Embed Size (px)
Citation preview
Windowsi-põhiste kohtvõrkude turbe
juhend
Tallinn 2019
Sisukord Saateks .................................................................................................................................. 5
1 Arhitektuuri haldus ......................................................................................................... 6
1.1 Väikese asutuse lahendus ................................................................................................ 8
1.2 Keskmise suurusega asutuse lahendus ............................................................................ 9
2 Andmete haldus ........................................................................................................... 10
2.1 Liikumises ....................................................................................................................... 10
2.1.1 Virtuaalne privaatvõrk (VPN) ................................................................................. 10
2.1.2 Proksi ...................................................................................................................... 34
2.1.3 Töökoha tulemüür ................................................................................................. 35
2.1.4 Telemeetria ............................................................................................................ 48
2.2 Andmete haldus talletades ............................................................................................ 50
2.2.1 Failiserveri kaitse seadistus .................................................................................... 50
2.2.2 Krüpteerimine ........................................................................................................ 58
2.2.3 BIOS/ EFI paroolikaitse ja olulisemad seadistused ................................................ 71
2.3 Andmete haldus pilves ................................................................................................... 75
2.3.1 Pilveteenuse riskid ja turvalisus ............................................................................. 76
2.3.2 Office 365 ja G Suite ............................................................................................... 77
3 Tarkvara haldus ............................................................................................................ 80
3.1 Windows Server Update Services .................................................................................. 81
3.1.1 WSUS teenuse paigaldamine ja seadistamine ....................................................... 81
3.1.2 Paigaldusjärgne seadistamine ................................................................................ 86
3.1.3 Tooted ja klassifikatsioonid .................................................................................... 89
3.1.4 Uuenduste piirangud ............................................................................................. 94
3.1.5 Arvutite lisamine ja grupeerimine ......................................................................... 94
3.1.6 Arvutite käsitsi lisamine ......................................................................................... 95
3.1.7 Arvutite lisamine rühmapoliitika abil ..................................................................... 97
3.1.8 SSL/HTTPS seadistamine ...................................................................................... 101
3.1.9 Andmebaasi puhastamine ................................................................................... 104
3.1.10 Ligipääs väljastpoolt sisevõrku ..................................................................... 105
3.2 WSUS Package Publisher .............................................................................................. 105
3.2.1 Paigaldamine ja seadistamine .............................................................................. 105
3.2.2 Sertifikaadi loomine, serverile ja klientidele paigaldamine ................................. 107
3.2.3 Pakettide loomine ja haldamine .......................................................................... 109
3.2.4 Pakettide paigaldamine ja jälgimine .................................................................... 113
3.3 System Center Configuration Manager ....................................................................... 114
3.3.1 Windows 10 versioonivärskendused ................................................................... 114
3.3.2 Automaatne paigaldamine ................................................................................... 115
3.3.3 Tarkvarapakettide loomine .................................................................................. 117
3.3.4 Tarkvarapakettide paigaldamine ......................................................................... 119
3.3.5 Ligipääs väljastpoolt sisevõrku ............................................................................. 120
3.3.6 Segamudeli soovitused ........................................................................................ 120
4 Identiteedihaldus ....................................................................................................... 121
4.1 Autentimine ................................................................................................................. 121
4.1.1 MFA (Multifactor authentication) ehk mitmeastmeline autentimine ................. 123
4.1.2 SSO ....................................................................................................................... 124
4.1.3 Paroolipoliitika GPO ............................................................................................. 125
4.1.4 Paroolipoliitika PSO (Password Settings Objects) abil ......................................... 126
4.1.5 Kasutaja sisselogimise piiramine seadmega ........................................................ 128
4.1.6 Konto aegumise määramine ................................................................................ 129
4.1.7 LAPS häälestus ..................................................................................................... 131
4.1.8 Windows Defender Credential Guard .................................................................. 134
4.2 Tulemüüri autentimine ................................................................................................ 135
5 BYOD (bring your own device) .................................................................................... 136
5.1 Võrgu seadistus ............................................................................................................ 136
5.1.1 Võrgu eraldamine................................................................................................. 137
5.1.2 Switchide seadistus .............................................................................................. 138
5.2 Riistvaraliidesed ........................................................................................................... 144
5.3 Mobiilsed seadmed (telefonid, sülearvutid ja tahvelarvutid) ...................................... 145
5.3.1 Office 365 mobiilipoliitika loomine ...................................................................... 146
5.4 Muud soovitused ......................................................................................................... 149
6 Rühmapoliitikate rakendamine Windows 10 põhises kohtvõrgus ................................. 151
6.1 Seadistamine ................................................................................................................ 151
6.2 Igapäevases praktikas kasulikuks osutunud GPOd Windows 10 tööjaamadele .......... 154
6.2.1 Lokaalse tööjaama paroolide vahemälu seadistamine ........................................ 154
6.2.2 Windows Defender Application Control .............................................................. 155
6.2.3 Tarkvarapiirangud ................................................................................................ 159
6.2.4 Veebisirvija seadistamine rühmapoliitikaga. ....................................................... 162
6.2.5 Tarkvara paigaldamine rühmapoliitika abil .......................................................... 166
6.2.6 Muud turvalisusega seotud rühmapoliitikad ....................................................... 168
7 Intsidendi halduse protsess ......................................................................................... 171
7.1 Pahavara tuvastus ........................................................................................................ 171
7.1.1 Sissejuhatus (milleks seda on vaja, millised on võimalused, ELAM) .................... 171
7.1.2 Windowsi omavahendid ...................................................................................... 172
7.1.3 Kolmanda osapoole vahendid .............................................................................. 179
7.2 Logimine ....................................................................................................................... 180
7.2.1 Windowsi teenuste logimine ............................................................................... 181
7.2.2 Süvalogimine ........................................................................................................ 188
7.2.3 Võrguseadmete logimine ..................................................................................... 188
7.2.4 Logide keskhaldus ................................................................................................ 189
8 Segamudeli soovitused ............................................................................................... 197
8.1 Erinevate OS masinate halduspoliitika ........................................................................ 197
8.1.1 Aegunud ebaturvaliste funktsioonide välja lülitamine GPOga ............................ 197
8.1.2 Serverite GPOd, mis nõuavad kõrgemat turvalisust ............................................ 200
8.2 Automaatne paikamine................................................................................................ 201
9 Võrgu ja võrguseadmete füüsiline turvalisus ............................................................... 202
10 Tööjaamade varunduslahendused ............................................................................... 203
11 Lõppkasutaja turvakoolituse korraldamine .................................................................. 207
Saateks
Käesolev juhendmaterjal on suunatud eelkõige väikese kuni keskmise suurusega asutuste (sh kohalikud
omavalitsused) võrkude süsteemiadministraatorile, toetamaks teda kaasaegse kohtvõrgu haldamise ja
kasutamisega seotud turvariskides orienteerumisel ning pakub abi levinud turvalahenduste hulgast
sobiva valimisel. Juhend ei käsitle uue taristu loomist, vaid keskendub olemasoleva arendamisele ja
turvamisele.
Juhend kirjeldab Windows 10 põhise kohtvõrgu ülesehituse põhimõtteid turvalisuse aspektist ning
annab praktiliselt rakendatavaid juhiseid meetmete kasutuselevõtuks, arvestades ISKE (infosüsteemide
kolmeastmeline etalonturbe süsteem) nõudeid.
Paljudel asutustel ei ole otstarbekas palgal pidada arvutiparki terviklikult haldavat täiskohaga
süsteemiadministraatorit ning teenused ostetakse sisse kolmandalt osapoolelt. Selliste lahenduste
kasutamine viib asutused tihti probleemini, kus infosüsteemi erinevate osade seadistused on tehtud eri
osapoolte poolt ja seetõttu puudub terviklik ülevaade infosüsteemist. Juhend annab tuge pädevate
otsuste tegemiseks IT teenuse (ka osalise) sisseostmise korral.
Teemade juures on toodud rühmapoliitika (GPO) näidisseadistus imporditavate konfiguratsioonifailidena
ning Powershelli skriptidena. Serveritarkvara kirjeldamisel on lähtutud juhendi koostamise ajal kõige
enam levinud versioonist Windows Server 2016, tööjaama tarkvara kirjeldamisel versioonist Windows
10 v1809. Nii üldine turvakontekst kui asutuste võimalused on pidevas muutumises - lisaks valmis
skriptitoorikutele ja poliitikatele (mis ei pruugi pärast järgmist tarkvarauuendust enam eeldatud viisil
toimida) sisaldab juhend ka turvateemadele lähenemise üldiste meetodite kirjeldusi.
Meetmete rakendamise prioritiseerimisel soovitame järgida RIA poolt välja antud ettevõtte
infoturbealase küpsustaseme hindamise juhendit (https://www.ria.ee/sites/default/files/content-
editors/KIIK/lisa_2_-_kupsustasemete_maaramise_juhend.pdf ) ja infoturbemeetmete kataloogi
(https://www.ria.ee/sites/default/files/content-editors/KIIK/lisa_3_-
_eto_infoturvameetmete_kataloog.xlsx ), mis on küpsustaseme hindamise aluseks.
Käesoleva dokumendi koostas AS BALTIC COMPUTER SYSTEMS Riigi Infosüsteemi Ameti tellimusel
Euroopa Liidu struktuuritoetuse toetusskeemi „Infoühiskonna teadlikkuse tõstmine“ raames Euroopa
Regionaalarengu Fondi rahastusel.
1 Arhitektuuri haldus
IT süsteemide arhitektuur peab katma asutuse IT vajadused ja arvestama sellega, et kõik ressursid
oleksid kättesaadavad ja kaitstud. Turvaline võrguplaneerimine on hädavajalik, et kaitsta teenuseid ja
informatsiooni pahatahtliku tegevuse eest. Planeerimise puhul tuleb arvestada võrgu ülesehitust, millist
riistvara ning tarkvara kasutada ja kuidas kõik peab olema seadistatud.
Eesmärgid, mida turvalise arhitektuuri juures meeles pidada:
Sisevõrk (tööjaamad, serverid ja ka muud seadmed) peab olema kaitstud internetist tulevate
rünnakute eest.
Kui mõnda süsteemi rünnatakse, peab arhitektuur toetama rünnaku pinna piiramist.
Kõik toimingud peavad olema logitud ning võimalusel võiks olla kasutuses sissetungi tuvastamise
süsteemi (IDS) või sissetungi tõkestamise süsteemi (IPS) tehnoloogiad.
Selleks, et neid eesmärke saavutada, on mõistlik lähtuda järgnevatest printsiipidest:
Võrgu segmenteerimine – erinevate eesmärkidega teenused ja seadmed peaksid asuma
erinevates võrkudes või tsoonides ja nende ligipääsud üksteisele peavad olema piiratud
(lähtudes vähima õiguse printsiibist). Segmenteerimisel peab planeerima tsoonid vastavalt
teenustele. Tavaline eraldatus, mida tasub alati rakendada, on eraldi sisevõrk, serverite võrk ja
külaliste võrk. Järgmise astmena tasub eraldada võrk, kuhu luuakse VPN ühendus, tõsta eraldi
võrku võrguseadmed ja telefonid ning serverite võrgu puhul eraldada serverid, mis on ainult
sisemiseks kasutamiseks ning serverid, mis on väljast kättesaadavad.
Õiguseid ja ligipääse anda lähtuvalt vähima õiguse printsiibist. See tähendab, et tuleb uurida
täpselt mida kasutaja või programm soovib teha ning anda õigused ja ligipääsud ainult selle
jaoks, kuigi võib esmapilgul olla kergem anda näiteks administraatoriligipääs või avada kõik
pordid serveril. Täpsemalt võib sellest lugeda siit: www.us-
cert.gov/bsi/articles/knowledge/principles/least-privilege (vt Arhitektuur_1.pdf).
Kasutada kõige turvalisemaid lahendusi:
o Kasutada turvalisi krüptograafilisi lahendusi.
o Kui lahendustes on turvaauke, tuleb need kohe paigata.
o Kui selgub, et mõni kasutuses olev lahendus pole enam turvaline (ja selle paikamine ei
ole võimalik), selle kasutamine lõpetada.
o Lülitada välja ebaturvalised protokollid ning keelata nende kasutamine.
Kontrollida pidevalt võrku. Kuna võrk on pidevas muutumises ja uued lahendused või vanade
eemaldamine võivad segada loodud seadistusi, siis tasub pidevalt kontrollida juba loodud võrku:
o Kontrollida pidevalt logisid, selle lihtsustamiseks võib korjata logid kesksesse serverisse
ja luua reeglid, mis võimaldavad paremini kõike jälgida.
o Rakendada IDS või võimalusel IPS süsteeme. Suurem osa tulemüüre pakub seda
võimalust, et võrguliiklusele IPS süsteem rakendada. Seda tasub teha, et tuvastada
rünnakute esinemist või kahtlast liiklust. Kõrgema turvalisuse puhul tasub võtta
kasutusele ka lahendusi, mis võimaldavad seda rakendada ka tööjaamadele.
o Jälgida, et kõik muudatused, mis sisse viiakse, on autoriseeritud (et administraatorid ei
teeks muudatusi oma suva järgi).
o Kontrollida regulaarselt loodud tulemüüri jms reegleid, et kõigi vanade teenuste reeglid
oleks eemaldatud.
o Kontrollida, et kõik loodud reeglid ning erandid oleks dokumenteeritud.
o Kontrollida, et kõik uued teenused oleks järelvalve all ja logitud.
o Jälgida kõiki sisemisi võrke ja WAN ühendust haavatavuse skaneerimise tööriistadega.
Neid on saadaval nii tasulisi (näiteks Nessus, saadaval
www.tenable.com/products/nessus/nessus-professional, F-Secure Radar, saadaval
www.f-secure.com/en/web/business_global/radar, GFI Languard, saadaval
www.gfi.com/products-and-solutions/network-security-solutions/gfi-languard, Qualys
Vulnerability Managment, saadaval www.qualys.com/apps/vulnerability-management/)
kui tasuta (näiteks OpenVAS, saadaval www.openvas.org/ ) ja need võimaldavad
tuvastada, kas võrgus on nõrkusi, mida varem seal ei olnud.
Käesolevas juhendis kirjeldame kahte lahendust – väike asutus paarikümne töötajaga ning keskmise
suurusega asutus 50+ töötaja ja mitme asukohaga.
1.1 Väikese asutuse lahendus
Väikeses asutuses on üks Microsoft Hyper-V Server 2016, millele on paigaldatud kaks virtuaalset
Windows 2016 Standard serverit. Ühe Windows serveri peal on AD, DNS, DHCP, CA, NPS ja VPN rollid,
teise Windows serveri peal on WSUS ja failiserveri rollid. Kasutajad töötavad nii kontoris kui
kodukontoris. Tulemüür on piisava võimekusega, et toetada veebi- ja rakendusfiltreid. Asutuse
tööjaamad on Windows 10 Professional ning kõik on domeeni liikmed. Asutuse serverid, tööjaamad ja
muud seadmed asuvad samas võrgus. E-mailid asuvad välise teenusepakkuja juures.
Internet
LANTööjaamad
Füüsiline serverWindows HYPER-V 2016
Virtuaalne server 1AD, DHCP, DNS, CA, VPN
Virtuaalne server 2WSUS, failiserver
Tulemüür
1.2 Keskmise suurusega asutuse lahendus
Suuremal asutusel on kahest füüsilisest Windows 2016 serverist koosnev klaster. Mõlema klastrisõlme
peal asub üks Windows 2016 AD, DNS, DHCP server. DHCP serverite skoobid on omavahel klastris ehk
siis ainult üks neist jagab IP aadresse ja probleemide korral on üleminek automaatne. Ühe AD serveri
peal on täiendavalt CA roll ja teisel AD serveril lisaks NPS ja VPN roll. Süsteemis on ka virtuaalne
logiserver, failiserver ja WSUS/CCM server rolli täitvad Windows 2016 serverid. Asutusel on ka teine
kontor, võrgud on ühendatud tulemüüride vahelise IPSec VPN kanali abil, kogu teise kontori võrguliiklus
suunatakse välja läbi peamaja tulemüüri. Allasutuse DHCP-d teeb tulemüür. Tulemüürid on piisava
võimekusega, et toetada veebi- ja rakendusfiltreid. Asutuse tööjaamad on Windows 10 Enterprise ning
on lisatud domeeni. Serverid asuvad tööjaamadest eraldatud võrgus. E-mailid asuvad välise
teenusepakkuja juures.
LAN
Internet
DMZFüüsiline server1
Windows Server 2016
Virtuaalne server 1AD, DHCP, DNS, CA
Virtuaalne server 2AD,DHCP,DNS, NPS, VPN
Peamaja Tulemüür
Füüsiline server2Windows Server 2016
Tööjaamad
Allasutuse tulemüür
LAN
Tööjaamad
KLASTER
Virtuaalne server 3Failiserver
Virtuaalne server 4SCCM/WSUS
Virtuaalne server 6Logiserver
2 Andmete haldus
2.1 Liikumises
2.1.1 Virtuaalne privaatvõrk (VPN)
Virtuaalne privaatvõrk (VPN) on krüpteeritud tunnel kahe asukoha vahel (vt ka ISKE M 3.65w). See
tunnel võib olla kahe võrgu vahel (Site-to-Site) või seadme ning võrgu vahel (End-to-Site, ligipääsu VPN).
Virtuaalset privaatvõrku kahe võrgu vahel kasutatakse tavaliselt kahe asutuse (näiteks koostööpartnerid,
peamajafiliaalid, ühe asutuse kaks maja jne) vahelise ühenduse loomiseks ning VPN luuakse tavaliselt
tulemüürist/ruuterist teise tulemüüri/ruuterini. Ligipääsu VPN on mõeldud selleks, et kasutajad saaksid
ühendust oma töövõrguga. Tänapäeval, kus väga palju tööd tehakse väljaspool kontorit, on taoline
võimalus äärmiselt vajalik ning antud juhendis keskendumegi peamiselt sellele. Lisaks asjaolule, et see
loob otsetunneli töövõrku, kaitseb see andmeid, mis arvutist üle selle tunneli liiguvad – need võivad olla
kõik andmed või siis ainult andmed, mis liiguvad töökoha ja arvuti vahel. ISKE-s käsitletakse antud
teemat punktis B 4.4.
2.1.1.1 Erinevad lahendused
VPN lahendusi on mitmesuguseid ja erineva turvalisuse astme ja seadistamise keerukusega. Windowsis
on võimalik seadistada SSTP, PPTP, L2TP/IPSec ja IKEv2/IPSec VPN versioone. Väga populaarne ja
võimekas VPN on OpenVPN ning paljud tulemüürid pakuvad ka enda SSL VPN lahendust. Sõltuvalt
lahenduse turvalisusest ja võimalustest tuleb teha kõige mõistlikum valik oma võrgu jaoks. Sobiva VPN
süsteemi valiku tegemine on käsitletud ka ISKE kataloogis M2.419 ja M 5.76w. Valiku tegemisel tuleks
arvestada, kas on vajalik ka mitmeastmeline autentimine (MFA ehk multi-factor authentication) –
täpsemalt peatükkides VPN ja MFA.
2.1.1.1.1 PPTP
PPTP (Point-to-Point Tunneling Protocol) on vana ja ebaturvaline lahendus ning selle liiklust on võimalik
dekrüpteerida. PPTP kasutab ühenduse loomiseks GRE protokolli ja 1723 porti. Paljud viirusetõrjed ja
kodused ISPd blokeerivad GRE protokolli ja samuti asudes mujal võrkudes ei pruugi olla pordi 1723 liiklus
lubatud ning VPN ühenduse loomine võib olla võimatu. PPTP ühendust on võimalik luua Windowsi
omavahenditega.
Soovitame rangelt seda mitte kasutada. Kui see on hetkel kasutusel, siis kindlasti kolida üle SSTP peale
või kui võrgus on teisi operatsioonisüsteeme peale Windowsi, siis OpenVPN peale.
2.1.1.1.2 IKEv2/IPSec
IKEv2/IPSec on turvaline lahendus, mis töötab nii Windows kui ka MacOS tööjaama puhul. Lahendus
kasutab UDP 500 ja UDP 4500 porti, mis võivad olla tulemüüri poolt blokeeritud ja seetõttu ei pruugi
VPN loomine kõikjalt olla võimalk.
IKEv2/IPSec lahendust soovitatakse kasutada mobiilide puhul, sest see suudab säilitada VPN ühenduse
isegi siis kui see vahepeal katkeb. Samuti, kui on soovi kasutada VPN reconnecti taasühendamise
tehnoloogiat (mis võimaldab vahetada võrku ilma, et VPN ühendus katkeks), on vajalik ka selleks
kasutada IKEv2/IPSec VPN lahendust.
Sobib lahendusena, kui on vaja luua VPN ühendus MacOS arvutist. Ühendust on võimalik luua Windows
ja MacOS omavahenditega.
2.1.1.1.3 L2TP/IPSec
L2TP/IPSec on turvaline lahendus, aga seda ei loeta nii turvaliseks kui IKEv2/IPSec ühendust.
Sobib lahenduseks, kui on vaja luua MacOS arvutis VPN ühendus. L2TP puhul on sama probleem kui
IKEv2 lahendusel, et kasutab ühenduseks UDP 500 ja UDP 4500 porti, mille tulemüür võib olla
blokeerinud ja seetõttu ei pruugi VPN ühenduse loomine õnnestuda. Ühendust on võimalik luua
Windows ja MacOS oma vahenditega.
Kui hetkel on kasutuses L2TP lahendus, siis tasuks see ümber teha IKEv2 lahenduse peale – kõik uuemad
operatsioonisüsteemid toetavad IKEv2 ühendust, see on turvalisem ja kiirem.
2.1.1.1.4 SSTP
SSTP on turvaline Microsofti poolt loodud lahendus. Lahendus on peamiselt kasutatav Windows
operatsioonisüsteemiga, kuigi viimasel ajal on lisandunud võimalused ka Linux ja MacOS X jaoks.
Kuna Microsoft pole lähtekoodi avanud kõigile (aga on avaldanud protokolli kirjelduse leheküljel:
docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sstp/c50ed240-56f3-4309-8e0c-
1644898f0ea8, vt Andmete_haldus_1.pdf), ei ole välised eksperdid seda täielikult uurinud ja ei saa
täielikult turvalisust kinnitada. Ühendus toimub üle pordi nr 443, mistõttu ei ole see enamikes võrkudes
piiratud. Ühendust on võimalik luua Windows omavahenditega.
Kui tööjaamad on Windows 10 peal ja serverid on Windows serverid, soovitame kasutada antud
lahendust, sest see on turvaline, võimaldab ühendust kõikjalt luua ning võimalik on seadistada õiguseid
AD põhiselt ning piirata ligipääse.
2.1.1.1.5 OpenVPN
OpenVPN on turvaline lahendus, mida toetavad kõik platvormid. Turvalisuse mõttes kasutab OpenVPN
AES krüpteeringut ja kuna lähtekood on avatud, on seda uuritud ka puuduste suhtes, mis teeb OpenVPN
lahenduse kõigist VPN süsteemidest kõige turvalisemaks. OpenVPN vaikimisi port on UDP port 1194, aga
seda on võimalik seadistada töötama ka port 443 pealt.
OpenVPN serverit saab seadistada nii Windowsi ja Linuxi operatsioonisüsteemidele, mõnele tulemüürile
ja NAS seadmetele. Tasub arvestada, et tulemüüri või NAS peal seadistades võivad seadistused olla
piiratud (näiteks ei saa muuta vaikimisi porti vms). Kasutamiseks peab tööjaama olema installeeritud
OpenVPN klient.
Lihtne juhend Windows serveri ja kliendile paigaldamiseks on saadaval siin:
community.openvpn.net/openvpn/wiki/Easy_Windows_Guide (vt Andmete_haldus_2.pdf), kuid
Windows AD keskkonnas tasuks kindlasti mõelda, et kasutada OpenVPN kommertstoodet OpenVPN
Access Server (saadaval: openvpn.net/vpn-server-resources/use-cases-for-the-openvpn-access-server-
product/, vt Andmete_haldus_3.pdf), mis võimaldab ka LDAP ühendust AD serveriga, saadaval
openvpn.net/vpn-server-resources/openvpn-access-server-on-active-directory-via-ldap/ (vt
Andmete_haldus_4.pdf). Selle skaleerumisega on olnud probleeme, suuremas ettevõttes tuleb
lahendust enne kasutusele võtmist testida.
Kui puudub Windows serveri keskkond, on see kõige mõistlikum lahendus (vt ISKE kataloog M 5.148).
Windows serveri võimaluse olemasolul soovitame kasutada ikkagi SSTP VPN süsteemi, sest see
võimaldab hallata kõige paremini kasutajakontosid ja ligipääse.
2.1.1.1.6 Tulemüüride VPN
Võimekamad tulemüürid nagu Sophos, Fortigate, Cisco jne pakuvad ka oma kliendile VPN süsteemi
paigadamise võimalust. Mitmed võimaldavad seadistada ka OpenVPN süsteemi, aga tavaliselt on
pakutavaks VPN variandiks tulemüüri tootja enda SSL VPN.
Need töötavad tavaliselt üle pordi 443 ja eeldavad ka antud tulemüüritootja klientprogrammi
installeerimist tööjaama ja mõningal juhul ka lisalitsentsi ostu. Seadistamise võimalused erinevatel
seadmetel on erinevad (vt näiteks: community.sophos.com/kb/en-us/122769 vt Andmete_haldus_5.pdf
või www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/200533-
AnyConnect-Configure-Basic-SSLVPN-for-I.html, vt Andmete_haldus_6.pdf). SSL VPN lahendust loetakse
turvalisuselt samal tasemel olevaks kui SSTP ja OpenVPN.
Mõni tulemüür võimaldab ka ühendust AD serveriga ja sellisel juhul saab ligipääse hallata AD gruppide
või kontode kaudu.
2.1.1.2 Windows VPN seadistamine
Kuna Windows võrgu puhul on kõige mõistlikumaks lahenduseks Windows SSTP VPN, siis antud juhendis
käsitletakse Windows SSTP serveri ja kliendikonto seadistamist.
Windows VPN serveri seadistamise eelduseks loetakse toimivat AD serverit (VPN seadistamine on
võimalik ka ilma AD serverita, aga ei soovita) ja ka Windows CA serveri olemasolu.
Nende seadistamisega saab tutvuda järgmistel internetilehekülgedel: docs.microsoft.com/en-
us/windows-server/identity/ad-ds/deploy/install-active-directory-domain-services--level-100- (vt
Andmete_haldus_7.pdf) ja
docs.microsoft.com/en-us/Windows-server/networking/core-network-guide/cncg/server-certs/install-
the-certification-authority (vt Andmete_haldus_8.pdf)
2.1.1.3 Sertifikaadi valik
SSTP serveri identiteedi tuvastamiseks kliendi poolt on vaja serverile installeerida sertifikaat (vt juhendit
allpool).
Selleks on mitmeid valikuid:
1. Ostetud sertifikaat
2. Lokaalse domeeni CA sertifikaat
3. Let's Encrypt sertifikaat
Ostetud sertifikaati on kõige mugavam kasutada, eriti kui see soetada pikaajaliselt – nimelt usaldab seda
enamik seadmetest ja see ei vaja pidevat vahetamist. Sertifikaati saab osta erinevate teenusepakkujate
käest, selle tellimiseks tuleb luua certificate request (vt juhendit allpool).
Lokaalse domeeni CA (vt ka ISKE M 2.232) sertifikaat võib tunduda mõistlik valik, sest selle saab koheselt
luua ja seda usaldavad kõik domeeniarvutid. Kui on soov kasutada VPN süsteemi mitte-domeeni arvutil,
siis tuleks sinna installeerida domeeni juur-CA. Kuid selleks, et sertifikaadi kehtivust kontrollida, peab
tööjaamal olema ligipääs CRL failile. Kui see pole õigesti seadistatud, ei suuda tööjaam VPN ühendust
luua.
CRL nimekirja ligipääsu võimaldamiseks on kõige mõistlikum jagada see välja veebi kaudu.
Siinkohal peab arvestama, et CRL nimekirjale ligipääsu tehes väljaspool sisevõrku peab veebiserver
olema avatud kogu internetile ja peab olema turvaliselt seadistatud (turvalisuse soovitused järgmisel
leheküljel: techcommunity.microsoft.com/t5/ITOps-Talk-Blog/Windows-Server-101-Hardening-IIS-via-
Security-Control/ba-p/329979, vt Andmete_haldus_9.pdf). Samuti toimib CRL nimekirja jagamine ainult
üle HTTP ühenduse. Kõike seda peab arvestama lokaalse CA sertifikaadi kasutusele võtmise juures ning
sellest tulenevalt ei ole see toodangukeskkonnas kõige parem lahendus.
Antud CRL ligipääsu seadistamise näite puhul asuvad CA server ja veebiserver sama serveri peal. Selleks
tuleb toimida järgnevalt:
1. Avada Server Manager rakenduse kaudu Certification Authority liides.
2. Teha paremklõps CA nimel, valida Properties ja avanenud aknas valida Extension vaheleht.
3. Valida Extension CRL distribution point (CDP) ja Add ning avanenud aknas määrata asukohaks
aadress, kuhu pääseks ligi nii seest kui väljast - selleks on vaja teha DNS kirjed nii sisemisse kui
välimisse DNSi ja perimeetritulemüüri olemasolul suunata port 80 antud serveri peale. Näiteks:
crl.test.ee/CertEnroll
4. Muutujate nimekirjast (Variables) lisada sinna (kasutades nuppu Insert)
<CaName><CRLNameSuffix><DeltaCRLAllowed> ning lõppu panna laiend .crl
Lõplik teekond oleks järgmine:
http://crl.test.ee/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
Peale seda valida OK.
5. Märgistada loodud kirje ja valida sealt omadused Include in CRLs.
6. Valida laiendus Authority Information Access (AIA). Panna asukoht nagu punktis 4. Näiteks:
crl.test.ee/CertEnroll. Peale seda lisada muutujate nimekirjast
<ServerDNSName>_<CaName><CertificateName> ning lõppu laiend .crt. Lõplik teekond oleks
järgmine: crl.test.ee/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt
Märgistada loodud kirje ja valida omadus Include in the AIA extension of issued certificates.
7. Seejärel on CRL nimekiri kõikjalt kättesaadav ja tööjaamad saavad edukalt ka väljaspool
töövõrku sertifikaati autentida. Jälgida kindlasti, et serveri tulemüür lubaks pöördumist HTTP
pordi poole.
Vajalikud seadistused saab teha ka Powershell käsu abil nii:
Add-CACRLDistributionPoint -Uri "http://crl.test.ee/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl" -AddToCertificateCdp -AddToFreshestCrl -Force
Add-CAAuthorityInformationAccess -Uri "http://crl.test.ee/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt" -AddToCertificateAia –Force
Täpsemalt võib CRL jagamise kohta lugeda järgnevalt leheküljelt:
blogs.technet.microsoft.com/nexthop/2012/12/17/updated-creating-a-certificate-revocation-list-
distribution-point-for-your-internal-certification-authority/ (vt Andmete_haldus_10.pdf).
Sellest on võimalik mööda minna, luues tööjaamas vastav registrikirje (enne teha kindlasti registri
varundus):
1. Selleks minna registris asukohta
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sstpsvc\Parameters
2. Sinna luua registrikirje (REG_DWORD) “NoCertRevocationCheck” ja määrata selle väärtuseks 1.
Kuna see vähendab turvalisust, siis me rangelt soovitame seda väljaspool testimist mitte teha.
Let's Encrypt on CA süsteem, mis pakub tasuta lühiajalisi (90 päeva) sertifikaate, mida on võimalik
automaatselt uuendada (täpsemalt: letsencrypt.org/docs/). Ka seda usaldavad üldiselt kõik seadmed ja
selle kasutamiseks ei pea tegema tööjaamades tegema lisaseadistusi, aga kuna VPN sertifikaat aegub iga
90 päeva tagant, tekitab see administraatorile lisatööd. Kuigi on võimalik seadistada, et sertifikaat
uueneks automaatselt, siis VPN seadistuses see ei uuene ja muudatus tuleb teha käsitsi, mis omakorda
eeldab VPN serveri teenuse taaskäivitamist. Samuti tuleks kohe vanad sertifikaadid eemaldada, sest nad
võivad segada sätteid ja uus sertifikaat ei pruugi enne rakenduda, kui vanad on eemaldatud.
2.1.1.4 SSTP VPN serveri seadistamine
2.1.1.4.1 Sertifikaadi loomine ja installeerimine
Nagu ka eespool on viidatud, on SSTP serveri seadistamiseks vajalik, et serverile oleks seadistatud
sertifikaat. Selle loomiseks tuleb teha IIS kaudu sertifikaadi taotlus:
1. Avada IIS Manager programm, vajutada sealt serveri nimele ning paremast aknast valida Server
Certificates
2. Avanenud vaates valida Action menüüst Create Certificate request käsklus. Täita taotluse andmed
vastavalt oma andmetele. Common name peab olema nimi, mille kaudu tööjaamad pöörduvad
serveri poole – näiteks vpn.test.ee. Bitipikkuseks valida vähemalt 2048. Taotluse salvestamise
asukohaks võib panna endale sobiva koha, kus salvestatud fail on hiljem kättesaadav.
Nime kohta peab looma DNS kirje, mis viitaks antud serveri välise IP peale (rangelt ei soovita
serverit otse internetis hoida) või tulemüüri välise IP aadressi peale, kus port 443 on suunatud
antud serveri peale.
3. Peale faili loomist, juhul kui sertifikaat ostetakse kolmandate osapoolte käest, võib selle faili antud
teenusepakkujale edastada (või sisestada see veebiliidese kaudu) ning peale vajaliku sertifikaadi
saamist kopeerida see serverisse. Edasi minna uuesti IIS Manageri ja samast kohast, kus sai loodud
sertifikaadi taotlus, valida Complete Certificate request käsklus ning näidata sertifikaadi asukoht.
4. Kui kasutada lokaalset CA süsteemi, saab antud taotluse sisestada veebi kaudu: CAserver/CertSrv.
Sealt valida Request a Certificate –> Advanced certificate request - Submit a certificate request by
using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-
encoded PKCS #7 file. Vastavussertifikaadiks valida Web server ja kopeerida punktis b loodud faili
sisu aknasse. Peale Submit vajutamist loob CA sertifikaadi, mille saab alla laadida ja paigaldada
samamoodi kui ostetud sertifikaati.
5. Peale sertifikaadi lisamist IIS süsteemi tuleks see muuta pordile 443 (HTTPS) sertifikaadiks. Selleks IIS
Manager-is Action menüüst valida Bindings, valida avanenud aknas HTTPS, Edit ja SSL Certificate alt
valida sertifikaat, mis sai lisatud eelmises punktis. Muudatuse rakendumise kindlustamiseks tasub ka
taaskäivitada, selleks anda käsuviibast (CMD) käsk IIS reset.
6. Nagu mainitud punktis 2, siis selleks, et VPN serverile saaks ligi üle interneti, peab tulemüüris olema
suunatud port 443 antud serveri peale. Samuti peab olema loodud DNS kirjed selle välise IP peale,
mille port 443 on suunatud serveri peale.
2.1.1.4.2 VPN serveri install ja üldiste parameetrite häälestus
1. Installeerida Kaugjuurdepääsu (Remote access) server:
a) Graafilise kasutajaliidese (GUI) programmi kaudu: Server Manager – Add Roles and Features,
valida Remote Access ning installeerida kõik vajalikud omadused, teenuste (Role Services) alt
valida otsene juurdepääs (DirectAccess and VPN (RAS))
b) Powershell (käivitada administraatori õigustes) käsuga:
Install-WindowsFeature RemoteAccess –IncludeManagementTools Install-WindowsFeature DirectAccess-VPN –IncludeManagementTools
2. Kui installeerimine oli edukas, siis saab alustada seadistust:
a) Avada aken Server Manager – Tools – Routing and Remote Access. Avanenud aknas teha
paremklõps serveri nimel ning valida käsklus Configure and Enable Routing and Remote Access.
b) Avanenud viisardil Configuration valikus valida Custom configuration
c) Järgnevalt lehelt teha valik VPN access, siis Next ja Finish
3. Virtuaalse privaatvõrgu (VPN) üldiste parameetrite seadistamine.
a) Avada Routing and Remote Access kaugjuurdepääsu aken ning paremklõps serveri nimel ja
Properties.
Security alt kontrollida, et Windows Authentication Method käskluse alt oleks valitud ainult EAP
ja MS-CHAP v2 ning SSL Certificate Binding oleks vaikimisi (Default) - siis server kasutab
sertifikaati, mis sai seadistatud sertifikaatide loomise punktis.
b) IPv4 all kasutab server vaikimisi dünaamilise hostikonfiguratsiooni protokolli (DHCP), aga on
võimalik ka staatiliselt määratleda, milliseid IP aadresse jagatakse.
4. Virtuaalse privaatvõrgu (VPN) ligipääsu jaoks võiks teha eraldi AD domeeni grupi näiteks nimega
VPN, mis kirjeldab sobivalt inimesi, kellele see ligipääs antakse. Kui on plaanis piirata privaatvõrgu
ligipääse vastavalt ISKE M2.418 (vt punkt - VPN seadistuse kaudu ressursside ligipääsu piiramine), on
võimalik luua erinevaid privaatvõrgu poliitikaid ja rakendada need erinevatele gruppidele.
On ka PowerShell käske, mille abil on teatuid VPN parameetreid võimalik seadistada või pärida
informatsiooni praeguse seadistuse kohta. Näiteks Get-RemoteAccess, mis annab üldise informatsiooni
VPNi kohta (sama on näha ka punktis 3 kirjeldatud graafilise liidese kaudu). Täpsemalt nende
käskude kohta: docs.microsoft.com/en-us/powershell/module/remoteaccess/?view=win10-ps vt
Andmete_haldus_39.pdf
2.1.1.4.3 Parooliga autentimise VPN võrgu seadistamine
Virtuaalse privaatvõrgu (VPN) puhul soovitame kindlasti kasutada sertifikaadiga autentimist, sest seda
loetakse turvalisemaks. Kuna teatud juhtudel pole see võimalik, tutvustame antud juhendis ka parooliga
autentimise seadistust. Selleks, et seadistada, kuidas on võimalik ühendada privaatvõrku, tuleb luua VPN
poliitika:
1. VPN poliitika loomiseks avada Server Manager kaudu Network Policy Server aken.
a) Valida Policies – Network Policies ja paremklõps New
b) Policy nimi panna endale sobiv ja Type of Network Access valida Remote Access Server, VPN Dial-
Up.
c) Conditons all valida Add ja määrata Windows grupp, mis sai loodud üldiste parameetrite loomise
punktis 4.
d) Access granted jätta samaks.
e) Configure Authentication Methods aknas eemaldada kõik ebaturvalised autentimismeetodid
(Less secure authentication methods). EAP Types alt valida Microsoft: Protected EAP. MS-CHAP-
v2 loetakse iseseivalt ebaturvaliseks, aga PEAP protokolli valides toimub autentimine üle TLS/SSL
tunneli ja nii on autentimise liiklus kaitstud.
PEAP Edit käskluse alt on näha, et serveri sertifikaat, mida see autentimiseks kasutab, on loodud
varasemalt ning EAP Types all on EAP-MSCHAP v2.
Siis võib valida Next, Next ja Finish - nendes akendes pole vaja hetkel midagi muuta.
f) NB! Kui on aktiveeritud Credential Guard, siis kasutades EAP-MSCHAP v2 ei toimi domeeni
kasutajaga automaatne VPNi sisselogimine ja kasutaja peab alati oma kasutajanime ja parooli
sisestama.
2.1.1.4.4 Sertifikaadiga autentimise virtuaalprivaatvõrgu (VPN) seadistamine
1. Sertifikaadiga autentimise seadistamiseks on punktid „a“ kuni „e“ samad. Peale PEAP protokolli
valimist tuleb EAP Types all määrata Smart Card or other certificate.
a) Selleks, et kasutajad saaks end serverisse autentida, peavad nad saama kas manuaalselt või
automaatselt kasutajasertifikaadi. Sertifikaat peab olema kindlasti mitteeksporditav.
b) Kasutajatele mitteeksporditava sertifikaadi pakkumiseks tuleb luua uus sertifikaadimall ja
määrata selle sätted:
i) Avada Server Manager kaudu Certification Authority aken. Avanenud aknas teha paremklõps
Certificate Templates peal ja valida Manage.
ii) Avaneb Certificate template Console. Teha paremkõps User Template peal ja valida
Duplicate template käsklus.
iii) General alla määrata mallile uus nimi – näiteks „VPN kasutaja sert“ vms. Sertifikaadi
kehtivusaega ei tasuks määrata pikemaks kui üks aasta.
iv) Request Handling all võtta ära linnuke Allow private key to be exported.
v) Security all eemaldada domeeni kasutajad (Domain Users) ja lisada loodud privaatvõrgu
(VPN) grupp. Kui on soov, et kasutajad päriks sertifikaate manuaalselt, siis määrata Enroll ja
kui vaja, et nad saaks ka need automaatselt AD kaudu, siis valida nii Enroll kui ka Autoenroll
vi) Valida OK ja väljuda Template konsoolist. Selleks, et kasutajad ei saaks kogemata tavalist
kasutajasertifikaati taotleda, tasub ka selle turvalisuse seadeid muuta ja eemaldada sealt
domeeni kasutajate grupp.
vii) CA aknas teha Certificate Templates peal paremklõps ja valida New – Certificate Template to
issue ning valida avanenud aknast loodud sertifikaadimall ja vajutada OK. Nüüd on see
kättesaadav kasutajatele, kes on õiges grupis.
viii) Sertifikaati saab manuaalselt pärida kahest kohast:
(1) CertSRV veebiliidesest (kirjeldatud sertifikaadi loomise punktis 4). Valida Request a
certificate, advanced certificate request, Create and submit a request to this CA.
Certificate Template alt valida see mall, mis sai loodud. Teised sätted võib samaks jätta
ja valida kinnita (Submit).
(2) MMC kaudu ühendada Certificate snap-in külge ja valida oma kasutajakonto (My user
account). Avanenud vaates teha paremklõps Personal kaustal ja valida All Tasks –
request New Certificates. Valida Next ja Next ning kui tuleb sertifikaatide valik, siis sealt
valida loodud mall ning vajutada Enroll.
ix) Selleks, et kasutaja saaks domeenis olles automaatselt sertifikaadi, tuleb luua
rühmapoliitika, mis seda domeenis lubab. Lisatud näidis rühmapoliitika nimega
1_VPN_Autoenroll. Luua uus rühmapoliitika (server manager – tools – Group Policy
Manager) sinna OU külge, kus asub kasutaja. Uue GPO loomise aknas minna User
configuration – Policies – Windows Setting - Security Settings – Public Key Policies. Seal on
omadus Certificate Services Client – Auto-Enrollment. Avage see topeltklõpsuga. Valida
Configuration Model – Enabled ning teha linnuke ette ka järgnevatele omadustele:
(1) Uuenda aegunud ja ootel sertifikaate ja eemalda kustutatud sertifikaadid (Renew
expired certificates, update pending certificates, and remove revoked certificates)
(2) Uuenda sertifikaate, mis kasutavad sertifikaadi vorme (Update certificates that use
certificate templates)
Kui on soov, et arvutid saaksid automaatselt sertifikaadi, tuleb GPO loomise aknas minna
Computer Configuration harusse.
x) Peale GPO uuenduse saamist peaks kasutaja automaatselt saama loodud sertifikaadi (kui ta
on õiges grupis).
xi) Kui on olukord, kus kasutajad logivad sisse mitmesse arvutisse, siis tasub mõelda Credential
Roaming kasutusele võtmisele. Credential Roaming süsteem hoiab kasutajate
informatsiooni (sertifikaadid, privaatvõtmed jms) AD halduri käes ja kasutaja saab need sealt
kätte, kui ta domeeniarvutisse domeenivõrgus sisse logib. Sellisel juhul ei päri kasutaja iga
uue arvuti puhul uut sertifikaati. Täpsemalt Credential Roaming süsteemi kohta saab lugeda
TechNet wiki kodulehelt aadressil:
social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-
roaming.aspx (vt Andmete_haldus_11.pdf). Tuleb arvestada, et paljude sertifikaatide tõttu
võib AD andmebaas suureks kasvada.
2.1.1.4.5 VPN privaatvõrgu seadistuse kaudu ressursside ligipääsu piiramine
Vastavalt ISKE M2.418 tuleb luua VPN võrgu turbepoliitika ja määrata kuhu tohib VPN võrgu kaudu
pöörduda. Vaikimisi seadistustega VPN võrku saab ligi kõikjale, kuhu saab ligi VPN võrgu server. See võib
olla vajalik, aga soovitame võimalusel seda ligipääsu piirata. Näiteks teatud kasutajad saavad ligi ainult
teatud serveritele, kas ligipääsu õiguste sisuliseks piiramiseks või turvalisuse tõstmiseks (vt ka ISKE M
5.77z). Windows VPN puhul on võimalik VPN poliitikas määrata IP aadresside filtreid. IP aadresside
filtreid on võimalik seadistada otse VPN võrgu poliitikas või luua selle kohta malle.
Soovitame luua malle, sest see lihtsustab haldust.
1. IP Filtri malli loomiseks avada NPS haldusliides, minna sealt Template Managment – IP Filters ning
paremklõps New.
2. Määrata mallile sobiv nimi.
Et piirata ligipääsu serveritele, tuleb muuta seadistus Outbound Filters. Esialgu ei ole võimalik seal
teha muid valikuid kui New. Avanenud aknas allikvõrguks (Source Network) määrata server/teenus,
millele soovitakse ligipääsu lubada/keelata. Kui on vaja lubada/keelata ainult üks host, siis määrata,
et Subnet mask oleks 255.255.255.255. Samuti on võimalik määrata, milline Protocol on
lubatud/keelatud – näiteks ainult HTTP vms.
3. Kui esimene IP Filter on lisatud, on võimalik Outbound Filters aknas määrata, kas Do not permit
packets listed below või Permit only the packets listed below. Esimesel juhul ei lubata ühendusi
loodud IP peale ja teisel juhul keelatakse kõik muud ühendused peale loodud IP.
4. IP filtri malli rakendamiseks võib muuta kas olemasolevat VPN võrgupoliitikat või luua uus VPN
poliitika. Kui luua samasugune VPN poliitika kui varem, on kõige mõistlikum teha VPN poliitika peal
paremklõps ja valida Duplicate. Avada antud poliitika, Overview alt muuta nimi sobivaks ja teha
Policy Enabled ette linnuke. Tingimuste alla määrata, kellele see VPN poliitika peaks rakenduma
(näiteks eraldi grupp „Piiratud VPN“ vms). Settings alt valida IP Filters ja Select an existing IP Filter
template ning valida sealt loodud mall.
5. Peale ühendamist pääsevad „Piiratud VPN“ grupi kasutajad ligi võrgule vastavalt loodud mallis
määratud sätetele.
2.1.1.5 SSTP VPN kliendi seadistamine
SSTP VPN võrkude seadistamiseks kliendi poolel on mitmeid variante. Hetkel käsitleme manuaalset
seadistust, PBK faili loomist, GPO-ga seadistamist ning SCCM kaudu seadistamist.
2.1.1.5.1 Manuaalne seadistamine
1. Valida Control Panel - Network and Sharing Center – Set up a new connection or network.
2. Valida Connect to a workplace – Use my Internet connection (VPN).
3. Internet address on varasemalt loodud DNS kirje aadress. Valida Create.
4. Peale loomist minna Network and Sharing Centeris – Change adapter settings, valida sealt loodud
VPN adapter, paremklõps ja Properties.
5. Security all määrata Type of VPN on SSTP. Authentication alt määrata Use EAP ja sealt omakorda
Microsoft: Protected EAP.
Valida Properties:
a) Trusted Root Certification Auhtorities alt määrata CA, kelle poolt on välja antud punktis 1 loodud
serveri sertifikaat. NB! Sertifikaadi uuendamisel, kui on CA-d muudetud, tuleb muuta antud säte
ka kõigis kliendi arvutites.
b) Select Authentication Method alt valida kas Secure Password (EAP-MSCHAP vs2) või Smart Card
or other certificate.
i) Kui valida sertifikaadiga autentimine, siis vajutada Configure. Sealt määrata Use a certificate
on this Computer. Advanced mooduli all saab määrata, millise CA poolt väljastatud
sertifikaati täpsemalt kasutatakse ning sealt valida enda CA.
ii) Samuti võib uuesti Trusted Root Certification Authorities alt määrata CA, kelle poolt on välja
antud punktis 1 loodud serveri sertifikaat.
6. Tähtis säte on Networking all - Internet Protocol Version 4 Properties, Advanced ja IP Settings – Use
default gateway on remote network.
Kui see omadus on sees, saadetakse kogu liiklus läbi VPN serveri (ka interneti oma), see on tuntud
kui full tunnel. Soovitame seda kasutada, sest nii on võimalik ettevõtte tulemüüriga kontrollida (vt ka
ISKE M 5.77z) ja hoida jälgimise all liiklust, mis tehakse arvutiga, kui see on VPNi ühendatud.
Muidugi tuleb jälgida, et serveri ja ettevõtte tulemüür lubaks liiklust internetti, sest vastasel juhul
peale VPNi ühendamist kasutaja kaotab oma internetiühenduse.
Kui IP Filters, millel on lubatud ligipääs ainult teatud serveritele, on sees, tasub see välja lülitada,
sest muidu kaotab VPN võrku ühendatud arvuti internetiühenduse. Kui see säte on välja lülitatud,
siis on tegemist split tunneliga, nii et VPN kaudu liigub ainult ühendus VPN võrku ja ülejäänud
võrguühendus toimib nagu varem ja liigub otse välja.
7. Valida OK ja VPN on seadistatud.
VPN klienti on võimalik seadistada ka PowerShell kaudu, vastavalt käskudele docs.microsoft.com/en-
us/powershell/module/vpnclient/?view=win10-ps vt Andmete_haldus_38.pdf.
2.1.1.5.2 PBK faili loomine
PBK faili loomiseks on kaks võimalust:
1. Luua uus tühi fail (näiteks .txt dokument). Muuta selle nimi, nii et see lõppeks .pbk faililaiendiga.
Loodud faili peal teha topeltklõps, valida OK ja avanenud valikutest workplace network. Edasi
seadistada internetiaadress nagu manuaalse seadistuse puhul ning valida OK. Siis valida Properties ja
muuta sätteid nagu punktis manuaalne seadistamine.
2. Kui arvutisse on juba VPN loodud, on selle seadistused salvestatud asukohta
%userprofile%\AppData\Roaming\Microsoft\Network\Connections\PBK. Seal on fail rasphone.pbk.
Selle võib kopeerida näiteks töölauale ja failinime muuta vastavalt vajadusele (näiteks vpn.pbk). Kui
arvutisse on seadistatud mitu VPN võrku, on võimalik seda avada Notepad programmiga ja
kopeerida sealt ainult vajalik osa VPN võrgu seadistusest .txt faili. Seejärel loodud .txt fail ümber
salvestada, nii et see oleks .pbk faililainediga. Erinevad VPN võrgud eristuvad nii, et algavad VPN
nimega (näiteks [VPN] vms).
PBK faili kaudu VPN võrgu ühendamiseks tuleb fail avada topeltklõpsuga ja valida Connect. Ühenduse
katkestamiseks avada fail uuesti ja valida katkesta (Hang Up).
2.1.1.5.3 VPN võrgu seadistamine GPO kaudu
VPNi seadistamiseks tuleb luua uus GPO (server manager – tools – Group Policy Manager) sinna OU
külge, kus asuvad kasutajad. Lisatud näidis rühmapoliitika nimega 2_VPN_VPN_copy.
Windows GPO-de puhul on olemas võimalus luua VPN ühendus automaatselt, aga see ei paku piisavalt
seadistuse võimalusi (näiteks PEAP seal valikus pole) ning ei oma valikus ka SSTP VPNi.
GPO kaudu SSTP VPNi seadistamiseks tuleb kas asendada rasphone.pbk fail või luua Powershell kaudu.
1. Faili kopeerimiseks:
a) Selleks, et rasphone.pbk kasutajal asendada, tuleb kõigepealt õige PBK fail mõnes arvutis luua ja
jagada välja mõnes kaustaserveris, kuhu oleks vajalikel kasutajatel (kas kõigil või VPN grupis
olijatel) lugemise õigused. Näiteks: \\Testserver\vpn_settings
b) Luua bat fail, näiteks nimega copy.bat ja luua sinna seadistus, mis kopeeriks antud kataloogist
failid kasutaja PBK kataloogi: xcopy "\\testserver\VPN_settings" "%userprofile%\AppData\Roaming\Microsoft\Network\Connections\Pbk\" /z /r /y
c) GPO-s minna User Configuration, Windows Settings – Scripts (Logon/Logoff). Avada Logon ja
valida Add, valida Browse ja kopeerida Copy.bat avanenud aknasse, märkida kopeeritud fail ja
valida Open. Vajutada OK.
d) Peale GPO levimist, kui kasutaja logib sisse, kopeeritakse fail tööjaama ning VPN valikute alla
tekib õige VPN.
NB! Kui arvutis on midagi VPN-iga teisiti seadistatud, siis need sätted kirjutatakse üle
vaikesätetega. Seetõttu võib olla mõistlik piirata selle GPO levikut VPN lubatud grupiga. Selleks
tuleb muuta GPO Security Filtering sätteid. Security Filtering alla lisada grupp VPN ja eemaldada
grupp Authenticated users.
Kuid Delegation all lisada kindlasti authentication users tagasi Read õigustega, sest muidu GPO
ei rakendu.
2. Powershell kaudu:
a) Arvutis, kus on VPN seadistatud, on vaja on genereerida EAP konfiguratsioon, selleks kasutada
skripti:
$exportXML = (Get-VpnConnection -Name "VPN").EapConfigXmlStream #VPN on selle juba seadistatud VPN ühenduse nimi $exportXML.Save("c:\temp\VPN_config.xml") #asukoht, kus saab pärast antud faili kätte
i) See fail tuleb kopeerida serverisse ja jagada välja inimestele kellel on VPN ühendust vaja
(nagu punktis 1.a)
b) Luua Powershell skripti fail, näiteks vpn.ps1 ja sinna lisada käsud:
$importXML = New-Object XML $importXML.Load("\\testserver\VPN_settings\VPN_config.xml") Add-VpnConnection -Name "Powershell VPN" -ServerAddress "vpn.test.ee" -TunnelType Sstp -EncryptionLevel Maximum -AuthenticationMethod Eap -EapConfigXmlStream $importXML
c) Luua uus GPO (Server manager – Tools – Group Policy Manager) OU külge, kus asuvad kasutajad.
GPO-s minna User Configuration, Windows Settings – Scripts (Logon/Logoff). Avada Logon ja
avanenud aknas valida Powershell Scripts. Valida Add ja Browse ning kopeerida loodud skript.
Märkida kopeeritud fail ja valida Open. Vajutada OK. Lisatud näidis rühmapoliitika nimega
3_VPN_Powershell VPN.
d) Peale GPO levimist kasutaja sisselogimisel käivitatakse skript ning VPN valikute alla tekib õige
VPN. Erinevalt kopeerimise viisist jäävad alles ka eelmised VPN seadistused, aga GPO õiguseid
tasub muuta ikkagi samamoodi nagu punktis 1.d.
2.1.1.5.4 VPN võrgu seadistamine SCCM kaudu
SCCMis on olemas eraldi sätte punkt, mille kaudu saab seadistada VPNi. Kuigi ka siin ei ole SSTP varianti,
siis saab valida Automatic ja kõiki vajalikke autentimise sätteid on võimalik määrata.
1. Avada konfiguratsiooni manager (Configuration Manager console)
2. Minna Overview – Compliance Settings – Company Resource Access – VPN Profiles
3. Teha paremklõps Create VPN Profile. Määrata sobilik nimi ja VPN profile Type Windows 10 –
järgmisel lehel valida Windows 10 (see sätestab, et VPN paigaldatake kõigile Windows 10
versioonidele).
4. Configure VPN connection käskluse alt valida – Microsoft Automatic ja server listi lisada Friendly
Name (vastavalt soovile) ja VPN serveri nimi, valida OK ja Next.
5. Authentication Mehtod valida Microsoft protected EAP (PEAP) ja valida Configure (sätted
määrata samad kui punktis manuaalne seadistamine).
6. Edasi valida Next ja Next ja Next ja Close.
7. Valida loodud VPN ning valida ülalt Deploy. Määrata Collection kuhu soovite VPNi installeerida.
Muud sätted võivad samaks jääda ning vajutada OK.
2.1.2 Proksi
Proksiserver on teenus, mis vahendab päringuid kliendi ja serveri vahel. Proksiserveri kasutamisel
saadab klient päringud proksiserverile ning see omakorda edastab need teenusele, teenus vastab
proksiserverile ning see saadab vastused kliendile tagasi.
Olenevalt proksitüübist on see kas kliendile näha või mitte. Enamasti ei ole kliendile näha, kas tema
päringud lähevad läbi proksi või otse selle taga oleva teenuse pihta. Proksi abil on võimalik päringuid
filtreerida ning vastavalt tulevale päringule ligipääs blokeerida, sellele midagi lisada või suunata
erinevate teenuste peale.
Olenevalt teenusest on erinevaid proksilahendusi, näiteks HTTPProxy vahendab HTTP või HTTPS
päringuid või jaotab neid mitme serveri peale (Load Balance). Exchange Client Access server pakub
autentimise ja proksi teenust postkasti serveritega suhtlemisel, selle puhul suunatakse kasutaja päringud
edasi sellele postkasti serverile, kus asub tema postkast.
HTTP proksi puhul on näiteks võimalik muuta ühendus teenusega turvalisemaks, kui vahendatav teenus
ei võimalda kasutada SSL ühendust. Proksile on võimalik lisada SSL sertifikaat ning seejärel kliendiga
suhtlemine käib üle turvalisema HTTPS’i, kuigi proksi suhtleb teenusega ikka üle HTTP. Teenustel, mis ei
logi piisava täpsusega sissetulevaid päringuid, saab proksit kasutada logitaseme tõstmiseks. Veel üks
võimalik kasutuskoht on portide efektiivsemal kasutamisel või teenuse maskeerimisel. Näiteks kui välise
ühenduse puhul on kasutada ainult üks IP aadress, siis saab proksi abil kasutada sama HTTPS porti
mitme erineva teenusega suhtlemiseks. Vastavalt sissetulevale päringule saab suunata erinevad
alamdomeene või aadresse erinevatesse kohtadesse või nendele ligipääsu piirata.
https://Teenus1.domeen.ee -> https://server1:443
https://teenus1.domeen.ee/teineteenus -> http://server1:8080
https://teenus2.domeen.ee -> http://server2:80
SOCKS on üldotstarbeline võrgupakettide vahendamise protokoll, kus proksi vahendab kliendi- ja
serverivahelist TCP ja UDP liiklust. See on väga levinud vahend üle SSH sisevõrgu teistele teenustele
ligipääsuks või veebibrauseri liikluse maskeerimiseks. SOCKS proksi eeliseks on see, et proksi töötab
mitmesuguste rakenduse taseme protokollidega nagu RDP, HTTP(S) või SQL. See võib olla dünaamiline,
see tähendab, et läbi sama proksipordi saab ligi kõikidele teenustele üheaegselt ilma neid teenuseid
eelnevalt eraldi kirjeldamata.
Sobiva proksitüübi valimist käsitleb ka ISKE M 2.75 ning selle integreerimist veebirakendustesse ISKE M
5.119.
Proksiserver pääseb ligi kõikidele andmetele päringutes, mida klient või server teevad. Nimelt kui klient
saadab päringu proksiserverile, siis proksiserver näeb täielikult selle sisu, võib selle vahepeal salvestada
või seda muuta ning alles siis originaali või muudetul kujul edasi saata. Sama kehtib serveri poolt tulnud
vastustega. Seega on väga oluline oma proksiserverit väga tugevalt kaitsta ning kolmandate osapoolte
proksiservereid vältida. Kui tegemist ei ole üldkasutatava teenusega, mis peab olema kõigile
kättesaadav, siis soovitame proksi asemel kasutada või sellega kombineerida VPN privaatvõrgu
lahendusi, sest siis ei ole avalikkusele näha isegi proksiserveri aadressi.
Ahvatlevad kolmanda osapoole proksiserverid on need, mis lubavad veebiliikluse muuta anonüümseks
valetades asukoha või kliendi brauseri sätete jms kohta – neid andmeid saab võltsida vaid päringuid
muutes, mis tähendab, et päringu sisu on proksiserverile täielikult näha.
2.1.3 Töökoha tulemüür
Töökoha tulemüür on tarkvara, mis kontrollib informatsiooni, mis tuleb internetist vm võrgust ja
vastavalt seadistusele lubab või keelab nende juurdepääsu arvutisse. Tulemüür aitab ennetada häkkerite
või pahatahtlikku tarkvara ligipääsemist tööjaama läbi võrgu või interneti. Tulemüür võimaldab takistada
ka pahatahtliku tarkvara saatmist teie arvutist teistesse arvutitesse või võrku.
Tööjaamade tulemüürid on mõeldud kliendi lokaalsete ressursside turbeks. Asutuse tulemüür kaitseb
asutuse võrku internetist tulevate rünnakute eest. Kuna tänapäeval on järjest rohkem kasutusel
kaasaskantavad seadmed, ei rakendata alati asutuse tulemüüri ja seetõttu on vajalik kasutada ka
seadmepõhist tulemüüri.
2.1.3.1 Windows tulemüüri seadistamine
Windows tööjaamas on võimalik tulemüüri seadistada vastavalt keskselt või käsitsi igas tööjaamas.
Tööjaama tulemüüri saab seadistada:
Keskselt serverist rühmapoliitikaga
Keskselt läbi System Center Configuration Manageri
Windows tulemüüri käsurealt Netsh
Käsustikust Powershell
Käsitsi tööjaamas
Osa kolmanda osapoolte tarkvarast võimaldab keskselt Windowsi tulemüüri hallata ja
seadistada.
2.1.3.1.1 Tulemüüri seadistamine keskselt rühmapoliitikaga
Server Managerist avada rühmapoliitika haldamine (Group Policy Management), lisada uus poliitika
„Tööjaamade tulemüür“ ja linkida see tööjaamade OUga. Avada poliitika sätted vahekaart ja muuta
sätteid. Editor tulbas avada Computer Configuration > Policies > Windows Settings > Windows Firewall
with Advanced Security. Lisatud näidis rühmapoliitika nimega 4_Andmete_haldus_Tööjaama tulemüür.
Esmalt lülitada tulemüür domeeni-, privaat- ja avalikes võrkudes sisse ja seadistada avalikes võrkudes
sissetulevad ühendused Blocked (default), rakenduvad tehtud reeglid. Lisaks seadistuste alt mitte lubada
lokaalsete reeglite kasutamist nii domeeni-, kui avalikes võrkudes. Domeenivõrgus on mõistlik keelata ka
kasutaja teavitamine, kuna üldiselt ei tea tavakasutaja nendest teadetest midagi ning pigem on nad
kasutajale häirivad.
Järgnevalt tuleks seadistada lubatud sisse ja välja võrguühendused, mida saab teha, valides vastavalt
Inbound rules ja Outbound rules.
Lisada uus reegel, soovitav on valida eelseadistatud reeglid ning vajadusel lisada erireeglid ja tarkvara
load. Reeglite tegemise võimalus valida programmipõhine, pordipõhine, eelseadistatud või kohandatud
reeglite vahel. Reegleid saab teha nii lubavaid kui ka keelavaid, kui mingid reeglid kattuvad, jääb alati
peale keelav reegel. Reegleid saab rakendada nii kõikide tüüpide võrkudele korraga või ainult kindlatele
(domain, private, public).
Domeenivõrgu reegleid seadistades oleks vajalik sisse lülitada järgnevad eeldefineeritud reeglid: Active
Directory Domain Services, Acvtive Directory Web Services, COM+ Network Access, DNS Services, File and
Printer Sharing, mDNS, Netlogon Service, Network Discovery, Remote Desktop ja Secure Socket Tunneling
Protocol. Lisaks on vajalik välja lubada kindlasti HTTPja HTTPS pordid, vajadusel ka SMTP port.
2.1.3.1.2 Seadistus konfiguratsiooni süsteemi keskjaama (System Center Configuration Manager)
kaudu
SCCM süsteemi kaudu on võimalik ka kontrollida ja seadistada Windows tulemüüri sisselülitamist, mis
võrkudes on sisse lülitatud, ei ole või siis defineerimata. Täpsemalt saab seadistamise kohta lugeda siit:
docs.microsoft.com/en-us/sccm/protect/deploy-use/create-Windows-firewall-policies (vt
Andmete_haldus_14.pdf). SCCM süsteemist on võimalik tulemüüri spetsiifilisemat seadistust teha
vajadusel Powershell skriptidega, millest tuleb juttu täpsemalt järgnevates peatükkides.
2.1.3.1.3 Seadistamine Windows tulemüüri käsurealt Netsh
Avada käsurida CMD ja näitena järgneva käsuga saab avada pordi:
netsh advfirewall add rule name=“nimi“ dir=in action=allow protocol=TCP/UDP localport=21
Vaikimisi lisatakse see reegel kõikidesse profiilidesse, kui on vajalik täpsustada, siis lisada
profile=public/private/domain. Süntaksi kohta saab siit lugeda siit: docs.microsoft.com/en-us/Windows-
server/networking/technologies/netsh/netsh-contexts (vt Andmete_haldus_12.pdf).
2.1.3.1.4 Seadistamine käsustikust Powershell
Powershelli käsurida pakub mugavamaid filtreid, kui graafiline kasutajaliides (GUI) ja lihtsamini
kasutatav kui Netsh. Powershell tuleb käivitada administraatori õigustes ja näitena järgneva käsuga saab
kõik tulemüüri reeglid mõne parameetriga: Get-NetFirewallRule. Ent üldiselt on reegleid palju ning
mõistlik on kasutada sorteerivaid parameetreid: Get-NetFirewallRule -Action Block -Enabled True -
Direction Inbound. Täpsemalt saab tutvuda siin: docs.microsoft.com/en-
us/Powershell/module/netsecurity/?view=win10-ps (vt Andmete_haldus_18.pdf).
2.1.3.1.5 Tulemüüri seadistamine tööjaamas
Vastavalt Windows tulemüüri omapärale on kõik sissetulevad ühendused blokeeritud, kui nad ei ole
lubatud listis ja kõik väljaminevad ühendused on lubatud, kui nad ei vasta teatud reeglile. Kui on mitu
reeglit, siis jääb alati peale keelav reegel. Tööjaamas käib tulemüüri seadistamine sarnaselt keskse
seadistuse tegemisele. Esmalt avada Windows tulemüür (Control Panel > Windows Firewall), kui ei ole
sisse lülitatud, siis lülitada sisse tulemüür kõikides võrkudes.
Kui programmid ei ole tulemüüri kaudu automaatselt lubatud, siis seda saab teha käskluse abil Allow an
app or feature through Windows Firewall, sealt saab lubada ja lisada programme või aplikatsioone, mis
peavad pääsema läbi tulemüüri.
Edasine peenhäälestus tuleb teha sätte Advanced Settings alt ja seejärel vastavalt juba eespool
kirjeldatud valikutele luua vajalikke reegleid.
Kui seadistada ühes tööjaamas tulemüür, siis on võimalik see eksportida ning teises tööjaamas
importida, võimalus importida isegi serveri rühmapoliitika (GPO) haldusesse, see lihtsustab ning
kiirendab üksikult tööjaamade seadistust.
2.1.3.2 Windows tulemüüri keskne haldamine kolmanda osapoolte tarkvaraga
Sellised lahendused tulevad tavaliselt mingi turvatarkvaraga kaasa ja on tasulised. Võimaldavad
kontrollida keskselt Windows tulemüüri jm võimalusi, sõltuvalt tarkvarast ja selle pakkujast. Näitena on
olemas pilvepõhine kaitsesüsteem F-Secure PSB (Protection Service for Business) Computer Protection ja
lokaalsetes serverites F-Secure Business Suite Client Security, mis mõlemad pakuvad keskset tööjaamade
Windows tulemüüri haldust, lisaks teisi kaitsemooduleid. Lahendus lisab täiustatud tulemüüri reeglid,
mis on läbinud turvatestid. Võrreldes Microsoft haldusega on neid lihtsam hallata ning seadistada,
samuti võimaldatakse kergemini erandeid teha. Täpsemalt saab tutvuda siin: www.F-
Secure.com/en/web/business_global/computer-protection ja www.F-
Secure.com/en/web/business_global/client-security.
2.1.4 Telemeetria
Vaikimisi sätetel on Windows 10 seadistatud saatma palju infot kasutajategevuse ning arvutitöö ja
seadistuse kohta (Telemeetria) Microsoftile. Turvalisuse seisukohast võib see sisaldada konfidentsiaalset
informatsiooni.
2.1.4.1 Windows 10 versioonid ja telemeetria piiramine
Windows 10 Enterprise (ka EDU) versioonides on võimalik telemeetriat seadistada Microsofti juhendite
järgi (docs.microsoft.com/et-ee/Windows/privacy/configure-Windows-diagnostic-data-in-your-
organization vt Andmete_haldus_13.pdf). Windows 10 Home versioonides ei ole telemeetria täielik
seadistamine võimalik, samuti ei ole Home versiooni võimalik liita domeeni ja on seega ettevõttele
sobimatu. Telemeetria takistamine muude vahenditega (näiteks tulemüür) ei ole soovituslik, sest samad
võrguaadressid omavad ka muid olulisi funktsioone nagu Windows uuendused.
2.1.4.2 Rühmapoliitika sätted
Järgnevad rühmapoliitika (Group Policy) reeglid on tuntumad, mis on seotud Windows 10 Telemeetria
ehk info saatmisega Microsofti ja mujale. Need tuleks määrata nii nagu antud või vajadusel kohandada
kui mõni nendest segab vajaliku rakenduse tööd. Lisatud näidis rühmapoliitika nimega
5_Andmete_haldus_Telemeetria.
Computer Configuration/Administrative Templates/Windows Components/Data Collection and
Preview Builds konfiguratsioonisäte:
Allow Telemetry:Enabled, 0 – security – Säte keelab igasuguse telemeetria peale turvalogide. Kui
ettevõttes kasutatakse näiteks Windows Error Reporting tõrgete lahendamisel või soovitakse
Microsofti poolt tuvastatud parandusi levinud tõrgetele, tuleks seda taset kohandada. Nende
tasemete kohta on rohkem informatsiooni Microsoft dokumentatsioonis:
docs.microsoft.com/en-us/windows/privacy/configure-windows-diagnostic-data-in-your-
organization (vt Andmete_haldus_13.pdf).
Computer Configuration/Administrative Templates/Windows Components/Windows Error Reporting
konfiguratsioonisäte:
Do not send additional data: Enabled
- Keelab täiendava kasutajainfo edastamise koos rakenduse veateatega (failid, kaustateed,
kasutajaandmed).
Computer Configuration/Administrative Templates/Control Panel/Regional and Language
Options/Handwriting personalization konfiguratsioonisäte:
Turn off automatic learning: Enabled
- Selle sätte määramisel ei kasutata enam kirjakeele õppimise mehhanisme ega saadeta kogutud
informatsiooni Microsofti serveritele. See tähendab ka seda, et käsikirja tuvastamine ei muutu
ajapikku paremaks.
Computer Configuration/Administrative Templates/System/User Profiles konfiguratsioonisäte:
User management of sharing user name, account Picture, and domain information with apps:
Enabled, Always off
- Keelab kasutajal anda loa rakendustel kasutada informatsiooni kasutajakonto kohta
Turn off the advertising ID: Enabled
- Keelab reklaami pakkujatel koguda informatsiooni kasutaja eelistuste ja näidatud ning avatud
reklaamide kohta ehk kasutaja profileerimise.
2.1.4.3 Rühmapoliitikata
Ilma rühmapoliitikata on enamikke sätetest peaaegu võimatu muuta. Paljud sätted ei ole
kasutajaliidesest seadistatavad või on peidetud sügavale seadistustesse, kust neid on raske leida. On
olemas kolmanda osapoole rakendusi millega on võimalik need sätted siiski mugavalt ühest kohast
keelata, näiteks O&O ShutUp10 (vt www.oo-software.com/en/shutup10), kuid selle ja sarnaste
rakenduste kasutamisel on risk, et keelatakse liiga palju ning eemaldatakse süsteemi tööks vajalikke
funktsioone. Nende rakenduste kasutamisel tuleb olla väga ettevaatlik.
2.1.4.4 Telemeetria muudes rakendustes
Windows ei ole ainus, mis telemeetriat rakendab, tihti on ka paigaldatavates rakendustes telemeetria
funktsioonid vaikimisi sisse lülitatud. Näiteks veebibrauserid Firefox ja Chrome annavad sellest teada
esimesel käivitamisel ning küsivad kas seda muuta või mitte. Kui kasutaja sellele tähelepanu ei pööra,
jäävad need vaikimisi sisse. Mistahes rakenduse paigaldamisel tuleks alati sätted üle vaadata ja muuta,
mida arendajatele saadetakse või vähemalt olla sellest teadlik. Rakenduste paigaldamisel keskselt tuleks
uurida, kas see säte on võimalik juba paigaldamisel paika panna ja võimalusel seda teha.
Paljud sätted on tänapäeval kasutajapõhiselt rakenduste vahel sünkroniseeritud (Chrome, Firefox ja
Windows) ning see säte võib olla eelmisest seadmest sünkroniseeritud, seega kui see kunagi on jäänud
tähelepanuta, hiljem seda enam ei pruugita üle küsida.
Paljud rakendused, mis on mõeldud ettevõtetes kasutamiseks, annavad võimaluse paigaldada vastavad
ADMX failid, et rühmapoliitikatega saaks sätteid muuta. Tuleks uurida, kas need on saadaval ja
võimalusel neid kasutada.
Eraldi paigaldatavad rühmapoliitika ADMX failid on olemas näiteks Microsoft Office, Google Chrome ja
Firefox rakendustele, täpsemalt on nende kohta kirjas peatükis 6.2.4 „Veebisirvija seadistamine
rühmapoliitikaga“.
2.2 Andmete haldus talletades
2.2.1 Failiserveri kaitse seadistus
Võrgukettad ja jagatud kaustad on tüüpilised kohad, mille kaudu ettevõtte sisevõrgus viirused levida
võivad. Jagatud kaustadele ja failidele pääsevad tavaliselt ligi väga paljud kasutajad ning seetõttu on risk
nende andmete hävimisele suur. Jagatud kaustad võiks jaotada väiksemateks osadeks või kogumiteks, et
need oleks rohkem üksteisest nii füüsiliselt kui õiguste poolest eraldatud, näiteks osakonna järgi. Õigusi
tuleks määrata grupipõhiselt, et neid oleks võimalikult lihtne eemaldada ning põhimõttel „mida vähem,
seda parem“. Lisaks üldisele õiguste süsteemile, mida käsitleb näiteks ISKE M 4.332, tuleks kasutada
dünaamilisi ja automaatseid reegleid, mis rakenduvad teatud tingimustel. Üks vahend selle
saavutamiseks Windows serverites on failiserveri ressursihaldur (File Server Resource Manager, FSRM).
Lisaks takistatavatele vahenditele ei tohiks unustada korralikku varundust. Väga oluline on ka keelata
aegunud ning teadaolevate turvanõrkustega protokollid - näiteks SMB v1.
2.2.1.1 Failiserveri ressursihaldur (FSRM)
Failiserveri ressursihaldur (FSRM) on vahend failiserveri jagatud kaustade haldamiseks ning
automaatsete reeglite ja filtrite loomiseks. FSRM võimaldab seadistada faili mahu ja tüübiga seotud
reegleid ning rakendada automaatikat kindlate filtrite alusel. Näiteks piirata kasutajal salvestada teatud
tüüpi faile või mahupiirangu täitumisel saata e-kirju.
2.2.1.2 Kaitse krüptoviiruste vastu failiserverites
FSRMi on võimalik kasutada krüptoviiruste tegevuse takistamiseks. Põhimõte seisneb teatud failitüüpide
salvestamise katsel kasutaja täielikku blokeerimist jagatud andmetele. Seadistuste lihtsustamiseks on
olemas kolmanda osapoole skriptid ja nimekirjad teadaolevatest krüptoviirustega seotud failitüüpidest
ja nimedest. See lahendus ei takista krüptoviiruste levikut teistele arvutitele vaid takistab sellel rikkuda
jagatud faile. Levinuim kolmanda osapoole vahend seadistuste lihtsustamiseks on “CryptoBlocker”
nimeline Github projekt (vt Github.com/m-dwyer/CryptoBlocker, vt Andmete_haldus_15.pdf), kuid võib
ka seadistada käsitsi ja luua oma skritpid.
2.2.1.2.1 Paigaldamine ja seadistamine
Eeldused skriptide kasutamiseks vanematel kui Windows Server 2016 operatsioonisüsteemidele:
Windows Management Framework version 5 või uuem
Paigaldamise protseduur:
1. Paigaldada FSRM kas Server Manager kaudu või Powershell käsuga:
Install-WindowsFeature –Name FS-Resource-Manager –IncludeManagementTools
2. Tee serverile kaks taaskäivitust, muidu ei pruugi hakata FSRMi Powershell käsud tööle.
3. Meilisätete seadistamiseks teha paremklõps FSRM (Local) peal ja valida “Configure Options…” ja
täita väljad
4. Notification liimits määrata kõik 1 peale, et tuleks kohale kõik teated.
5. Lisada uus File Group näiteks "CryptoBlocker". Lisada vähemalt üks filter, et saaks grupi tekitada.
6. Luua uus File Screen Template.
a. Name - "CryptoBlocker".
b. Valida Active
c. Valida File groups "CryptoBlocker"
d. Seadistada e-kirja saatmine administraatorile (e-mail message to [Admin e-mail]).
E-kirja sisu võib soovi korral muuta.
Muutujad asendatakse kirjas vastavalt tehtud template’dele.
7. Lisa Command:
Run this command or script:
C:\Windows\System32\WindowsPowershell\v1.0\Powershell.exe
Command Arguments:
-ExecutionPolicy Unrestricted -NoLogo -Command "& { Get-SmbShare -Special $false | ForEach-
Object { Block-SmbShareAccess -Name $_.Name -AccountName '[Source Io Owner]' -Force } }"
8. Luua uus File screen. Kasuta malli CryptoBlocker ja määra, millist kausta see jälgima peab.
Sellega on seadistused tehtud ning kausta jälgimine ja kasutajate blokeerimine aktiivne.
Kui keegi proovib jagatud kausta lisada midagi, mis on File Groupis kirjeldatud, saab ta ligipääs keelatud
(Access Denied) teate, määratud admin-meilile peale saadetakse teade ja kasutaja blokeeritakse
failiserverist.
Uute laiendite lisamiseks tuleks minna tagasi punkti 5, lisada uusi laiendeid või seadistada eraldi
nimekirjad, mida skriptide abil automaatselt uuendatakse. Näiteks võib teha .txt faili ning selle
importida.
$FGroup = Get-Content „fsrm.txt“
Set-FsrmFileGroup -name „CryptoBlocker”-IncludePattern @($FGroup)
2.2.1.2.2 Automaatne nimekirjade uuendamine
Automaatne nimekirjade uuendamine toimub skripti ja seda käivitava ajastatud tööna, nimekiri laetakse
alla Internetist https://fsrm.experiant.ca/ lehelt.
Nimekirja täiendatakse pidevalt ning seda on oluline jälgida. Kui Internetist pidevalt uueneva nimekirja
allalaadimist enam ei soovita, võib taski keelata ning nimekirja käsitsi edasi täiendada. Seda ei ole
võimalik teha läbi graafilise liidese, sest viimane ei luba sisestada nimekirjas juba olevaid ega luba
seetõttu salvestada. Täiendusi tuleb teha Powershelli abil.
Nimekirjas on ka palju levinud tavaprogrammide kasutatavaid faililaiendeid ja tuleks arvestada, et
kasutajad võidakse nende kasutamisel blokeerida ning sellisel juhul on vaja teha erandeid. Õnneks on
failinimi juba administraatorile saadetavas kirjas näha ja seda on lihtne lisada.
Failinimede erandeid ja lisasid saab hallata muutes CryptoLockerSkipList.txt.
Skripti seadistamine:
1. Kopeerida skript „cryptoblocker-fsrm-update.ps1“ näiteks C:\Windows kausta või mujale.
Kopeerides muuta skriptis SkipList asukoht vastavalt.
2. Importida või teha ajastatud töö selle käivitamiseks. Ajastatud töö käivitavaks kasutajaks valida
SYSTEM või teha selleks teenuskonto.
Trigger: olenevalt vajadusest kord nädalas, kord päevas kindlal kellaajal või soovi korral
tihedamini.
Action:
Program/Script: Powershell
Add arguments:
-ExecutionPolicy Unrestricted -NoLogo -file "c:\Windows\cryptoblocker-fsrm-update.ps1"
3. Käivitada task ja jälgida, et exit code oleks (0x0) ehk success ning FSRM’i tekiks laiendid.
2.2.1.2.3 Kasutaja blokeeringu eemaldamine
Juhul, kui mõni kasutaja antud lahendusega blokeeritakse, saab blokeeringu eemaldada käsuga:
Get-SmbShare -Special $false | ForEach-Object { Unblock-SmbShareAccess -Name $_.Name -
AccountName ‘ACCOUNT NAME TO UNBLOCK’ -Force }
Selle lihtsustamiseks võib kasutada ka skripti „cryptoblocker-release-user.ps1"
Skript tuleb käivitada administraatorina, muutes selles eelnevalt ära share nime
$Perms = Get-SmbShareAccess -name <share name>.
2.2.2 Krüpteerimine
Kõigil füüsiliselt turvatud tsoonist väljaviidavatel (nt kodus töötamiseks kasutatavatel) sülearvutitel on
kohustuslik kasutada kogu kettasisu krüpteerimist.
Krüpteerimistarkvaral ei tohi olla turvaauke, mis võimaldavad parooli teadmata ja/või autentimisseadet
omamata juurdepääsu mistahes andmetele sülearvuti kettal.
2.2.2.1 Bitlocker
Tegemist on Microsoft Windowsi (alates Windows Vista versioonist) kaasatuleva funktsionaalsusega
terve volüümi krüpteerimiseks. Kasutakse AES krüpteerimist algoritmi mudelitega cipher block chaining
(CBC) või XTS 128-bitise või 256-bitise võtmega.
2.2.2.1.1 Seadistamine
Seadistamiseks on vaja kasutada Windows 10 Pro või Enterprise versiooni (Home versioon ei toeta).
Tulenevalt kasutatavast riistvarast on seadistamiseks võimalikud kombinatsioonid autentimiseks:
TPM kiibiga (alates versioonist 1.2) – ei vaja kasutaja sekkumist
TPM + PIN kood – kasutaja peab lisaks sisestama PIN-koodi
TPM + Võrgu võti – ei vaja kasutaja sekkumist
TPM + startup parool – kasutaja peab sisestama parooli
Startup parool – juhul kui puudub TPMi kiibi tugi ja kasutaja peab sisestama parooli.
Bitlocker võimaldab krüpteerida kas kogu kettapinna või ainult kasutuses oleva kettaruumi. Esimesel
juhul on protsess aeganõudvam, kuid turvalisem. Teisel juhul toimub krüpteerimisprotsess kiiremini,
kuid ei ole nii turvaline.
Bitlockeriga saab krüpteerida süsteemikettaid ja ka andmekettaid. Kuna Bitlocker loob boot faili
süsteemi boot volüümile, siis andmeketastel on valik juurde teha uus volüüm, kus vajalik BdeHdCfg.exe
bootfail talletada.
Bitlockeri taastevõtit/infot on võimalik seadistada sõltuvalt organisatsioonist ja seal kasutatavast
süsteemist:
Taastevõti talletatakse serveris AD arhitektuuris
Taastevõti talletakse mingil teisel kettal: võrguketas, USB-seade (soovitatav kaaluda nende
turvalisust/ligipääsetavust) – ei saa salvestada krüpteeritavale kettale.
2.2.2.1.1.1 Serverid ja kliendid AD arhitektuuriga
Bitlockerit saab integreerida Active Directory Domain Services’ga, mis pakub keskset võtmehaldust.
Vaikimisi ei ole taastamise info Active Directorysse seadistatud, kuid seda on võimalik seadistada.
Esmalt tuleb AD serverisse vajalikud moodulid paigaldada, seda on võimalik teha kas graafilise liidesega
või Powershelli käsurealt (nt kui on kasutusel Core versioon serverist).
2.2.2.1.1.1.1 Paigaldamine Windows serveri graafilises liideses
Server Manageri alt valida Add Roles and Features ja paigaldada features Bitlocker Drive Encryption
2.2.2.1.1.1.2 Mooduli paigaldamine Powershelli käsurealt
Saab paigaldada Sever Manageri või DISM mooduliga:
Install-WindowsFeature Bitlocker -IncludeAllSubFeature -IncludeManagementTools -Restart
Või
Enable-WindowsOptionalFeature -Online -FeatureName Bitlocker, Bitlocker-Utilities –All
2.2.2.1.1.1.3 Rühmapoliitika seadistamine, et Bitlockeri taaste info säilitataks Active Directorys
Esmalt avada serveris Group Policy Management (gpmc.msc) ja luua sinna uus poliitika sellele OUle, mis
sisaldab soovitud tööjaamu. Lisatud rühmapoliitika näidis nimega 6_Andmete_haldus_Bitlocker.
Poliitika võib näiteks nimetada „Bitlocker“ ning siis muuta poliitikas järgnevas asukohas Computer
Configuration->Policies->Administrative Templates->Windows Components->Bitlocker Drive Encryption->
Store Bitlocker Recovery information in Active Directory Domain Services
Sisse lülitada seadistus ning valida Bitlocker recovery information to store: Recovery passwords and key
packages
Seejärel valida süsteemi ketta alt (Operating System Drives) ja/või andmete ketta alt (Fixed Data Drives)
ning lülitada sisse järgmine seadistus: Require additional authentication at startup. Seadistada arvuti
käivitamisel parooli või USB-võtme küsimine, kui Bitlockeri jaoks ei ole sobivat TPM kiipi. Edasi määrata
järjekord, kui autentimine toimub TPM kiibi olemasolul.
Seejärel seadistada parameeter Choose how Bitlocker-protected operating system drives can be
recovered, lubada see ning lisada linnukesed sätetele, et lubada andmete taastamise agent ning
Bitlockeri taaste info säilitatakse AD DS (Save Bitlocker recovery information to Active Directory Domain
Services) ja Bitlokcerit ei lülitata sisse enne kui info on AD DSis olemas (Do not enable Bitlocker until
recovery information is stored to AD DS for operating system drives).
Soovitav on lubada ka täielik ketta krüpteerimine Enforce drive encryption type on operating system
Drives.
Edasi on vajalik krüpteerimise sisselülitamine tööjaamades, mida saab samuti teha näiteks
rühmapoliitikaga ja skriptiga, mis käivitab käsu:
manage-bde -on c: -rp
2.2.2.1.1.2 Seadistamine kliendis ilma AD-ta
Tulenevalt kasutatavast riistvarast on seadistamiseks võimalikud kombinatsioonid autentimiseks:
ainult TPM kiibiga (alates versioonist 1.2)
TPM + PIN-kood
TPM + parool
Parool (juhul kui riistvaral ei ole TPM kiibi tuge)
Bitlockeri krüpteeringut on võimalik sisse lülitada järgnevate meetoditega:
Bitlockeri juhtpaneelist
Windows Explorerist
Manage-bde käsurea liidesest (kuni Windows 8.1)
Bitlockeri Powershelli käsurealt
2.2.2.1.1.2.1 Bitlockeri seadmistamine Windows 10 juhtpaneelist
Kogu juhtpaneel
Bitlocker ketta krüpteerimine
Lülitada sisse Bitlocker
Seejärel luua parool ja salvestada taastevõti. Võtit ei saa salvestada krüpteeritavale kettale. Soovitatav
on see salvestada välisele USB pulgale, mis on omakorda krüpteeritud.
Valida kogu ketta krüpteerimine (soovitatav), on võimalik krüpteerida ka ainult kasutatud kettapind.
Viimane valik pole soovitatav, kuna kustutatud failid paigutatakse ketta krüpteerimata osale ning
senikaua kuni need ei ole üle kirjutatud, saab neid taastetööriistadega taastada.
Edasi alustada krüpteerimist.
Krüpteerimise mahavõtmiseks tuleb Bitlockeri juhtpaneelist valida selle väljalülitamine.
2.2.2.1.1.2.2 Bitlockeri seadistamine Windowsi Explorer aknast
Windows võimaldab otse Exploreri aknast paremklõpsuga soovitud kettal ketta krüpteerimise sisse
lülitada. Edasised valikud on samad nagu eelpool olevas punktis kirjeldatud.
Samuti on võimalik krüpteerimine paremkõpsuga välja lülitada.
2.2.2.1.1.2.3 Manage-bde käsurea liidesest
Näidis krüpteerimise lubamiseks TPM kiibiga:
manage-bde -on C:
Täpsemat teavet süntaksi ja käskude kohta saab siit: https://docs.microsoft.com/en-us/previous-
versions/Windows/it-pro/Windows-server-2012-R2-and-2012/ff829849(v=ws.11) (vt hardcopy
Andmete_haldus_16.pdf)
Sama käsurea liides võimaldab ka deaktiveerida:
manage-bde -off C:
2.2.2.1.1.2.4 Bitlockeri Powershelli käsurealt
Avada Powershelli käsurida ja käsuga Enable-Bitlocker C: saab aktiveerida Bitlockeri krüpteerimise,
täiendavate parameetritega saab tutvuda siin: https://docs.microsoft.com/en-
us/Powershell/module/Bitlocker/?view=win10-ps (vt hardcopy Andmete_haldus_17.pdf)
Powershelli Bitlockeri liides võimaldab krüpteerimist ka maha võtta: Disable-Bitlocker
2.2.2.1.1.2.5 Bitlockeri aktiveerimine ilma TPM kiibita arvutis
Selleks, et ilma TPM kiibita arvutis Bitlockeri krüpteerimist aktiveerida, on vaja teha muudatused Local
Group Policy Editoris:
Muudatused tuleb teha järgmises kohas: Computer Configuration -> Administrative Templates ->
Windows Components -> Bitlocker Drive Encryption -> Operating System Drives
Avada Require additional authentication at startup, lubada ja lisada linnuke Allow Bitlocker without a
compatible TPM (requires a password or a startup key on a USB flash drive).
Nüüd saab Bitlockeri paneelis krüpteerimise sisse lülitada, lahtilukustamiseks saab kasutada USB pulka
või parooli. Soovitav on kasutada USB pulka, kuna see on kasutaja jaoks mugavam kui veel ühe parooli
meeldejätmine. Edasine on eespool kirjeldatud.
2.2.2.2 Bitlocker To Go
Tegemist on Bitlockeri krüpteerimisega eemaldatavate ketaste nagu USB ketaste, SD kaartide, väliste
kõvaketaste ning teiste NTFS, FAT16, FAT32 või exFAT failisüsteemi ketaste puhul. Kettad, mis on
krüpteeritud Bitlocket To Go-ga, saab avada parooli või smart cardi kasutades Bitlocker ketta
krüpteerimise juhtpaneelis.
Seadistamine käib samuti Windows 10 juhtpaneelist, valides Bitlocker Drive Encrytion ning järgnevalt
soovitud välise andmeketta puhul Turn on Bitlocker.
Edasise valikuga määratakse, kas dekrüpteerimiseks kasutatakse parooli või smart cardi ja kuhu
taastevõti salvestatakse.
Järgnevalt valida kogu ketta (või ainult kasutatud osa) krüpteerimine ning New encryption mode
(Windows 10), vanemate süsteemide jaoks saab valida ka Compatible mode. Seejärel alustada
krüpteerimist.
Bitlockeri poliitikat saab määrata ka keskselt rühmapoliitikaga, täpsemalt saab selle kohta lugeda siit:
https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-group-
policy-settings (vt hardcopy Andmete_haldus_19.pdf).
2.2.2.3 Alternatiivid
Üks open-source lahendus on VeraCrypt, mis võimaldab terve ketta krüpteerimist ja on toetatud alates
Windows XP versioonist. Tegemist on kunagise TrueCrypt koodi edasiarenduse ja täiendusega.
Seadistamise kohta saab täpsemalt lugeda siit: https://www.howtogeek.com/howto/6169/use-
truecrypt-to-secure-your-data/ (vt hardcopy Andmete_haldus_20.pdf).
Üks tasuline variant on näiteks McAfee Complete Data Protection, mis võimaldab Bitlockeri halduse
enda McAfee ePO alla võtta ning importida juba Bitlockeriga kaitstud ketta taastevõtmeid ja
lisavõimalusi. Lähemat teavet saab siit: https://www.mcafee.com/enterprise/en-us/products/complete-
data-protection.html
AxCrypt võimaldab 256-bitist AES krüpteerimist, selle haldus on pilvepõhine ning sisaldab lisaks mitmeid
funktsionaalsusi, näiteks Password Manager. Täpsemalt saab lugeda siit:
https://www.axcrypt.net/information/features/
2.2.3 BIOS/ EFI paroolikaitse ja olulisemad seadistused
Tööjaamade turvalisuse tagamiseks on oluline seadistada arvutite BIOS selliselt, et kolmandatel
osapooltel poleks võimalik kasutaja failidele ega ettevõtte võrgule ligi pääseda.
Kui BIOS parool on seadistamata, saab arvuti käivitada mõnelt väliselt andmekandjalt. Kui puudu on ka
Bitlocker, pääseb väliselt andmekandjalt laetud operatsioonisüsteemist kasutaja failideni ning saab
muuta süsteemi sätteid, tekitada kasutajaid ja võtta administraatori õigused.
NB! Arvuti riistvara peaks olema selline, millel ei ole võimalik ka füüsiliselt BIOS sätteid taastada ega
BIOS parooli eemaldada, st et arvuti emaplaadil ei tohiks olla nuppe ega kontakte, mis võimaldaksid seda
teha.
Bitlocker seadistamine koos BIOS parooli ning alglaadimise järjekorraga (boot order) tagab tõkke ketta
failisüsteemile ning takistab sellel olevate failidega manipuleerimist. Soovimatute muudatuste
vältimiseks saab teha mõned BIOS muudatused:
1. Panna peale BIOS parool – siis ei saa kolmandad isikud muuta arvuti alglaadimise järjekorda.
2. Kasutada Legacy asemel (U)EFI laadimist– sellisel juhul ei ole alglaadimise järjekorda vaja ühtegi
seadet peale Windows Boot Manager kirje.
3. Lubada ja kasutada Secure Boot funktsionaalsust. Selle nõudeid ning täpsemat kirjeldust saab
lugeda Microsoft dokumentatsioonist: https://docs.microsoft.com/en-us/windows-
hardware/design/device-experiences/oem-secure-boot (vt hardcopy Andmete_haldus_21.pdf).
4. Võimalusel eemaldada alglaadimise järjekorrast kõik teised seadmed peale arvuti kõvaketta.
Uuemad arvutid suudavad (U)EFI abil laadida ka Windows operatsioonisüsteemi, isegi kui arvuti
kõvaketas ei ole alglaadimise järjekorras. Sellise seadistuse puhul ei saa arvutit enam ühegi teise
kõvaketta ega välise seadmega käivitada ega sellele ühtegi tarkvara ka ketta vahetuse puhul paigaldada
– arvuti muutub kolmandatele osapooltele täiesti kasutuskõlbmatuks.
BIOS kaudu saab keelata ka arvutite porte ning väliseid seadmeid. Ka need tuleks seadistada vastavalt
vajadustele.
Kõige täpsema juhendi nende seadistuste tegemiseks leiab emaplaadi tootja kasutusjuhendist.
Tüüpiliselt on nende seadistuste nimedeks: Boot Order, Master Password, Boot options, Supervisor
Password jms.
BIOSi pääsemine:
Üldjuhul pääseb arvuti BIOSi, kui käivitamisel olenevalt mudelist vajutada F2, F8, DELETE või ENTER.
Tihti on see ka arvuti käivitamisel mõnes servas näha, näiteks Lenovo puhul:
ENTER klahvi vajutamisel kuvatakse menüü, kus on näha, et BIOS sätete muutmiseks on vaja vajutada
F1.
BIOS sätetest saab muuta erinevaid arvutiseadistusi. Antud juhul on olulised Boot order ja type, mis
asuvad Lenovo puhul Startup lehel. Boot asub siin :
Selle avamisel kuvatakse alammenüü, kus saab tekitada soovitud järjekorra ja sellesse kirjeid lisada või
neid sealt eemaldada.
Ideaalne järjekord, kui arvuti seda lubab, on järgmine:
ESC klahviga tagasi minnes saab seadistada Security menüü alt Supervisor Password.
Samas asukohas on ka Secure Boot valik, kui arvuti seda toetab.
2.3 Andmete haldus pilves
Tänapäeval on pilveteenuste osakaal suurenenud – teenuste valik on laienenud ning pilveteenuste
algusaastatel esinenud probleemid (teenuse kättesaadavus, kiirus, stabiilsus ja turvalisus) on
vähenenud. Väiksematel asutustel on mõistlikum kasutada kõigi vajalike teenuste (meiliserver,
majandustarkvara, failiserver jms) jaoks pakutavaid pilveteenuseid, sest siis ei ole vaja eraldi serverit,
mis vajab hooldust ning haldamist.
Pilveteenused on kolme põhilist tüüpi IAAS, PAAS ja SAAS (vt ka ISKE M_4.462).
IAAS (Infrastructure as a Service) ehk infrastruktuur teenusena. IAAS puhul tagab pilveteenuse pakkuja
füüsilise infrastruktuuri (serverid, kettamassiivid, virtualiseerimisplatvorm, võrk jms) ning teenuse ostja
saab sinna luua oma serverid ning vastutab ise kõigi serverisiseste ressursside eest (OS, rakendused,
rakenduse andmed jne). Hinnastamine toimub tavaliselt tarbitud teenuse (kettakasutus, võrgukasutus,
mälukasutus jne) alusel. IAAS teenused on näiteks Microsoft Azure, Amazon AWS, Google Cloud
Platform jt.
PAAS (Platform as a Service) ehk platvorm teenusena. PAAS puhul haldab pilveteenuse pakkuja lisaks
füüsilisele infrastruktuurile servereid ka OS tasemel. Teenuse ostja saab tellida erinevaid rakendusi ja
neid seadistada kas teenuste või API kaudu ning hallata rakenduse andmeid. Kõik muu on
teenusepakkuja hallata. Hinnastamise aluseks on tavaliselt tarbitud teenus ja lisaks ka vahekihi haldus.
PAAS vähendab halduse keerukust, samas seab piirid seadistamisele. PAAS teenuse pakkujad on
tavaliselt samad kui IAAS teenuse pakkujad.
SAAS (Software as a Service) ehk tarkvara teenusena. Sellisel juhul pakub pilveteenuse pakkuja mingit
rakendust, mis on tema pilveplatvormil majutatud. Sellisel juhul on kogu alusplatvorm (füüsiline
infrastruktuur, serverid, alusrakendused nagu andmebaasid jne) teenusepakkuja hallata ning tarbija
saab kasutada ja mingil määral hallata rakendust ning rakenduse andmeid. Hinnastamismudel - tavaliselt
on kasutusel kasutajapõhine fikseeritud hind, st teatud hinna eest saab kasutaja teenuse teatud
funktsioone kokkulepitud mahus kasutada. SAAS näiteks on erinevad e-maili teenused (Office 365,
Zone), majandustarkvara (Directo, Erply, Hansaworld pilv), CRM jne.
Sobiv pilveteenus tuleb valida vastavalt asutuse vajadustele ning avalike asutuste puhul lähtuvalt riigi
seadusandlikest nõuetest ja teenuse võimalusest neile nõuetele vastata. Täpsemalt saab pilveteenuse
kasutuselevõtu soovitustest lugeda ISKE moodulist B 1.17. Ka RIA on selle teema kohta juhendi
koostanud: https://www.ria.ee/sites/default/files/content-editors/ISKE/avalike-pilvede-kasutamise-
juhend.pdf (vt hardcopy Andmete_haldus_22.pdf).
2.3.1 Pilveteenuse riskid ja turvalisus
Põhilised riskid pilveteenuste kasutamisel on järgnevad:
1. Teenuse kättesaadavus - looduskatastroofid, teenuse seadistamise teenusepakkuja poolne viga,
teenusepakkuja pankrot vms võivad põhjustada olukorra, kus teenus pole kättesaadav ning
teenuse tellijal pole olukorra parandamiseks võimalik midagi teha. Näiteks:
https://www.bleepingcomputer.com/news/microsoft/microsoft-365-suffers-massive-two-day-
outage-outlook-and-exchange-down/ (vt hardcopy Andmete_haldus_23.pdf).
2. Kontode turvalisus – kasutajate haldus võib toimida teistmoodi ning korraliku kasutajapoliitika
puudumisel võib kasutajatele jääda liiga palju õiguseid või töölt lahkudes säilida ligipääs. Kuna
teenused on pilves, on need tavaliselt kõikjalt kättesaadavad ning häkkeritele ja pahatahtlikele
inimestele kergem sihtmärk. Näiteks: https://thehackernews.com/2019/04/microsoft-outlook-
e-mail-hack.html (vt hardcopy Andmete_haldus_24.pdf).
3. Andmeleke – kuna teenused asuvad sama alusinfrastruktuuri peal, on võimalik, et keegi proovib
pahatahtlikult oma virtuaalkeskkonnast teiste klientide teenustele ligi pääseda või see juhtub
mõne seadistuse vea tõttu.
4. Andmekadu – looduskatastroofid, seadistuse vead või pahatahtlik tegevus võivad viia olukorrani,
kus kõik andmed lähevad kaduma ja neid ei ole võimalik enam taastada. Näiteks
https://krebsonsecurity.com/2019/02/e-mail-provider-vfe-mail-suffers-catastrophic-hack/ (vt
hardcopy Andmete_haldus_25.pdf).
Mida vähem on võimalusi teenuseid hallata, seda vähem on võimalusi ka turvalisuse sätteid seadistada.
IAAS puhul on võimalik loodud serveri sätteid seadistada nagu tavalise Windows serveri puhul ja
tavaliselt ka ligipääse hallata, et server oleks kättesaadav ainult sisevõrgust näiteks üle IAAS
teenusepakkuja ning asutuse vahelise IPSec tunneli. Tavaliselt on seda võimalik seadistada ka PAAS
puhul, kuid SAAS on üldjuhul üle võrgu kõigile kättesaadav ja kõige suurem seadistusvõimalus on see, et
saab nõuda SSL ühendust ning kaheastmelist autentimist.
Üldised soovitused pilveteenuse turvaliseks kasutamiseks on:
1. Peale sobiva pilveteenuse valikut luua poliitikad, mis määravad, kuidas andmeid säilitatakse,
kuidas käib kasutajate haldus, kuidas käib üldine haldus, milliseid teenuseid kasutatakse jne.
2. Andmevahetus asutuse ja pilveteenuse vahel peab toimuma üle turvalise kanali. IAAS ja PAAS
lahenduse puhul soovitame ligipääsu piirata üksnes liiklusega sisevõrgust ja nii, et see toimuks
võimalusel kahe asukoha vahel üle IPSec tunneli. Kui teenustel on avalik veebiliides, siis sinna
ligipääs peab olema üle HTTPS-i. Ka teenuse haldusliidese ligipääs peab kindlasti olema üle
HTTPS-i. Kui HTTPS-i sertifikaati on võimalik ise seadistada, siis tuleb valida selleks
üldusalduväärne sertifikaat (osad lahendused võivad seda ka kohe nõuda), aga suuremal osal
juhtudest on sertifikaat teenusepakkuja määratud.
3. Võimaluse korral seadistada paroolipoliitika vastavalt oma asutuse nõuetele. IAAS puhul saab
majutuses olevatele Windows serveritele paroolinõudeid samamoodi rakendada kui lokaalsetele
serveritele. Ka PAASil on tavaliselt rohkem seadistusvõimalusi vastavalt rakenduste
võimalustele, kuid SAASi võimalused on tihtipeale piiratud ja on võimalik, et paroolipoliitikat ei
saa tehniliselt rakendada või peab kasutama üldiseid nõudeid, mis on teenusepakkuja poolt
määratud (kindlad paroolinõuded antud tarkvara puhul, parooli aegumist ei saa nõuda jne). Kui
automaatset parooli muutmist ei ole võimalik seadistada, tuleb seda kasutajatele meelde
tuletada ning parooli muutmist nõuda. Eriti tähtis on see kasutajate puhul, kellel võib olla
rakenduses rohkem õigusi, näiteks peakasutaja, süsteemiadministraator jne.
4. Kui ligipääs pilveteenusele käib üle avaliku Interneti, peab MFA olema sisse lülitatud nii
administraatorkasutajatel kui tavakasutajatel juhul, kui teenusele proovitakse ligi pääseda
väljastpoolt lubatud seadmeid. Domeeniarvutis ei pea tavakasutaja MFA-d kasutama, aga kui ta
üritab ligi pääseda koduarvutist, peab see olema kohustuslik. Vt täpsemalt peatükk MFA.
5. Lülitada välja funktsionaalsused, mida pole vaja. Pilveteenustel võib vahel olla funktsionaalsusi,
mida vaja pole. Eriti esineb seda SAAS puhul (näiteks Office 365 IMAP/POP3). Sellisel juhul tuleks
need võimalusel välja lülitada, sest kui neid ei kasutata, võidakse need unustada. Nende
turvanõuded võivad olla ka väiksemad, nende kaudu võivad olla avatud ligipääsud, mis mujalt on
kinni ning seetõttu on sellised funktsionaalsused pahatahtlikele inimestele atraktiivne
ründekoht.
6. Andmeid kuhugi lokaalselt varundada. Kuna pilveteenuste riskid on seotud teenuse
kättesaadavuse ja andmete kaoga, on tähtis, et andmeid varundatakse ka kusagile lokaalselt, et
teenuse rikke korral oleksid need kättesaadavad ja taastatavad.
2.3.2 Office 365 ja G Suite
SAAS pilveteenuste puhul on väga populaarsed erinevad lahendused, mis pakuvad kasutajatele
võimalust oma andmeid pilves hoida, neid teiste kasutajatega jagada ning ka koos faile muuta.
Ettevõtetes on laialdaselt kasutusel Office 365 ja G Suite, mis pakuvad pilves andmete hoidmist,
koostöövõimalusi ja e-maili (lisaks on tuntud ka Dropbox, iCloud, Nextcloud jne).
Andmete hoidmiseks ja jagamiseks pakub Office 365 rakendusi nagu OneDrive for Business, Microsoft
Teams ja Sharepoint Online. Nii OneDrive kui ka Microsoft Teams asuvad Sharepoint Online’l.
G Suite pakub andmete hoidmiseks ja jagamiseks Google Drive’i ja Team Drive’i.
Nende lahenduste turvalisuse hindamisel tasub mõelda järgmistele teemadele:
1. Paroolipoliitika.
Ka Office 365 ja G Suite teenuste kasutamiseks tuleks rakendada samad paroolinõuded kui
lokaalsetes süsteemides. Võimalik, et parooli keerukust tasub suurendada, sest teenuste ligipääs
on kõikjalt, mis tähendab, et teenused on kergem sihtmärk rünnakutele. G Suite paroolinõuete
kehtestamise juhend: https://support.google.com/a/answer/139399?hl=en (vt hardcopy
Andmete_haldus_26.pdf). Office 365 ja Azure AD paroolipoliitika on kindlalt määratud
https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy (vt
hardcopy Andmete_haldus_27.pdf) ning muuta saab ainult parooli aegumisega seonduvat.
Selleks, et paroolipoliitika oleks üle võrgu ühtlasem, soovitame siduda lokaalse AD kontod Office
365 või G Suite kontodega. Office 365 ja lokaalse AD kontod saab sünkroniseerida Azure AD
Connect tööriistaga https://www.codetwo.com/admins-blog/how-to-sync-on-premises-active-
directory-to-azure-active-directory-with-azure-ad-connect/?sts=4112 (vt hardcopy
Andmete_haldus_28.pdf). G Suite ja lokaalse AD kontod saab sünkroniseerida kasutades GSPS
tööriista https://support.google.com/a/answer/2611842?hl=en
Nii Office 365 kui ka G Suite puhul soovitame kõrgemate õigustega kasutajatel sisse lülitada
mitmeastmeline autentimine:
1. Office 365 juhend https://docs.microsoft.com/en-us/Office 365/admin/security-and-
compliance/set-up-multi-factor-authentication?view=Office 365-worldwide (vt hardcopy
Andmete_haldus_29.pdf)
2. G Suite juhend
https://support.google.com/cloudidentity/answer/175197?hl=en&ref_topic=2759193&visit
_id=636908479939567405-1025730311&rd=1 (vt hardcopy Andmete_haldus_30.pdf)
2. Failide ligipääsu ning jagamise õigused.
Failide pilve laadimisel tuleb ka failiõigused samamoodi planeerida kui lokaalses serveris. Samuti
tuleb arvestada teiste kasutajatega jagamise õigustega, mis kasutajatel on. Office 365 ja G Suite
puhul võivad kasutajad faile, millele nad ligi pääsevad, jagada kõigile ka nii, et sisselogimist ei ole
vaja. Juhend nende sätete muutmiseks on siin: https://docs.microsoft.com/en-
us/OneDrive/manage-sharing (vt hardcopy Andmete_haldus_31.pdf). Ka G Suite puhul pole
jagamine vaikimisi piiratud. Juhend G Suite sätete muutmiseks on siin:
https://support.google.com/a/answer/60781?hl=en (vt hardcopy Andmete_haldus_32.pdf) ja
https://support.google.com/a/answer/7662202?hl=en (vt hardcopy Andmete_haldus_33.pdf).
Samuti nagu lokaalse failiserveri puhul, peaks ka pilves olevate andmete kasutamiseks sisse
lülitama auditeerimise. Juhend Office 365 auditeerimise sisse lülitamiseks on siin:
https://support.microsoft.com/en-us/help/4026501/office-auditing-in-office-365-for-admins (vt
hardcopy Andmete_haldus_34.pdf) ja G Suite auditi logi lugemise juhend on siin:
https://support.google.com/a/answer/4579696?hl=en (vt hardcopy Andmete_haldus_35.pdf).
3. Andmete lokaalne sünkroniseerimine.
Nii Office 365 kui ka Google Apps pakuvad tarkvarasid andmete arvutisse sünkroniseerimiseks.
Office 365 puhul on selleks OneDrive for Business Sync Client, millega saab faile sünkroniseerida
nii OneDrive, Teams kui ka Sharepoint Online lehtedelt. Google Apps puhul on selleks Drive File
Stream (et see oleks lubatud, tuleb see eraldi sisse lülitada
https://support.google.com/a/answer/7496409 vt hardcopy Andmete_haldus_36.pdf), mis
võimaldab sünkroniseerida nii Google Drive’i kui ka Team Drive’i faile. Mõlema tarkvara puhul
luuakse failide pilvega sünkroniseerimisel turvaline kanal ja see on AES256-ga krüpteeritud.
Soovitav on piirata seadmeid, millelt saab arvutisse faile sünkroniseerida. Office 365 puhul on
võimalik sünkroniseerimist piirata ainult domeeni arvutitega https://docs.microsoft.com/en-
us/OneDrive/allow-syncing-only-on-specific-domains (vt hardcopy Andmete_haldus_37.pdf).
3 Tarkvara haldus
Turvalisuse tagamiseks ning turvanõrkuste vähendamiseks või eemaldamiseks on oluline hoida
operatsioonisüsteem ja sellele paigaldatud tarkvara värske ning ajakohasena. Windows keskkonna
paikamiseks ja tarkvara paigaldamiseks on võimalikeks vahenditeks Windows Server Update Services
(WSUS) ja System Center Configuration Manager (SCCM). Rühmapoliitikaga on samuti võimalik
lihtsamaid MSi pakette paigaldada (vaata igapäevases praktikas kasulikuks osutunud GPOd Windows 10
tööjaamadele / Tarkvara paigaldamine rühmapoliitika abil).
Kolmanda osapoole lisana saab kasutada WSUS Package Publisher nimelist laiendust WSUS serverile, mis
annab lihtsustatud võimaluse tarkvara keskselt paigaldada ja uuendada. Samuti on tarkvara paikamise ja
operatsioonisüsteemi värskenduste haldus sisse ehitatud enamikesse viirusetõrje tarkvaradesse ning on
tihti ka keskselt hallatav.
Selleks, et paremini teada, millised seadmed võrgus vajavad kaitset ning mis nõrkused võivad esineda,
on tähtis omada oma varadest ülevaadet. Selleks tasub teha nii tarkvara kui ka riistvara inventuuri ning
hoida seda pidevalt ajakohasena. Kuna käsitsi inventuuri tehes võib esineda vigu (mõni seade/tarkvara ei
lähe kirja, pannakse valesti kirja jne) ning see on ka väga ajamahukas, on mõistlik kasutada
automaatseid inventuuri tööriistu. Näiteks pilve- ja internetipõhistest lahendustest Microsoft Intune,
mis peaks osaliselt asendama SCCM, vabavaralistest OCS-NG (https://www.ocsinventory-ng.org), mille
abil saab koguda seadme tarkvara, riistvara ja seadistuste kohta informatsiooni üle võrgu, Spiceworks
(https://www.spiceworks.com/), mis lisaks eelmisele kogub informatsiooni ka võrguseadmete kohta.
Alla 100 seadme puhul võiks sobida ka Lansweeper’i tasuta versioon (https://www.lansweeper.com/).
Turvalisus on protsess. Automaatika seadistamine tarkvara ja opertsioonisüsteemi turvanõrkuste
parandamiseks ei tähenda, et kõik on automaatselt kaitstud. Pidevalt tuleks jälgida, et paikapandud
automaatika toimiks ning uuendused paigaldataks piisavalt kiiresti. Samuti tuleks pidevalt jälgida,
millised turvanõrkused on välja tulnud ning millistele ei ole veel parandusi. Mõned head kohad selleks
on näiteks:
https://cve.mitre.org/
https://www.securityfocus.com/
https://portal.msrc.microsoft.com/en-us/security-guidance
Automaatsel paikamisel tuleks arvestada ka riskidega. Kõige värskemate uuendustega võivad kaasneda
ka uued tarkvaravead. Tarkvara paikamisel tuleks kindlasti luua selline töövoog, mille käigus testrühmal
on piisavalt aega uuendused läbi testida ja leida võimalikud lahendused või tööd takistavad uuendused
paigaldamata jätta enne kui uuendused jõuavad kõikidele seadmetele. Uuenduste ajastamisel tuleks
arvestada kasutajate tööajaga ning informeerida kasutajaid, et nad saaksid arvestada uuendustest
tingitud võimalike katkestustega.
3.1 Windows Server Update Services
Windows Server Update Services paigaldamisel tuleks lähtuda olemasolevatest ressurssidest ning
hallatavate arvutite kogusest. WSUS andmebaas on SQL ning seda on võimalik paigaldada nii eraldiseisva
SQL serveri peale kui Windows Internal Database peale. Eraldiseisva SQL serveri eelis on kiirem teenus
ning hajutatud koormus, miinusena võib tuua litsentsi olemasolu vajaduse, sest andmebaas kasvab väga
kiiresti üle vaba litsentsi piirangu (10GB). Sisseehitatud (WID) andmebaasi puhul on mahupiirang
oluliselt suurem ning reeglina selleni ei jõuta, kui korralised hooldused ja puhastused on korrektselt
seadistatud. WID andmebaasi miinuseks võib lugeda seda, et kogu koormus on ühel serveril ning
seetõttu on teenus tervikuna veidi aeglasem.
WSUS teenust ei tohiks paigaldada ADDS teenustega samasse serverisse, sest see võib pärssida ADDS
teenuse tööd või sattuda konflikti nende teenuste andmebaasidega. Serverile, kus on paigaldatud WSUS,
ei tohiks teha in-place upgrade’i, sest WSUS on igas serveriversioonis erinev ning alusserveri upgrade ei
ole toetatud. Enne serveri upgrade’i tuleb WSUS teenus eemaldada ja peale upgrade’i see uuesti
paigaldada.
Turvapaikade planeerimist on käsitletud ISKE kataloogis M2.421.
3.1.1 WSUS teenuse paigaldamine ja seadistamine
WSUS teenuse paigaldamine toimub sarnaselt teistele teenustele Windows Server Manager'ist Add
Windows roles and features kaudu.
Powershell kaudu installeerimiseks koos sissehitatud andmebaasiga saab kasutada käsku:
Install-WindowsFeature -Name Updateservices,UpdateServices-WidDB,UpdateServices-services –IncludeManagementTools
Server Managerist tuleb valida menüüst Manage -> Add roles and features. Avanenud viisardist
navigeerida edasi ning teha rollide alt vastav valik:
Rolli valides pakutakse automaatselt kõik sõltuvad teenused ja haldusvahendid. Vaikimisi valikud
sobivad, seega midagi muuta pole vaja ning vajutada tuleb Add Features.
Vahepealseid valikud pole vaja muuta, seega navigeerida edasi kuni punktini Role services.
WSUS rollide alt on vaikimisi valitud WSUS Services ja WID teenus, siin valitud WID on eelnevalt
kirjeldatud andmebaasi tüüp. Kui andmebaasi soovitakse paigaldada mõnda teise serverisse, tuleks WID
asemel valida SQL Server Connectivity.
Juhul kui valida SQL Server Connectivity, küsitakse järgmises etapis SQL serveri nime ja instance’i. SQL
server instance’is peab WSUS teenust paigaldaval kasutajal olema õigus luua uus andmebaas ning
määrata sellele õiguseid. WSUS serveril võiks olla täiesti oma SQL instance.
Content viitab asukohale, kuhu laetakse alla ja hoitakse WSUS teenusega seotud tarkvarapakette ning
Windowsi uuendusi. Windowsi uuendused on küllaltki mahukad, seega võiks Windows 10 ja Windows
Server 2016 uuenduste hoiustamiseks ruumi olla vähemalt 50GB ulatuses (soovitatavalt 100GB või
rohkem) ja seda kohas, mida on võimalik vajadusel lihtsasti suurendada. Asukohaks võib olla ka
võrgukaust.
Viimaseks sammuks on Confirmation. Siit saab näha väljavõtet kõikidest valikutest ja ainus valik edasi on
Install.
Kui paigaldamine on lõppenud, on Server Manageri staatuse ikooni juures näha kollane kolmnurk ning
sellele klikkides valik Start post-installation tasks, mille peale tehakse vajalikud teenused, eelnevalt
määratud WSUS kausta sisu ja pannakse teenused käima.
Post-installation seadistusi ning Content asukoha muudatust on võimalik käivitada ka käsurealt:
cd "C:\Program Files\Update Services\Tools" .\wsusutil.exe postinstall CONTENT_DIR=C:\WSUS
3.1.2 Paigaldusjärgne seadistamine
Kui paigaldamine on lõppenud, saab Server Manager Tools menüüst avada Windows Server Update
Services haldusvahendi.
Esimesel korral avaneb viisard, kus küsitakse kõikvõimalike sünkroniseerimise sätete kohta.
Esimesed kaks lehte on sissejuhatus, teenuse kirjeldus ning muu eelinfo ja alles kolmandal lehel näeme
esimest valikut Upstream Server. Siin tuleb valida Synchronize from Microsoft Update. Teine valik on
juhuks, kui on olemas üks kõrgema taseme WSUS server, millest tahetakse uuendusi edasi
sünkroniseerida.
Juhul, kui ettevõte peab Internetti pääsemiseks kasutama proksit, tuleb see määrata järgneval lehel.
Peale internetiühenduse loomist tuleb teha esmane sünkroniseerimine, et laadida alla toodete ja
klassifikatsioonide nimekiri.
Juhul, kui tulemüüris on ranged piirangud, tuleks kontrollida, et WSUS serveril oleks lubatud suhelda
järgmiste aadressidega:
http://Windowsupdate.microsoft.com
http://*.Windowsupdate.microsoft.com
https://*.Windowsupdate.microsoft.com
http://*.update.microsoft.com
https://*.update.microsoft.com
http://*.Windowsupdate.com
http://download.Windowsupdate.com
https://download.microsoft.com
http://*.download.Windowsupdate.com
http://wustat.Windows.com
http://ntservicepack.microsoft.com
http://go.microsoft.com
http://dl.delivery.mp.microsoft.com
https://dl.delivery.mp.microsoft.com
WSUS seadistus saab teha ka PowerShell kaudu, täpsemad käsud siin docs.microsoft.com/en-
us/powershell/module/wsus/index?view=win10-ps, vt Tarkvara_haldus_4.pdf
3.1.3 Tooted ja klassifikatsioonid
Kui esmased toodete ja klassifikatsioonide nimekirjad on alla laetud, tuleb hakata valima tooteid, millele
WSUS uuendusi pakkuma hakkab.
Eesmärk on valida võimalikult vähe, aga samas kõik nõutav, et arvutid saaks kätte vajalikud uuendused.
Mida rohkem valida, seda rohkem võtab WSUS ruumi ja tekitab suuremat koormust.
On väga palju erinevaid Windows 10 versioone ning tuleks teada kõiki kasutuselolevaid versioone või
teha üldisemad valikud, et kõik versioonid oleks kaetud.
Näiteks valik Windows 10 ja Windows 10 and Later Drivers on üldised valikud kõikide Windows 10
versioonide jaoks.
Üldiselt ei ole WSUS kaudu draiverite paigaldamine soovituslik. Neid on oluliselt rohkem kui muid
uuendusi ning tuleks läbi mõelda, kas neid on vaja pidevalt alla laadida. Näiteks kui arvutitele
paigaldatakse operatsioonisüsteem enne domeeni liitmist, saab draiverid kõik enne kätte ning neid ei
ole vaja WSUS kaudu paigaldada. Samuti saab draiverite viimased versioonid üldiselt kätte tootjate
kodulehtedelt.
Muud Windows 10 versioonid ja nende tähendused:
Windows 10 Dynamic Update: selle valiku alla käivad uuendused, mida laeb alla ja paigaldab Windows Setup – neid on vaja ainult arvuti upgrade protseduuril ja puhtal paigaldamisel.
Windows 10 GDR-DU: praegu kõige viimase Windows 10 versiooni dünaamilised uuendused.
Windows 10 […] Upgrade & Servicing Drivers: nagu esimene siin nimekirjas, on need versioonivahetuse ja paigaldamise ajal driverite allalaadimiseks ja paigaldamiseks.
Language Packs: keelepakettide uuendused nii jooksvalt kui Windows Setup’i ajal.
Windows 10 Feature On Demand: kõikvõimalikud lisad Windows operatsioonisüsteemile, mida paigaldatakse Add-, Remove Windows Features kaudu. Näiteks .NET 3.5, telnet client, subsystem for linux jms.
Windows 10 GDR-DU FOD: sama, mis eelmine, aga ainult kõige uuema Windows 10 versiooni jaoks.
Klassifikatsioonid on pisut lihtsamini arusaadavad ning siin võiks valida kõik, mis on kriitiline ja
turvauuendused. Selleks, et muud parandused järgi jõuaksid, võiks lisaks valida Update Rollups, Service
Packs. Feature Packs tähendab uusi Windowsi versioone.
Järgmises etapis saab valida, mis kellaajal ja mitu korda päevas WSUS andmebaasi sünkroniseerimist
(sealhulgas uuenduste kontroll ja allalaadimine) tehakse.
Esialgu tuleks jätta initial synchronization tegemata. Seda saab hiljem teha haldusliidesest või oodata
eelnevalt valitud aega.
Kindlasti tuleb see valik jätta tegemata juhul, kui on soov seadistada WSUS nii, et tööjaamad laevad
uuenduspaketid alla otse Microsofti serveritest, mitte ei salvestata neid WSUS serverisse.
Viisardi lõpus antakse veel mõned lingid Microsofti-poolsetele soovitustele ning seadistamise juhistele.
Kui seadistusviisard on lõpetanud, avaneb Finish nupu vajutamisel Update Services halduspaneel.
3.1.4 Uuenduste piirangud
Vaikimisi ei lubata arvutitel paigaldada ühtegi uuendust, nende uuenduste lubamiseks tuleb teha
Approval Rule WSUS halduspaneelist Options -> Automatic Approvals.
Sinna võiks teha igale grupile reegli ning valida soovitud kriteeriumid:
Need reeglid käivitatakse koos sünkroniseerimistöödega, seega kui seal teha muudatusi, tuleks kohe
vajutada ka Run Rule, et see rakendataks eelnevatele uuendustele, mis võivad olla juba järjekorras.
Seda on võimalik teha ka powershell käsu kaudu docs.microsoft.com/en-us/powershell/module/wsus/approve-wsusupdate?view=win10-ps vt Tarkvara_haldus_5.pdf.
3.1.5 Arvutite lisamine ja grupeerimine
WSUS seadistamisel tuleks arvutid ja serverid grupeerida vastavalt vajadusele, et saavutada uuenduste
ja tarkvara paigaldamisel grupipõhine kontroll.
Näiteks:
Arvutid
Terminalid
Serverid
Domeenikontrollerid
Tihti on terminaliserverites kasutusel tarkvara, mida ülejäänud serverites ei ole, seetõttu võiks need olla
eraldi grupis.
Arvuteid ja servereid saab grupeerida kahel viisil:
A. Käsitsi WSUS serveris õigesse gruppi tõsta
B. GPO abil WSUS grupp määrata
Mõlemal puhul tuleb grupid käsitsi ette ära teha, GPO kaudu arvutile WSUS grupi määramine ei tekita
uut gruppi. Samuti tuleb vastav valik määrata Options -> Computers sätete alt:
Antud seadistust on võimalik teha ka PowerShell abil käsuga Add-WsusCompute. Täpsemalt käsu ja
parameetrite kohta saab infot aadressilt docs.microsoft.com/en-us/powershell/module/wsus/add-
wsuscomputer?view=win10-ps vt Tarkvara_haldus_7.pdf.
3.1.6 Arvutite käsitsi lisamine
Käsitsi lisamiseks tuleb arvutites tekitada või muuta järgnevad registrivõtmed:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
Võti Andmetüüp Väärtus
DisableWindowsUpdateAccess Reg_DWORD 1 = Keelab Windowsi uuendused
0 = Lubab Windowsi uuendusi (vaikimisi valik)
WUServer Reg_SZ HTTP(S) aadress WSUS serverile, sama väärtus
tuleks sisestada WUStatusServer võtmele
(vaikimisi puudub = Windows Online Update)
WUStatusServer Reg_SZ HTTP(S) aadress WSUS serverile, sama väärtus
tuleks sisestada WUServer võtmele
(vaikimisi puudub = Windows Online Update)
TargetGroupEnabled Reg_DWORD 0 = Ära kasuta WSUS’is määratud gruppe
(vaikimisi valik)
1 = Kasuta WSUS’is määratud gruppe
TargetGroup Reg_SZ WSUS’is ette tehtud grupi nimi
(vaikimisi puudub)
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU
Võti Andmetüüp Väärtus
AUOptions Reg_DWORD 2 = Teavita enne allalaadimist.
3 = Lae automaatselt alla, aga teavita paigaldamisest.
4 = Lae alla ja paigalda automaatselt. Töötab vaid siis, kui
võtmete ScheduledInstallDay ja ScheduledInstallTime väärtused
on olemas.
5 = Uuendamine on nõutud, kuid kasutaja saab sätted määrata.
NoAutoUpdate Reg_DWORD 0 = Luba automaatne uuendamine.
(vaikimisi valik)
1 = Keela automaatne uuendamine.
UseWUServer Reg_DWORD 1 = Arvuti võtab uuendused WSUS serverist.
Peab olema määratud kui kasutatakse WSUS serverit.
0 = Arvuti võtab uuendused Microsoft Update’i kaudu
(vaikimisi valik).
3.1.6.1 Näide
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
Võti Andmetüüp Väärtus
WUServer Reg_SZ http://WSUS.ssh.lan:8530
WUStatusServer Reg_SZ http://WSUS.ssh.lan:8530
TargetGroupEnabled Reg_DWORD 1
TargetGroup Reg_SZ Arvutid
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU
Võti Andmetüüp Väärtus
AUOptions Reg_DWORD 4
UseWUServer Reg_DWORD 1
3.1.7 Arvutite lisamine rühmapoliitika abil
Arvutite määramine erinevatesse gruppidesse eeldab, et OU, kuhu Group Policy link tehakse, sisaldab
ettenähtud arvuteid või on Group Policy objektil filter nii, et see rakenduks vaid ettenähtud arvutitele.
Lisatud on rühmapoliitikate näidis nimega 7_Tarkvara_WSUS.
NB! WSUS server ise peaks uuendused saama Windows update’i kaudu ning antud GPO ei tohiks WSUS
serverile rakenduda.
Rühmapoliitika sätted, mida on vaja lubada ja muuta, et WSUS serveri kasutamine klientidele rakenduks:
Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Update
Policy Status Settings
Configure Automatic Updates Enabled Configure automatic updating:
4 - Auto download and schedule
the install
Install during automatic
maintenance: Enabled
Scheduled install day: 4 - Every
Wednesday
Scheduled install time: 03:00
Install updates for other
Microsoft products: Disabled
Enable client-side targeting Enabled Serverid
Specify intranet Microsoft
update service location
Enabled Set the intranet update service
for detecting updates:
http://WSUS.ssh.lan:8530
Set the intranet statistics server:
http://WSUS.ssh.lan:8530
Set the alternate download
server:
Download files with no Url in
the metadata if alternate
download server is set: Disabled
3.1.7.1 Näide
Rühmapõhiselt rakendatud poliitika serveritele:
OU-põhine (rakendub kõikidele arvutitele ja serveritele kindlas OUs ja selle all)
Sätte võib defineerida kõik samas rühmapoliitika objektis või jaotada osadeks nii, et üldised sätted
(Configure Automatic Updates, Specify intranet Microsoft update service location) rakenduvad kõigile,
kuid näiteks Enable client-side targeting on erinevatele gruppidele või OUdele erinev.
Peale rühmapoliitika rakendumist ja esimest uuenduste kontrolli ning klientide raporteerimist ilmuvad
serverid ja tööjaamad WSUS halduspaneelis nähtavale. Arvutid, mis saavad küll WSUS asukoha sätted,
aga mitte Enable client-side targeting poliitikat (või kui näiteks viimases on kirjaviga), ilmuvad
Unassigned Computers nimelisse rühma.
Kui kõik on korrektselt seadistatud, peaks arvutid WSUS kaudu uuendused kätte saama ja need
paigaldama:
3.1.8 SSL/HTTPS seadistamine
Arvutid vajavad WSUS serveriga suhtlemiseks ligipääsu WSUS serverile kahel pordil: HTTP (port 8530) ja
HTTPS (port 8531).
WSUS teenus kasutab SSL ühendust ainult metaandmete edastamiseks. Uuendusfailid tulevad üle
krüpteerimata HTTP samamoodi nagu tavapärased Windows uuendused Microsoftilt. Uuenduste
kaitsmiseks üle HTTP kasutatakse pakkide allkirjastamist WSUS teenuse poolt ning metaandmetesse
kaasatakse räsi. Kui allalaetud paki arvutatud räsi ja metaandmetes olev räsi ei kattu, siis uuendust ei
paigaldata.
SSL kasutamine tõstab krüpteerimise tõttu WSUS serveri koormust umbes 10% võrra.
SQL ühendus WSUS serveri ja andmebaasi vahel ei ole krüpteeritud. Andmebaas peaks turvalisuse
huvides asuma kas WSUS serveris või andmebaasi ja WSUS vaheline suhtlus peaks käima läbi eraldatud
võrgu.
SSL kasutamisel vajab WSUS kahte porti – HTTPS porti metaandmete jaoks ning HTTP porti
uuenduspakettide jaoks. Pordi määramisel tuleb arvestada, et:
Tavapärase HTTPS pordi (443) kasutamisel kasutab WSUS HTTP pordina tavapärast porti (80).
Kõikide muude portide puhul määrab WSUS ise HTTP pordiks ühe numbri võrra väiksema pordi,
näiteks vaikimisi pordid HTTP 8530 ja HTTPS 8531.
Kõigepealt tuleb WSUS serverile teha sertifikaat, kas self signed või domeeni CA poolt. SSL
aktiveerimiseks tuleb minna WSUS serveri käsureal asukohta:
%ProgramFiles%\Update Services\Tools\
ning sisestada järgnev käsk:
WSUSutil configuressl certificateName
kus certificateName on WSUS serveri DNS nimi (sama mis sertifikaadil CN)
Seejärel lisada sertifikaat IIS’is WSUS Administration saidi HTTPS pordile:
SSL sundimisel tuleb arvestada, et kõikidele WSUS’i IIS virtuaalsetele kataloogidele ei tohiks sundida SSL
ühendust, sest WSUS krüpteerib ainult metadata osa ja ülejäänud ühendused ei õnnestu.
SSL ühenduse võib sundida järgmistele virtuaalsetele kataloogidele IIS’is:
SimpleAuthWebService
DSSAuthWebService
ServerSyncWebService
APIremoting30
ClientWebService
SSLi ei tohiks sundida järgmistele kataloogidele:
Content
Inventory
ReportingWebService
SelfUpdate
IIS Manageris SSLi sundimiseks tuleb valida vastav virtuaalne kataloog, selle alt valida SSL Settings:
Panna linnuke Require SSL ette:
WSUS SSL ühenduse sertifikaat või selle väljastaja sertifikaat (CA) tuleb importida arvutite ja WSUS
serverite Trusted Root CA kataloogi – seda saab teha käsitsi MMC või keskselt rühmapoliitika abil.
Lisatud rühmapoliitika näidis nimega 8_Tarkvara_WSUS_WSUSSertifikaat.
Computer Configuration -> Polices -> Windows Settings -> Security Settings -> Public Key polices
Kui WSUS server on seadistatud kasutama SSLi, siis arvutites tuleb arvestada, et:
WSUS serveri sätetes (Regiter või GPO) peab olema WSUS serveri aadress määratud veebiaadressina
koos protokolliga, näiteks:
WSUS SSL port 8531 puhul on aadress: https://WSUS.ssh.lan:8531
WSUS SSL port 443 puhul on aadress: https://WSUS.ssh.lan
WSUS SSL port 1234 puhul on aadress: https://WSUS.ssh.lan:1234
WSUS serveris kasutatav sertifikaat peab olema arvutite poolt usaldatud. Sertifikaat või selle väljastaja
sertifikaat tuleb lisada arvuti sertifikaatide kataloogi:
Local Computer/Trusted Root Certificaton Authorities
3.1.9 Andmebaasi puhastamine
WSUS andmebaasi puhastamine vanast uuenduste ja arvutite infost on väga oluline. Kui see jääb pikaks
ajaks tegemata, võib andmebaas niivõrd palju kasvada, et WSUS halduspaneel enam ei avane ja
andmebaasi puhastamine WSUS enda vahenditega ei õnnestu. Sellisel juhul tuleb kasutada kolmandate
osapoolte skripte või andmebaas uuesti teha.
Andmebaasi puhastamine toimub WSUS halduspaneelist käsitsi või Powershelli käsku kasutades.
Andmebaasi automaatseks puhastamiseks on kõige lihtsam viis teha iganädalane scheduled task, mille
ülesandeks on käivitada Powershelli skript, mis kasutab käsku:
Invoke-WSUSServerCleanup
Täpsem teave antud käsu kohta - https://docs.microsoft.com/en-us/Powershell/module/WSUS/invoke-
WSUSservercleanup?view=win10-ps (vt hardcopy Tarkvara_haldus_1.pdf).
3.1.10 Ligipääs väljastpoolt sisevõrku
Microsofti litsentsitingimused WSUS teenusele ütlevad, et teenus võib olla kättesaadav vaid
organisatsioonile, kuhu see on paigaldatud. See tähendab, et välisvõrgust teenusele ligipääsu tekitada ei
tohiks, sest seda ei ole võimalik piirata ainult ettevõtte arvutitele. WSUS ligipääsu piiramiseks tuleb
teenust kasutada läbi VPNi või DirectAccessi. Alternatiivina võib seadistada rühmapoliitika nii, et
tuvastatakse kasutaja võrk ning vastavalt sellele laetakse uuendused alla kohalikust WSUS serverist või
Microsofti uuenduste kataloogist.
3.2 WSUS Package Publisher
WSUS Package Publisher (edaspidi WPP) on kolmanda osapoole lisa WSUS jaoks, mis annab lihtsustatud
kasutajaliidese ning -halduse tarkvara paigaldamiseks läbi Windows Update teenuse. WPP kasutab ära
WSUS sisseehitatud pakettide loomist ja allkirjastamist sarnaselt System Center Configuration
Manager’le.
3.2.1 Paigaldamine ja seadistamine
WSUS Package Publiser on endine Codeplex projekt Github keskkonnas https://Github
.com/DCourtel/WSUS_Package_Publisher (vt hardcopy Tarkvara_haldus_2.pdf).
Paigaldamiseks tuleb Github’ist allalaetud fail vabalt valitud asukohta lahti pakkida, WPP ei vaja
installeerimist. Lisaks rakendusele on samas kaustas ka hulk PDF formaadis juhendeid.
Kui WPP paigaldati WSUSiga samasse serverisse, siis esmasel käivitamisel annab WPP teate, et serverist
on WSUS teenus leitud ja see lisatakse automaatselt serverite alla:
Ühendamiseks tuleb vajutada ülemiselt realt Connect/Reload.
Juhul kui WSUS on seadistatud kasutama SSLi, siis ühendus ei õnnestu ning veateateks kuvatakse
HTTP403
SSL ühenduse seadistamiseks tuleb minna Tools -> Settings menüüsse ja lisada server:
Server Name: täispikk nimi, hostname ei ole piisav, peab olema sama nimi, mis WSUS serveri
sertifikaadil.
Eemaldada linnuke Connect to local server
Muuta õigeks port ja panna linnuke Use SSL järele.
Lisada need sätted Add Server nupu abil.
Hilisemate segaduste vältimiseks võib eelmise, automaatselt tekitatud serveri Remove Server nupu abil
paneelist eemaldada.
Peale serveri sätete lisamist peaks ühendus õnnestuma.
3.2.2 Sertifikaadi loomine, serverile ja klientidele paigaldamine
Selleks, et WPP abil saaks tarkvara tööjaamadele levitada, tuleb teha tarkvarapakettide allkirjastamise
sertifikaat. Seda saab teha läbi WPP või domeeni sertifikaadiserveri.
WPP abil sertifikaadi loomiseks tuleb valida menüüst Tools -> Certificate…
ning vajutada nuppu Generate the certificate.
Peale sertifikaadi loomist tuleb WSUS teenused ja WPP taaskäivitada ja peale seda saab samast kohast
WPPs sertifikaadi salvestada.
NB! WPP abil ei saa sertifikaati luua kui WSUS server kasutab SSLi, sest WPP ei pea sellisel juhul serverit
lokaalseks. Sertifikaadi loomiseks tuleb ajutiselt SSL maha võtta (piisab Require SSL linnukeste
eemaldamisest IIS’is).
Sertifikaat tuleb sarnaselt WSUS SSL sertifikaadile paigaldada arvutitesse kas käsitsi või GPO abil kahte
asukohta:
Local Computer/Trusted Root Certificaton Authorities
Local Computer/ Trusted Publishers
Computer Configuration -> Polices -> Windows Settings -> Security Settings -> Public Key polices
Domeeni CA kaudu sertifikaadi tegemisel tuleb kindlasti lisada sertifikaadile intended purpose - Code
Signing. Lisatud rühmapoliitika näidis nimega 9_Tarkvara_WSUS_WPPSertifikaat.
3.2.3 Pakettide loomine ja haldamine
Pakettide loomise protseduur on küllaltki lihtne, selleks peab olema installifail .msi või .exe, mis toetab
taustal paigaldamist ilma kasutajale küsimusi esitamata.
Näiteks protseduur ID-kaardi tarkvara paigaldamiseks on järgmine:
Laadida alla ID-kaardi tarkvara viimane ZIP fail, kus on sees kõik vajalikud komponendid
(https://installer.id.ee/media/win) ja pakkida ZIP fail lahti.
WPPs valida menüü Updates -> Create an Update.
Ülemisse lahtrisse valida paigalduse .exe fail ja alumisse kõik ülejäänud kaasatulevad failid:
Järgmisel lehel täita kõik vajalikud väljad ning Command line reale lisada ID-kaardi tarkvara
dokumentatsioonist võetud lisakäsud, näiteks /quiet AutoUpdate=0 IconsDesktop=0 RunQesteidutil=0.
Seejärel määrata kriteerium, mille alusel Windows update saab aru, et tarkvara on juba paigaldatud ja ei
hakka seda uuesti paigaldama:
Siin tuleb teha lisasamm ning paigaldada antud tarkvara ning võtta näiteks MSI ID juba paigaldatud
paketilt. Üks võimalus selle saavutamiseks on Powershell:
Saame tulemuseks Open-EID Metapackage MSI ID, mida WPP reeglis kasutada.
Järgmisena tuleb teha reegel, mis tingimustel pakett paigaldatakse – see võiks olla nii, nagu tarkvara
väljaandja on öelnud, näiteks võib teha kriteeriumi Windows 7 või uuem tööjaam.
Viimane samm on Publish, mis teeb vajaliku paketi valmis.
3.2.4 Pakettide paigaldamine ja jälgimine
Loodud paketid tekivad WPP konsooli Updates alla.
Iga paketi staatuse ja raporti vaadetest on näha, millistele arvutitele pakett on paigaldatud, millistele
mitte ja millistele paigaldamine ei õnnestunud.
Paketi paigaldamiseks grupile tuleb teha paketil paremklõps ja valida Approve.. . Avanenud aknas saab
iga grupi puhul valida soovitud tegevuse.
Järgmisel uuenduste kontrollil peaks arvutid paketi tuvastama ja selle paigaldama.
3.3 System Center Configuration Manager
System Center Configuration Manager on osa Microsoft System Center paketist, mis keskendub arvutite
kesksele haldusele, operatsioonisüsteemi ning tarkvara ja uuenduste paigaldamisele. SCCM kasutab
taustal WSUS rolli serverite ja tööjaamade paranduste olemasolu või puudumise tuvastamiseks.
Uuendus- ja tarkvarapakettide paigaldamine tööjaamadesse käib läbi kliendirakenduse Software Center.
3.3.1 Windows 10 versioonivärskendused
Windows 10 versiooniuuenduste paigaldamise lihtsustamiseks on Configuration Manageris eraldi
sektsioon Windows 10 Servicing. Seal saab grupikaupa ära määrata, mis versioonile ja millal tööjaam
uueneb.
SCCM kaudu upgrade’i valimist saab väga erinevalt lahendada ja see sõltub sellest, kuidas ettevõttes
kokku on lepitud. Kõige lihtsam viis oleks filtreerida, kas mõni arvuti vajab uuendamist ja kui vajab, siis
seda lubada.
Näiteks antud juhul on filtreerimiseks valitud ainult keel ja kontroll, kas mõni arvuti küsib
versioonivärskendust.
Teiseks reegli osaks on edasilükkamise aeg, antud juhul on selleks 90 päeva.
See tähendab, et kui Microsoft annab välja vastava kanali versioonivärskenduse, ootavad arvutid 90
päeva ja annavad seejärel SCCM’le teada, et nüüd on vaja see paigaldada. SCCM teeb otsuse tehtud
reegli põhjal - kui keel on õige ja üks arvuti soovib seda paigaldada, laetakse versioonivärskendus alla ja
lubatakse kõigile.
Reegleid võiks olla kaks ja ainus erinevus nende puhul on kanal - Semi-Annual või Semi-Annual
(Targeted). Viimane tuleb reeglina varem välja, et jõuaks võimalikele probleemidele reageerida ja
lahendused läbi mõelda enne kui teised uuenduse saavad ja see kõigile kättesaadavaks muutub.
3.3.2 Automaatne paigaldamine
Uuenduste kontrollimiseks, allalaadimiseks ja tööjaamadele või serveritele lubamiseks tuleb luua reeglid
(Automatic Deployment Rule). Reeglites saab määrata, millised uuendused lubatakse ning kui tihti neid
kontrollitakse. Üldjoontes on kõik valikud samad, mis WSUS serveri tarkvara ja klassifikatsioonide juures.
Nagu nimi ütleb, on tegemist automaatse rakendamise reegliga. Seega saab siin määrata, kuidas
uuendused paigaldatakse.
Antud reeglit on võimalik luua ka PowerShell käsu abil: docs.microsoft.com/en-
us/powershell/module/configurationmanager/new-cmsoftwareupdateautodeploymentrule?view=sccm-
ps vt Tarkvara_haldus_6.pdf.
3.3.3 Tarkvarapakettide loomine
Tarkvarapakettide ja nende uuenduste loomise protseduur on peaaegu identne WSUS Package
Publisherile.
Olenevalt paketist tuleb valida õige paketi tüüp ja anda vastavad väärtused. Täpsem rakenduste ja
pakettide loomise kirjeldus on Configuration Manageri dokumentatsioonis:
https://docs.microsoft.com/en-us/sccm/apps/deploy-use/create-applications (vt hardcopy
Tarkvara_haldus_3.pdf).
Mõned rakendused nõuavad eriseadistusi olenevalt paketi paigaldamise protseduurist ja selle
paigaldamise tuvastusmeetoditest. Näiteks ID-kaardi tarkvara paigaldamiseks on küll olemas MSI failid,
kuid neid paigaldatakse komplektina – tuleb teha skript tüüpi paigalduspakett.
Näidisprotseduur ID-kaardi tarkvara puhul:
Viimase versiooni kõiki komponente sisaldav ZIP fail on kättesaadav
aadressil: https://installer.id.ee/media/win
Seal on fail:
Open-EID.zip 2018-01-08 16:05 127M
See tuleks alla laadida ning pakkida lahti võrgukettale, kus kõigil on lugemisõigus. SCCMis rakenduse
paigalduspaketi loomise viisardis tuleks paigalduse tüübiks valida Script.
Olulised valikud skripti puhul:
1. Content location peaks olema share, kuhu ZIP sai lahti pakitud:
2. Programs kaardil peavad käsud viitama .exe failile koos kõigi vajalike valikutega:
Install: Open-EID-17.12.0.1770_x86.exe /quiet /norestart AutoUpdate=0 IconsDesktop=0
RunQesteidutil=0
Uninstall: Open-EID-17.12.0.1770_x86.exe /uninstall /quiet /norestart
Sätteid saab kontrollida andes väärtuse 0 või 1
AutoUpdate=0 – tarkvara uuendusi ei kontrollita automaatselt.
IconsDesktop=0 – töölauale ei looda ikoone.
RunQesteidutil=0 – ID-kaardi utiliiti ei käivitata peale paigaldamist.
3. Detection method
Detection methodiks tuleks valida MSI paki olemasolu ning sisestada paki OpenEID Metapackage ID.
Peale ülaltoodud install-käsuga viimase versiooni paigaldamist ühes arvutis saab OpenEID Metapackage
MSI ID kätte näiteks Powershell käsuga.
PS C:\WINDOWS\system32> Get-WmiObject -Class Win32_Product | ft | findstr Open
3.3.4 Tarkvarapakettide paigaldamine
Peale tarkvarapakettide loomist tuleb neile teha Deployment reeglid. Deployment reeglid määravad, kas
tarkvara paigaldatakse koheselt või mingi aja pärast ja kas seda sunnitakse peale või on see valikuline.
3.3.5 Ligipääs väljastpoolt sisevõrku
Erinevalt WSUS’ist on SCCM’i puhul võimalik määrata pakettide kättesaadavus ka väljastpoolt sisevõrku,
kui määrata vastav säte Deployment reegli alt või seadistada PKI ja SSL sätted ning suunata vajalikud
pordid. Võimalik on ka selline seadistus, et uuendused laetakse alla otse Microsofti kataloogidest.
3.3.6 Segamudeli soovitused
Juhul kui ettevõttes on kasutusel vanemaid Windows operatsioonisüsteeme - näiteks Windows 7, 8 või
8.1, tuleks nendele vajalikud tarkvarauuendused WSUSis ja SCCMis Products valikute all lubada
samamoodi, nagu seda tehakse Windows 10 puhul. Soovitav on nende lubamiseks teha eraldi reeglid ja
grupid, et neid oleks lihtne eemaldada kui nende eluiga läbi saab.
4 Identiteedihaldus
Identiteedihaldus on protsess identifitseerimaks, autentimaks ja autoriseerimaks isikute ligipääsu mingitele rakendustele, süsteemidele, võrkudele jms. Autentimisel identifitseeritakse kasutaja isik parooli, sertifikaadi (signatuuri), sessioonivõtme vms põhjal. Autoriseerimisel seotakse kasutaja identiteet temale omistatud õiguste ja piirangutega süsteemis. ISKEs räägitakse sellest täpsemalt punktis B 1.18.
4.1 Autentimine
Autentimine on tegevus, mille käigus süsteem tuvastab, kas see, kes süsteemi poole pöördub, on see,
kes ta väidab ennast olevat. Tavaliselt kasutatakse tuvastamiseks parooli või sertifikaati.
Kohtvõrkudes autentimiseks tuleb mõelda, kas kasutada keskset haldust või mitte. Ilma domeenita
kohtvõrk on mõistlik ainult väga väikese kasutajate koguse puhul, kui spetsialistil on võimalik neid
seadmeid pidevalt hallata.
Keskseks halduseks on tavaliselt mõistlik kasutada LDAP (kataloogiteenuse) lahendusi nagu Active
Directory Domain Services (https://docs.microsoft.com/en-us/Windows-server/identity/ad-ds/get-
started/virtual-dc/active-directory-domain-services-overview vt hardcopy Identiteedihaldus_1.pdf) ja vt
ka ISKE M 3.64w) või OpenLDAP (https://www.openldap.org/doc/admin24/intro.html vt hardcopy
Identiteedihaldus_2.pdf ja vt ka ISKE M 3.85w ja M 2.403).
Tänapäeval on võimalus tööjaamad ja kasutajad Microsoft Azure AD-sse liita
(https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis vt
hardcopy Identiteedihaldus_3.pdf), aga see eeldab mõne Microsoft Online teenuse tellimist, mille käigus
Azure AD luuakse ning võimalused olenevad paketist. Täpsemalt saab lugeda:
https://msdnshared.blob.core.windows.net/media/2017/04/AzureADSKUsFeatureComparison.pdf (vt
hardcopy Identiteedihaldus_4.pdf). Azure AD pole LDAP ja ning seal ei ole ka kõiki neid võimalusi, mis
Windows AD-l – näiteks ei saa sinna servereid liita ega luua sellisel kujul rühmapoliitikaid nagu Windows
AD puhul. Azure AD võimaldab vajalikke seadistusi teha Intune (eeldab vastava litsentsi olemasolu) või
Azure AD MDM poliitikate abil.
Kuna selles juhendis on tegemist olukorraga, kus võrgus on peamiselt Windows arvutid ja serverid, on
mõistlik kasutada Windows domeeni Active Directory’t (vt ISKE M 2.229), mis võimaldab keskset
kasutajahaldust.
Windows AD puhul peavad kõik Windows tööjaamad ja serverid olema domeeni lisatud. Samuti tuleb
domeeni luua kõigi kasutajate kasutajakonto. Kui kasutaja soovib domeenis olevasse arvutisse sisse
logida, peab ta olema domeeni kasutaja. AD võimaldab paroolipoliitika nõudeid keskselt GPO abil
seadistada.
ISKE punktist M2.11 lähtudes soovitame, et parool oleks vähemalt kaheksakohaline. Pikemaid paroole ei
soovita kasutajatelt ka nõuda, sest siis võib tekkida probleem parooli meeles pidamisega. See võib kaasa
tuua riskikäitumise nagu parooli kirjutamine töölaual olevale paberile või pika, aga kergelt ära arvatava
parooli kasutamine vms.
Parool peaks sisaldama erinevaid sümboleid või numbreid ning suuri ja väikeseid tähti. Parooli tuleks
muuta vähemalt 90 päeva tagant ja varasemat parooli ei tohiks olla võimalik kohe uuesti kasutada.
Kuna Windowsi parooliaken toetab kuni 127 sümbolit, võib parooli alternatiivina soovitada kasutajatel
märgulauset. Märgulause on parool, mis koosneb 4-5 sõnast, mis moodustavad lause (Näiteks:
LehmaPiimOnValge1), mis on pikem, aga samas kasutajatel lihtsam meeles pidada kui suvalistest
kirjamärkidest koostatud parooli. Lauses ei tasuks kasutada liiga tuntud sõnakombinatsioone või
tsitaate.
Kui on olnud mitmeid ebaõnnestunud sisselogimise katseid, tuleks konto lukustada.
Et vähendada kasutajakonto kuritarvitamist selle lekkimisel, tasuks kasutajate sisselogimist piirata ainult
neile määratud tööjaamade ning serveritega (vt punkt 4.1.3).
Kontod tuleks luua nii, et need on seotud konkreetse inimesega. See võimaldab kasutaja tegevust
paremini jälgida ning kontoga kaasnevaid õiguseid saab vastavalt vajadusele nii paremini piirata. See on
eriti tähtis siis, kui tegemist on kolmandate osapooltega (üldise, firma nimega konto puhul pole kerge
kindlaks teha, kes antud kontot kasutas). Vt ka ISKE M 4.340.
Kui tegemist on ajutise kontoga, tuleks kohe kehtestada aegumiskuupäev (vt punkt 4.1.4).
Kõik ebaõnnestunud sisselogimise katsed tuleks logida (vt 7.2.1.1). Teatud seadmete ning kontode puhul
(näiteks administraatori kontod, serveritesse, tulemüüridesse jms seadmetesse logimised, mis on
kõrgema turvalisuse nõuetega) on mõistlik logida ka kõik sisselogimised.
Kasutaja enda kaitsmiseks ei tohi igapäevane töökonto arvutis olla administraatori õigustega. Ka
lokaalseid paroole on soovitav hallata läbi AD, kasutades selles LAPS lahendust. LAPS (Local
Administrator Password Solution) võimaldab hallata lokaalsete administraatorite paroole domeeni
arvutites, paroolid säilitatakse ADs ja nende ligipääsu saab piirata, et ainult vajalike õigustega inimestele
ligipääs võimaldada.
Paroolide turvalisuse tõstmiseks soovitame kasutusele võtta ka Windows Defenderi funktsiooni
Credential Guard, mis piirab paroolidele ligipääsu ainult lubatud süsteemi tarkvaraga ja kaitseb
igasuguseid paroole, mida võidakse hoiustada või rakendustes kasutada. Credential Guard kasutab
virtualiseerimist, et volitusi operatsioonisüsteemis eraldatud konteineris hoiustada, nii et viirused ja
pahavara sellele informatsioonile ligi ei saa. Credential Guardi kasutusele võtmisel peab arvestama, et
osa autentimistest (näiteks NTLMv1 ja MCHAPv2) ei tööta arvutis üldse või töötavad osaliselt, sest
Credential Guard ei toeta neid ebaturvalisuse tõttu. Täpsemalt saab lugeda siit:
https://docs.microsoft.com/en-us/Windows/security/identity-protection/credential-guard/credential-
guard-considerations (vt hardcopy Identiteedihaldus_5.pdf).
Microsoft soovitab paroolide kasutamisest loobuda ja kasutada hoopis kiipkaarte, virtuaalseid kiipkaarte
või Windows Hello for Business. Kuna Microsoft kavatseb tulevikus virtuaalsetest kiipkaartidest loobuda,
siis Windows Hello for Business on mõistlik valik, kui plaanitakse rakendada paroolivaba autentimist.
Windows Hello for Business kohta saab täpsemalt lugeda siit: https://docs.microsoft.com/en-
us/windows/security/identity-protection/hello-for-business/hello-identity-verification (vt hardcopy
Identiteedihaldus_6.pdf).
Osadel rakendustel on ka ADga seotud SSO (Single Sign-On) ehk ühekordne sisselogimine. Sellisel juhul
kasutatakse kasutaja AD kontot, et mõnda seotud rakendusse, veebilehele või teenusesse sisse logida.
4.1.1 MFA (Multifactor authentication) ehk mitmeastmeline autentimine
MFA ehk mitmeastmeline autentimine on turvasüsteem, mis nõuab kasutaja autentimiseks kahte või
enamat autentimismeetodit.
Näiteks lisaks kasutajanimele ja paroolile kasutatakse kas SMSile tulnud koodi, rakenduses olevat
kinnitust/koodi, sõrmejälge, turvaküsimust, sertifikaati vms.
2FA (two-factor authentication) on MFA alamtüüp, mis nõuab kahe autentimismeetodi olemasolu.
Kui mõni rakendus seda toetab, tasub MFA (multi-factor authentication) kindlasti sisse lülitada – eriti
tasub seda teha administraatorite või muude võtmeisikute kontode puhul. Iga toote ja rakenduse puhul
on MFA võimalused erinevad ning tuleb uurida vastava rakenduse dokumentatsiooni. Näiteks Office 365
juhend https://docs.microsoft.com/en-us/Office 365/admin/security-and-compliance/set-up-multi-
factor-authentication?view=Office 365-worldwide (vt hardcopy Andmete_haldus_29.pdf) ja G Suite
juhend
https://support.google.com/cloudidentity/answer/175197?hl=en&ref_topic=2759193&visit_id=636908
479939567405-1025730311&rd=1 (vt hardcopy Andmete_haldus_30.pdf).
Windows tööjaam hetkel MFA võimalust ei paku.
2FA domeeni sisselogimise rakendamiseks saab kasutusele võtta mõne välise vahendi. Näiteks on
võimalik seadistada ID-kaardiga domeeni sisselogimine – sellisel juhul on vaja sisselogimiseks nii ID-
kaarti kui ka PINi. Täpsem juhend: https://www.id.ee/public/1901_-
_ID_kaardi_login_Windows_domeenis.pdf (vt hardcopy Identiteedihaldus_7.pdf). Sarnaste võimalustega
vahend on veel ka YubiKey: https://support.yubico.com/support/solutions/articles/15000006456-
yubikey-smart-card-deployment-guide (vt hardcopy Identiteedihaldus_8.pdf).
4.1.1.1 VPN ja MFA
Kuna VPN võimaldab ligipääsu sisevõrgule, tuleb arvestada ligipääsu turvalisuse tagamisega. Enamasti
on soovimatu ligipääsu põhjuseks nõrgad või varastatud paroolid. Kuna tavaliselt kasutatakse VPN
ligipääsu autentimiseks kasutajanime ja parooli kombinatsiooni, on mõistlik ka seda mitmeastmelise
autentimisega (MFA) turvata. Kindlasti tuleb seda rakendada administraatorkasutajate puhul, kelle
ligipääsud on tavaliselt suuremad, kuid seda tasub kaaluda ka tavakasutajate puhul.
Üks lihtsamaid võimalusi on lisaks kasutajanimele ja paroolile nõuda ka seda, et VPN ühenduse
loomiseks oleks arvutis olemas sertifikaat (vt peatükk 2.1.1.4.4).
OpenVPN kasutab vaikimisi autentimiseks kliendisertifikaati, aga lisaks on võimalik sisse lülitada ka
kasutajanime ja parooli küsimine vastavalt juhendile: https://openvpn.net/community-resources/using-
alternative-authentication-methods/ (vt hardcopy Identiteedihaldus_9.pdf).
Azure AD kasutajad saavad Windows VPN puhul kasutada Azure MFA laiendust, mis võimaldab nõuda
telefoni aplikatsioonist nõustumist (on variant valida ka SMS koodi sisestamine, aga VPN ühenduse
loomisel ei ole asukohta, kuhu seda koodi lisada). Juhendiga saab tutvuda siin:
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension-vpn
(vt hardcopy Identiteedihaldus_10.pdf).
Samuti toetab suurem osa tulemüüri VPN’e MFA’d, näiteks:
Sophos OTB (lisakood paroolile) https://community.sophos.com/kb/en-us/125228 (vt hardcopy
Identiteedihaldus_11.pdf)
Fortinet Fortitoken
https://kb.fortinet.com/kb/viewAttachment.do?attachID=How%20to%20configure%20FortiOS%
20SSL%20VPN%20with%20FortiToken.pdf&documentID=FD33345 (vt hardcopy
Identiteedihaldus_12.pdf)
Cisco https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-
client/213931-configure-anyconnect-secure-mobility-cli.html (vt hardcopy
Identiteedihaldus_13.pdf)
4.1.2 SSO
Ühest küljest võib SSO (Single Sign-On) tähendada seda, et kasutaja kasutab kõikjal sama kontot, mille
autentimine käib ühest kohast ning parooli muutmisel, lukustamisel või eemaldamisel rakendub see
kõikjal, kus SSO on kasutusel. Teine osa SSOst võib tähendada seda, et kasutaja sisestab parooli oma
arvutis vaid korra ning sama sessiooni ajal teistes seotud teenustes parooli uuesti ei küsita.
Esimese variandi näitena võiks välja tuua tuntud teenusepakkujad nagu Google, Facebook. Tihti on
võimalik paljudes teistes teenustes sisselogimiseks või isegi konto loomiseks kasutada antud
teenusepakkujate linke, kasutajalt küsitakse ainult nõusolekut ühe pakkuja käes oleva info edastamiseks
teisele.
Teise variandi näitena võib tuua Microsoft Active Directory. Domeeni liidetud arvutisse sisselogimisest
piisab, et pääseda ligi näiteks Outlooki postkastile, failiserveri jagatud failidele või andmebaasidele.
Ettevõttesisene Active Directory on võimalik siduda ka Microsofti pilveteenustega. Olenevalt
lahendusest on kasutajal lisaparoole sisestamata võimalik ligi pääseda erinevatele Microsofti
pilveteenustele nagu OneDrive, Teams või Sharepoint Online.
SSO teeb administraatorite töö lihtsamaks ning vähendab võimalust ligipääsude eemaldamisel midagi
unustada, sest kui SSO puhul kasutaja eemaldada või ligipääs keelata, rakendub see kõikides teenustes
korraga. Teiseks heaks küljeks on mugavam ja lihtsam kaheastmelise autentimise rakendamine
kasutajatele, mida saab teha ühest kohast kõigile ning ka kasutajatel on mugavam ainult ühe korra sisse
logida. Riskifaktor on, et kasutaja parooli lekkimisel või tema sessiooni ülevõtmisel pääseb rohkematesse
kohtadesse korraga.
4.1.3 Paroolipoliitika GPO
Paroolipoliitika on tavaliselt juba Default Domain Policy’s teatud sätetega olemas.
Olemasolevaid sätteid võib muuta või luua uue GPO kõrgemale domeeni külge (Server manager – tools –
Group Policy Manager). Valida Computer Configuration – Policies – Windows Settings – Security Settings
– Account Policies – Password Policy.
Sisse tuleb lülitada esimene omadus Enforce Password Policy. Soovitatav mäletatavate paroolide arv
(mida ei saa uuesti paroolina kasutada enne uute paroolide arvu täitumist) peaks olema vähemalt 10
parooli. Vastavalt ISKE soovitusele tuleks Maximum password age panna 90 päeva. Minimum password
age tuleks panna 3 päeva – sellega võtame kasutajalt võimaluse mitmekordse järjestikuse
paroolivahetuse abil sama salasõna uuesti kasutusele võtta. Vastvalt ISKE soovitusele tuleks Minimum
password length määrata vähemalt kaheksakohaline. Sisse on vaja lülitada Password must meet
complexity requirements. See määrab, et parool peab olema vähemalt kuuekohaline, parool ei tohi
sisaldada kasutaja nime ning peab sisaldama kolme neist neljast omadusest: suur täht (A kuni Z), väike
täht (a kuni z), number (0 kuni 9), mittetähestiku märk (näiteks !, % jne).
Sätteid saab muuta Configuration – Policies – Windows Settings – Security Settings – Account Policies –
Account Policies. Muuta tuleks Account lockout duration, mis võiks olla 15-30 minutit või kui soovitakse
olukorda rohkem kontrollida, siis panna 0 (sellisel juhul saab ainult AD administraator konto lukust lahti
teha).
Account lockout threshold sätestab, mitu vale parooli peab panema, et konto lukku läheks. Soovitav
oleks valida viis, sest väiksema arvu määramisel tekib palju juhuseid, kus kasutaja ise kogemata parooli
lukku laseb. Reset account lockout counter after tuleks panna sama väärtus, mis lockout aeg.
Lisatud rühmapoliitika näidis nimega 10_Autentimine_ParooliPoliitika.
4.1.4 Paroolipoliitika PSO (Password Settings Objects) abil
GPOs saab paroolinõudeid määratleda ainult kas Default Domain Policys või siis eraldi GPOs, mis on
lingitud domeeni külge ja mis on kõrgema prioriteediga kui Default Domain Policy. Nõudeid on kindlasti
vaja rakendada kogu domeenile, et kõigile oleks rakendatud keskne paroolipoliitika. Nõudeid ei ole
võimalik rakendada erinevatele kasutajatele või osakondadele, kui on vajadus, et kellegi paroolipoliitika
oleks erinev tavapärasest (näiteks administraatoritel või mõnel kasutajal, kes töötab konfidentsiaalsete
materjalidega jne). Alates Windows 2008 serverist on selleks olemas Fine-grained Password policy, mida
saab rakendada otse kasutajatele või gruppidele. Vastavaid seadistusi saab teha kas Active Directory
Administrative Center või Powershelli kaudu. Samuti võimaldab see seadistada rohkem omadusi kui
GPO.
Seadistamise näites loome domeeni administraatorite grupile uue poliitika, kus parooli vanus on
maksimaalselt 30 päeva ja parooli minimaalne pikkus on 20 märki.
Selle poliitika loomiseks tuleb Powershell kaudu anda käsud:
New-ADFineGrainedPasswordPolicy "Admin_PSO" -MaxPasswordAge "30" -Precedence 100 -MinPasswordLength 20 #Käsk, et luua uus paroolipoliitika
Add-ADFineGrainedPasswordPolicySubject -Identity "Admin_PSO" -Subjects “Domain Admins” #Seo loodud paroolipoliitika kasuajagrupiga
Precedence määrab poliitika prioriteedi (mida väiksem number, seda kõrgem prioriteet).
Loodud poliitika vaatamiseks on käsk:
Get-ADFineGrainedPasswordPolicy -Filter { name -like 'Admin_PSO'}
Poliitika muutmiseks on käsk:
Set-ADFineGrainedPasswordPolicy "Admin_PSO" -MaxPasswordAge "10"
Active Directory Admin Center (ADAC) kaudu poliitika loomiseks tuleb see avada ning avanenud
konsoolist minna Treeview vaate peale.
Avanenud kataloogipuus tuleb valida System - Password Settings Container. Seal teha paremklõps, New -
Password Settings
Avanenud aknas saab määrata soovitud paroolipoliitika sätted ja selle, kellele see poliitika rakendub.
Kasutaja paroolipoliitikat saab kontrollida, kui teha ADAC kasutaja peal paremklõps ning valida View
Resultant Password Settings.
4.1.5 Kasutaja sisselogimise piiramine seadmega
Selleks tuleb avada Active directory Users and Computer, leida vastav kasutaja, vajutada Properties ning
avanenud aknas Account. Sealt Log on To…, valida variant The following computers ja lisada arvutid,
kuhu kasutaja võib sisse logida. Kindlasti on vaja lisada ka serverid, millega kasutaja konto otse suhtleb,
nagu domeeni kontrollerid ja näiteks Exchange server.
Seda on võimalik seadistada ka Powershell kaudu:
Set-ADUser testdrone -LogonWorkstations "WIN10"
Tuleb meeles pidada, et nimekirjas peavad olema kõik seadmed, millesse sisse logimine on lubatud, sest
antud säte kirjutab kõik üle.
Kui on palju kasutajaid ja neile kõigile on vaja lisada uus seade (näiteks uus AD), siis tuleks selleks
kasutada skripti:
$kasutajad = (Get-ADUser -Filter {LogonWorkstations -like "*"}).samaccountname
foreach ($kasutaja in $kasutajad)
{
$arvutid = (Get-ADUser -Identity $kasutaja -Properties LogonWorkstations).LogonWorkstations
$arvutid += ",AD3"
Set-ADUser -Identity $kasutaja -LogonWorkstations $arvutid
$arvutid=$null
}
4.1.6 Konto aegumise määramine
Kui tegemist on ajutise kontoga, mille sulgemise aeg on teada, tasuks kohe seadistada konto aegumine.
Ajutise konto näiteks on projektis osalev töötaja, kes on tööl kaks kuud, või väline teenuspartner, kellel
on vaja süsteemile ligipääsu ainult üheks kuuks. Selleks tuleb avada Active directory Users and
Computers, otsida sealt vastav kasutaja, vajutada Properties ning avanenud aknas Account. Seal on väli
Account expire ja saab valida kuupäeva, millal konto aegub.
Powershellis on selleks käsk:
Set-ADAccountExpiration -Identity [kasutajanimi] -DateTime "31.12.2019"
Oluline on tähele panna, et kui see GUI kaudu määrata, on kirjas End of - selle kuupäeva lõpus konto
aegub. Powershell käsuga määratakse aga esimene päev, millal konto peab olema aegunud. Eelmise
käsu tulemus GUI-s on:
Selleks, et teha päring kõigi aegunud kontode kohta (ja need seejärel näiteks eemaldada), saab kasutada
käsku:
Search-ADAccount -AccountExpired | Select-Object Name, SamAccountName, DistinguishedName
4.1.7 LAPS häälestus
Kuigi Windows 10 vaikimisi installi käigus on lokaalne administraatori konto tavaliselt keelatud seisus,
siis enne LAPS programmi installi tasub sellele vaatamata teha GPO, millega ära keelata vaikimisi
administraator ja ka konto, mis arvuti installil lisati (näiteks admin).
Selleks tuleb luua uus GPO selle OU külge, kus on arvutid ja muuta sätet Computer Configuration >
Preferences > Control Panel Settings > Local Users and Groups. Seal tuleb valida New > Local User.
Järgmisena valida User name Administrator ning valikutest valida Account is disabled:
Sama tuleb teha ka teiste kontodega, mida soovitakse sulgeda. Lisatud on rühmapoliitika näidis nimega
11_Autentimine_KeelaAdmin.
Administraatori konto on võimalik sulgeda ka muutes sätet Computer Configuration – Policies –
Windows Settings – Security Settings – Local Policies – Security Options. Sealt tuleb valida omadus
Accounts: Administrator account status ja sätteks valida Disabled. Lisatud on rühmapoliitika näidis
nimega 12_Autentimine_KeelaAdminv2.
LAPS programmi häälestuseks tuleb see alla laadida, paigaldada serverile ja GPO (või SCCM) kaudu
arvutitele. Lisatud on rühmapoliitika näidis nimega 13_Autentimine_LAPS_install_defaultadmin.
Samuti tuleb uuendada AD schema, et seal saaks hoida tööjaamade paroolide informatsiooni.
TechNet gallery’s on selle paigaldamiseks väga hea juhend, mida tasub jälgida:
https://gallery.technet.microsoft.com/Step-by-Step-Deploy-Local-7c9ef772 (vt hardcopy
Identiteedihaldus_14.pdf).
LAPS programmi saab alla laadida lingilt: https://www.microsoft.com/en-us/download/details.aspx?id=46899
TechNeti juhend viitab administraatori vaikekonto kasutamisele – turvakaalutlustel soovitame luua
administreerimiseks uue konto. Selleks peab installi käigus lisama parameetri administraatori nimega
CUSTOMADMINNAME=testadmin. Seetõttu peab GPO puhul installi tegema skripti kaudu või
transformation faili abil. SCCM puhul saab vajalikud parameetrid lisada paketi loomise käigus.
Skriptiga installi tegemiseks tuleb kõigepealt luua skript, mis kontrollib, kas programm on arvutis olemas
ja kui ei ole, siis installeerib selle (muuta administraatori nimi vastavalt oma soovile):
IF EXIST C:\Program Files\LAPS\CSE\AdmPwd.dll GOTO :end
ELSE
msiexec /q /i "\\testserver\install\LAPS.x64.msi" CUSTOMADMINNAME=testadmin
:end
Või powershell skriptiga:
$fileExists= Test-Path -Path "C:\Program Files\LAPS\CSE\AdmPwd.dll" if ($fileExists -eq $False) { msiexec /q /i "\\testserver\install\LAPS.x64.msi" CUSTOMADMINNAME=testadmin }
GPOs minna Computer Configuration – Policies– Windows Settings – Scripts (startup/shutdown). Valida
Startup, sealt Add (kui kasutada PowerShell skripti, siis ka enne valida sakk PowerShell Scripts) ja Browse,
kopeerida skript sinna kausta, valida see ja vajutada OK. Lisatud on rühmapoliitika näidis nimega
14_Autentimine_LAPSInstall.
Peale seda kui GPO levib ja arvutile tehakse restart, peaks programm olema installeeritud.
LAPS sätete GPOd seadistades tuleb määrata parooli pikkus ja selle muutmise sagedus. Kuna tegemist on administraatori õigustes kontoga, võiks parool olla pikem ja vahetamise sagedus tihedam kui tavakasutajal (näiteks 14 märki ning muutmine iga 30 päeva tagant).
Samuti tasuks GPOs muuta sätet name of administrator account to manage, et luua uus administraatorkonto, mida ründajatel ei ole kerge ära arvata.
4.1.8 Windows Defender Credential Guard
Credential Guard on saadaval ainult Windows 10 Enterprise’s. Credential Guard sisselülitamiseks tuleb
teha uus GPO selle OU külge, kus asuvad arvutid. Lisatud on rühmapoliitika näidis
20_GPO_DeviceGuard.
GPO muutmiseks tuleb minna Computer Configuration – Policies - Administrative Templates – System -
Device Guard.
Kuvatud on võimalus Turn on Virtualization Based Security, sellele tuleb panna Enabled. Select Platform
Security Level valikuks teha Secure Boot and DMA Protection ning sealt Credential Guard Configuration
panna Enabled with UEFI lock. Enabled with UEFI lock tähendab seda, et GPO abil ei ole võimalik seda
välja lülitada. Välja lülitamiseks peab administraator arvutisse logima ja sealt nimetatud sätte välja
lülitama.
4.2 Tulemüüri autentimine
Uuematel tulemüüridel on võimalus seadistada kasutajaid ja teha tulemüürireegleid vastavalt nendele
kasutajatele.
Kasutajapõhised reeglid võimaldavad paremini kontrollida võõraste seadmete ligipääsu sisevõrgust
mujale (näiteks autentimata kasutajad ei pääse Internetti) ja teha kasutajapõhiseid ligipääsureegleid nii,
et kasutajad pääseksid ligi ainult endale vajalikele ressurssidele. Näiteks raamatupidajad pääsevad ligi
majandustarkvara pakkuja kaughaldusele, aga vaikimisi pole see lubatud, või külaliskasutajad saavad
Internetis juurdepääsu ainult teatud teenustele.
Kasutajad saavad tulemüüri autentida tavaliselt näiteks arvutis oleva klientprogrammiga või logides sisse
läbi veebiliidese. Paljud tulemüürid pakuvad võimalust koos AD’ga seadistada ka SSO. Tavaliselt eeldab
see tulemüüri sidumist AD’ga ja tulemüüri agendi installi AD serverisse, mis saadab kasutaja
sisselogimise informatsiooni tulemüürile nii, et tulemüür teab, millisest seadmest ja milline kasutaja on
sisse loginud.
Sophos tulemüüri SSO seadistamine:
https://community.sophos.com/kb/en-us/123156 (vt hardcopy Identiteedihaldus_15.pdf).
Fortigate tulemüüri SSO seadistamine:
https://cookbook.fortinet.com/providing-single-sign-using-ldap-fsso-agent-advanced-mode-expert/ (vt
hardcopy Identiteedihaldus_16.pdf).
5 BYOD (bring your own device)
Tänapäeval, kus elektroonika on kergesti kättesaadav ja levinud, on järjest tavapärasem, et kasutajad
soovivad töökohas ka oma isiklikke seadmeid kasutada.
Väga levinud on isiklike mobiiltelefonide kasutamine, aga järjest tavalisemaks hakkab saama ka isikliku
arvuti (tööjaama) tööl kasutamine. Lisaks tuuakse tööle ka isiklikke USB pulkasid ja väliseid kõvakettad,
mis võimaldavad kiiresti ja lihtsalt andmeid sisevõrgust välisele andmekandjale liigutada.
Kui asutuse võrgus on lubatud isiklikke seadmeid kasutada, peab kindlasti looma BYOD poliitika, mis
määratleb tingimused ja kehtestab reeglid.
Põhilised reeglid, mida BYOD poliitikasse lisada:
1. Määratleda, millised turvanõuded seadmele kehtivad – millised peavad olema paroolid (nende
keerukus, parooli vahetamise sagedus), millised funktsioonid peavad olema seadmetel toetatud
(näiteks kui seade ei toeta krüpteerimist, siis seda võrku ei lubata) ja millised rakendused või
rakenduse versioonid (kui on teada, et mingi kindel versioon on turvaauguga) on keelatud.
2. Koostada keelatud seadmete nimekiri. Kõik seadmed ei toeta määratletud turvanõudeid.
Seetõttu tuleb koostada nimekiri seadmetest ja operatsioonisüsteemidest, mida ei tohi võrku
lubada. Kui on teada, et teatud telefoni mudelil või näiteks Androidi versioonil on turvaauk, siis
tuleks need lisada keelatud seadmete nimekirja. Samuti peaks olema keelatud ettevõtte võrku
tuua näiteks Windows XP arvutit, mis ei saa enam turvauuendusi. Lisaks peaksid olema keelatud
ka kõikvõimalikud muud võrguseadmed (kasutaja isiklikud switchid, ruuterid, WiFi seadmed jne).
3. Seadmete registreerimise protsess. BYOD poliitikas tuleks määratleda, et ainult registreeritud
seadmed saaksid võrku ja registreerimata seadmete võrku pääsemist peaks tehniliselt piirama.
IT osakond/administraatorid peaksid haldama lubatud seadmete registrit.
4. Millised ligipääsud on BYOD seadmetel lubatud (kindlasti ei peaks BYOD seadmed saama
kõikjale samamoodi, kui domeenis olevad arvutid) ja mida teha konfidentsiaalsete andmetega.
Tuleks määratleda, milliseid andmeid tohib antud seadmetes töödelda, kas seadmed peavad
olema krüpteeritud (USB pulkadele ja välistele kettaseadmetele tuleks seda kindlasti rakendada)
ja mida teha seadme kaotuse või varguse puhul või siis, kui töötaja lahkub töölt.
5. Kasutaja nõusolek – kasutajad peavad tutvuma kõigi BYOD poliitika reeglite ning nõuetega,
peavad nendega nõustuma ning seda tõendama oma allkirjaga (muidu seadet võrku ei lubata).
Juhendis on toodud soovitused, mida BYOD rakendamise puhul arvestada. BYOD seadmete puhul peaks
jälgima ka ISKE B 5.14 soovitusi.
5.1 Võrgu seadistus
5.1.1 Võrgu eraldamine
Kasutaja enda toodud seadmete eraldamiseks ja paremaks kontrollimiseks tuleks eraldada võrk, kuhu
need seadmed pääsevad. Kuna tavaliselt on tegemist mobiilsete seadmetega, siis kõige mõistlikum on
luua nende jaoks eraldi WLAN võrk.
Eraldatud võrk võimaldab paremini selle võrguliiklust kontrollida ning tuvastada, millised ligipääsud
sinna võrku ning sealt võrgust on. Lisaks on turvaintsidentide korral eraldatud võrgu osa kerge kogu
ülejäänud võrgust eraldada. Üldiselt tasub eraldi võrgud teha kõikidele seadmetele nagu serverid,
tööjaamad, võrguseadmed, külaliste seadmed jne (ISKE M 5.61 ja M 5.62). Selles juhendis keskendume
põhiliselt BYOD seadmetele võrgu eraldamisele.
Tavaliselt on ettevõtetes külalistele mõeldud WiFi võrk juba olemas, kuid soovitav oleks vastavalt
tulemüüri/WiFi seadmete võimalustele luua täiesti uus eraldatud WiFi võrk, kuhu saab luua
ligipääsureeglid, mis pole külaliste võrgus lubatud. See võimaldab eraldi jälgida nii külaliste võrgu
seadmeid kui ka lubatud BYOD seadmeid. BYOD seadmetele mõeldud ligipääsu reeglistikku on
soovitatav hoida eraldi võrgus, et ka ligipääsureeglistikud oleksid võrgupõhiselt eraldatud. See vähendab
ohtu, et inimliku vea tõttu lubatakse suuremate õigustega ligipääse suvalisele külalisseadmele.
Kindlasti ei ole soovitatav BYOD seadet lubada otse sisevõrku, sest nagu eespool mainitud, võimaldab
eraldatud võrk paremini jälgida, mida nende seadmetega tehakse ja aitab vähendada inimliku eksituse
ohtu.
Seega peaks BYOD võrk olema sisevõrgust eraldatud võrgusegment ja sellele ligipääs võiks olla täiendava
kaitsemeetodina (lisaks paroolile jne) piiratud näiteks seadme MAC aadressiga. Lokaalse MAC filtri
tegemise sätted olenevad WiFi seadme tootjast ja selleks tuleks uurida nende seadmete
dokumentatsiooni.
Näiteks:
Cisco
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/91901-mac-
filters-wlcs-config.html (vt hardcopy BYOD_1.pdf)
Ruckus
https://docs.ruckuswireless.com/unleashed/200.1.9.12/t-CreateNewL2ACL.html (vt hardcopy
BYOD_2.pdf)
Aruba
https://www.arubanetworks.com/techdocs/Instant_41_Mobile/Advanced/Content/UG_files/Au
thentication/MAC_Authentication.htm#Configur (vt hardcopy BYOD_3.pdf)
Nagu poliitika loomise kohta kirjeldati, tuleb peale ühenduse loomist antud WiFi võrku luua ka reeglistik
(kuhu sealt võrgust edasi pääseb). Olenevalt võrgu seadistusest ja tulemüürist on võimalik lubada
otseligipääsu sisevõrgu teenustele, aga see ei ole soovitatav, sest MAC aadressi on võimalik peita ja nii
ligipääsu petta.
Avalike teenuste ligipääsud (avalik veebileht serveris, Exchange serveri OWA, Internet jne) võib lubada
sarnaselt külaliste võrgu ligipääsudega, aga ülejäänud ligipääsudele tuleks seadistada teine autentimise
aste. Selleks on mitmeid erinevaid võimalusi:
1. Luua sisevõrku VPN ühendus ja edasi toimub ligipääs vastavalt VPN sätetele.
2. Luua ligipääs terminaliserverile, mille kaudu pääseb vajalikele teenustele ligi. Nii on võimalik
piirata andmete kopeerimist ning kogu töö toimub sisevõrgus oleval seadmel.
3. Logida sisse tulemüüri AD kontoga. Selleks tuleb tulemüüri luua vastavad reeglid, mis sellisel
juhul aktiveeruvad. Tulemüüri ja AD vahelist seost on kirjeldatud lõigus 4.2.
4. Sisemiste veebiteenuste ligipääsu võib luua läbi proksiserveri (näiteks Web Application Proxy
vms).
5.
5.1.2 Switchide seadistus
Sülearvutite (ja ka muude Ethernet liidesega seadmete) puhul on oht, et kasutaja võib oma seadme
lihtsalt seinas olevasse vabasse pesasse ühendada. Siis eespool kirjeldatud eraldatud WiFi võrgust kasu
ei ole ja tundmatu seade pääseb lihtsalt sisevõrku.
Soovitused selliseks olukorraks:
1. Kasutuses mitte olevad seinapesad välja lülitada.
2. Avalikes ruumides, kuhu võib sattuda külalisi ning võib vaja minna LAN ühendusi (seminari-
/koosolekusaalid, ooteruum), lubada ainult külaliste võrgu kasutamist.
3. Ülejäänud portidelt nõuda 802.1X autentimist ja kui autentimine ebaõnnestub, suunata BYOD
VLANi.
Varem oli üheks ligipääsu kontrollvahendiks Windows serveris ja tööjaamas NAP (Network Access
Protocol). See oli Windowsi enda serverites olev vahend, mis võimaldas administraatoritel kontrollida
võrku ühendatavate seadmete tervist ja vastavalt sellele seadistada piiranguid ja sätteid. Windows
Server 2016 ja Windows 10 seda enam ei toeta, see tugi kadus juba alates Windows Server 2012 R2
versioonist. Üks põhjus selle funktsionaalsuse eemaldamiseks oli, et see ei toetanud hästi BYOD. NAP
seadistuse kohta on võimalik lugeda siit: http://www.electricmonk.org.uk/2013/12/13/nap-network-
access-protection-on-Windows-server-2012/ (vt hardcopy BYOD_4.pdf).
5.1.2.1 Pordipõhine juurdepääsupoliitika (802.1X)
Enamikes switchides on koostöös Windows Serveriga võimalik seadistada tööjaama autentimine 802.1X
standardit kasutades.
Switchide seadistused olenevad tootjast ja tuleks uurida tootja dokumentatsiooni.
HP: http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/WB/15-18/5998-
8152_wb_2920_asg/content/ch13.html (vt hardcopy BYOD_5.pdf)
Cisco:https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-
2_55_se/configuration/guide/3750xscg/sw8021x.html (vt hardcopy BYOD_6.pdf)
Juniper: https://www.juniper.net/documentation/en_US/junos/topics/topic-map/802-1x-
authentication-switching-devices.html (vt hardcopy BYOD_7.pdf)
Nende seadistuste puhul tuleb domeeniks määrata oma Windows domeen, RADIUS serveriks NPS server
ja autentimise meetodiks EAP. Autenditud võrgu VLANiks tuleb määrata sisevõrgu VLAN ja autentimata
võrgu VLANiks BYOD VLAN. Kui switch ei toeta dünaamilisi VLANe, siis autentimise ebaõnnestumise
korral ei saa tööjaam võrguga ühendust.
Enne kui portidele rakendada autentimise nõue, tuleks teha Windows serveri seadistused.
Nende seadistuse eelduseks on installeeritud NPS server: https://docs.microsoft.com/en-us/Windows-
server/networking/technologies/nps/nps-manage-install (vt hardcopy BYOD_8.pdf).
1. Seadistada server switchides RADIUS serveriks.
2. Kui switchdes on RADIUS server seadistatud, siis need switchid tuleks serveris lisada RADIUS
kliendiks.
Powershell kaudu saab need lisada käsuga:
New-NpsRadiusClient -Address "192.168.23.11" -Name "Switch2" -SharedSecret "SalajaneParool"
GUI kaudu seadistamiseks:
Server Manager – Tools - Network Policy Server – RAIDUS Clients and Servers – RADIUS Clients -
New. Seal seadistada nimetus switchile (mille järgi on seda kerge tuvastada), IP aadress või DNS
nimetus ning ka shared secret.
Shared secret on sama, mis seadistati switchis RADIUS serveri määramisel. Kui switche on palju,
siis võib olla mõistlik seadistada Shared secret Template ehk üks parool kõigi switchide puhul.
Network Policy Server konsoolist valida Template Management – Shared Secrets – paremklõps
ja New. Defineerida nimetus ja lisada sinna parool.
Nüüd saab uue RADIUS kliendi lisamisel valida kohe secret template ja ei pea parooli eraldi
sisestama.
3. Luua uus NPS poliitika. Selleks tuleb teha paremklõps Network Policies peal ja valida New.
Määrata sobiv nimi (näiteks: 802.1x autentimine vms), type of Network Access jätta Unspecified
ja valida Next. Conditions alla lisada Machine Group Domain Computers (et sisevõrku pääseks
ainult domeeniarvutid) ning NAS port type Ethernet ja seejärel valida Next.
4. Järgmisel lehel jätta valikuks Access granted ja valida Next.
Autentimise tüüpide juurest eemaldada kõik muud autentimise tüübid ja lisada EAP Types alla
Microsoft: Protected EAP (PEAP), valida Edit ja sealt omakorda määrata EAP Types alla Smart
Card or other certificate.
Muud autentimise viisid ei toimi kui Credential Guard on sisse lülitatud. Järgnevatel lehekülgedel
ei ole vaja midagi muuta ja võib valida Next kuni saab valida Finish. Siis on serveri seadistus
tehtud.
5. Tööjaama seadistuseks on vaja kahte tegevust:
a. Seadistada tööjaamade automaatne sertifikaadi päring ja uuendamine. Sertifikaadi
seadistus tuleb teha sarnaselt punktis VPN kirjeldatud uue sertifikaadi loomisele.
Sertifikaadi aluseks võtta Users sertifikaadi malli asemel Computer sertifikaadi mall.
Tuleb luua ka uus Autoenrollment GPO, mis lubab tööjaamadel automaatselt sertifikaati
pärida. Selleks tuleb GPO luua selle OU külge, kus arvutid asuvad. Sätetes määrata
Computer Configuration – Policies – Windows Settings – Security Settings – Public Key
Policies – Certificate Services Client – Auto-Enrollment. Valida Configuration model
Enabled ning lisada linnukesed sätetele Renew expired certificates, Update pending
certificates, and remove revoked certificates ja Update certificates that use certificate
templates. Lisatud on rühmapoliitika näidis 15_BYOD_Computer_AutoEnroll.
b. Tööjaamas sisse lülitada wired auth teenus ning lubada 802.1x autentimine.
Domeeni tööjaamades saab seda teha läbi GPO. Selleks tuleb uus GPO luua (server
manager – tools – Group Policy Manager) selle OU külge, kus arvutid asuvad. Lisatud on
rühmapoliitika näidis nimega 16_BYOD_802.1x wired auth. Seadistada tuleb järgnevad
sätted:
i. Computer Configuration – Policies – Windows Settings – Security Settings –
System Services. Nimekirjast tuleb otsida Wired AutoConfig, see avada, teha
linnuke sättele Define this policy setting. Select service startup mode alt valida
Automatic.
ii. Computer Configuration – Policies – Windows Settings – Security Settings –
Wired Network (IEEE 802.3) Policies ja teha sellel paremklõps Create a new
wired Network policy for Windows Vista and Later Releases. General vahelelel
määrata antud poliitika nimi ja kirjeldus (näiteks test.local ja test.local wired
auth vms) . Security alt teha linnuke Enable IEEE 802.1x authentication for
Network Access. Select a network authentication method alt määrata Microsoft:
Protected EAP (PEAP) ja selle Properties alt määrata omadus Select
authentication Method – Smart Card or Other Certificate. Authentication
Mehtod alt valida: Computer Only, Max authentication failure jätta 1.
6. Kui GPO on loodud ja arvutitesse levinud, võib switchi portide seadistuse aktiveerida.
Kui arvuti ei suuda nüüd mingil põhjusel võrku autentida, liigutatakse see BYOD võrku.
5.2 Riistvaraliidesed
Kuna riistvaraliidesed nagu USB, Firewire jms võimaldavad väga kiirelt andmeid tööjaamadest liigutada
ja samas on nende seadmete puhul ka andmete kaotuse risk väga kõrge, siis tuleb neid seadmeid
kontrolli all hoida. Seda nii asutuse poolt töötajatele pakutud kui ka töötaja enda seadmete puhul.
Kindlasti peaks kõik need seadmed olema krüpteeritud (võib kasutada Bitlockerit, andmekandja oma
vahendeid vms). Samuti tuleks kõigi taoliste seadmete kohta registrit pidada (BYOD puhul kõigi BYOD
seadmete kohta).
Selleks, et kasutajad mittelubatuid seadmeid ei kasutaks, tuleks ülejäänud seadmed arvutites keelata.
Selleks on võimalik seadistada GPO. GPOs saab määrata, millised seadmed pole keelatud ning see
võimaldab lubada ainult registreeritud ja asutuse lubatud seadmeid.
On ka kolmandate osapoolte vahendeid (tavaliselt viirustõrjeprogrammid), mis võimaldavad seadmete
piiranguid seadistada. Nende lahenduste eelis on see, et üldiselt jõuavad muudatused arvutisse kiiremini
kui GPO puhul, samuti saab piiranguid paremini kontrollida iga arvuti kohta eraldi ning teha raporteid
või lisada kommentaare, mis pole GPO lahenduse puhul võimalik.
Sellised lahendused on näiteks:
ESET https://help.eset.com/ees_mac/6/en-US/ud_devicecontrol.html?ud_devicecontrol_rules.html (vt
hardcopy BYOD_9.pdf)
F-Secure https://community.F-Secure.com/t5/Business/Blocking-device-access-using/ta-p/91439 (vt
hardcopy BYOD_10.pdf)
McAfee https://www.mcafee.com/enterprise/en-us/assets/data-sheets/ds-device-control.pdf (vt
hardcopy BYOD_11.pdf)
DeviceLock https://www.devicelock.com/products/technology.html (vt hardcopy BYOD_12.pdf)
GPO seadistamiseks tuleb GPO luua sellesse harusse, kus on arvutid. Selle seadistuse eripära on, et
ükskõik milliste seadmete install pole lubatud. Lisatud on rühmapoliitika näidis
17_BYOD_DisableDeviceInstall.
Seadistustes tuleb minna Computer Configuration – Policies – Administrative Templates – System -
Device Installation – Device Installation restrictions. Seal on võimalik muuta kolme omadust:
1. Prevent installation of devices not described by other policy settings – valida Enabled ja OK.
2. Display a custom message when installation is prevented by a policy setting – valida Enabled ja
lisada tekst, mida kasutajale kuvatakse kui ta midagi installeerida proovib. Näiteks „Teie IT
osakond ei luba seda seadet“.
3. Allow installation of devices that match any of these device IDs, valida Enabled ja Show alla
lisada IDd, milliseid seadmeid on lubatud installeerida. Et oma võrgus vajalikke seadmeid
tuvastada, on soovitav võtta uus arvuti, kuhu takistamise GPO on rakendunud ja vaadata, mida
seadmete lisamisel blokeeritakse. Soovitav on kohe lisada järgmised seadmed: gencdrom
(DVD/CD-ROM drive), {e0cbf06c-cd8b-4647-bb8a-263b43f0f974} (Bluetooth seadmed),
{6bdd1fc6-810f-11d0-bec7-08002be2092f} (kaamerad ja skännerid), {50dd5230-ba8a-11d1-
bf5d-0000f805f530} (kaardilugeja), {4d36e979-e325-11ce-bfc1-08002be10318} (printerid),
{4d36e978-e325-11ce-bfc1-08002be10318} (COM ja LTP pordid), USB\Class_E0 (juhtmevabad
seadmed) , SWD\PRINTENUM\ (print järjekord Windows 10 puhul), HID_DEVICE (hiir ja
klaviatuur). Kui on soov lubada konkreetne USB seade, siis tuleks sinna lisada näiteks
USBSTOR\DiskADATA___.
Seadmeid saab lubada või keelata ka läbi tooteklasside, kasutades selleks rühmapoliitika omadusi
Prevent/Allow Installation of devices using drivers that match these device setup classes. Nende kohta
saab täpsemalt lugeda siit:
https://getadmx.com/?Category=Windows_10_2016&Policy=Microsoft.Policies.DeviceInstallation::Devi
ceInstall_Classes_Allow (vt hardcopy BYOD_13.pdf) ja
https://getadmx.com/?Category=Windows_10_2016&Policy=Microsoft.Policies.DeviceInstallation::Devi
ceInstall_Classes_Deny (vt hardcopy BYOD_14.pdf) ning
https://www.anotherwindowsblog.com/2012/08/how-to-prevent-devices-from-installing-in-
windows.html (vt hardcopy BYOD_15.pdf).
5.3 Mobiilsed seadmed (telefonid, sülearvutid ja tahvelarvutid)
Väga levinud BYOD seadmed on telefonid ja tahvelarvutid, mille puhul ei pruugita isegi mõelda, et neid
peaks kuidagi piirama. Töökoha e-posti seadistamine nutiseadmesse on väga levinud. Tihtipeale ei
pakugi asutus eraldi nutiseadet, aga ikka on vaja e-kirju telefonis lugeda.
Kuna e-kirjades on tihtipeale konfidentsiaalseid ja vaid ettevõttesiseseks kasutamiseks mõeldud
andmeid, tuleb ka neile seadmetele piirangud seada. Kõik töötajate nutiseadmed tuleks registreerida ja
võimalusel seadistama piirangud, et töötaja ei saaks enne IT osakonna kinnitust ise e-posti oma
seadmetesse seadistada. Registreerimisel saab kontrollida, kas tegemist on lubatud seadmega, kas see
on parooliga kaitstud, kas on olemas viirustõrje ja muid vajalikke sätteid. Paljude e-posti
teenusepakkujate puhul ei ole võimalik seda piirata, aga Exchange ja Office 365 vahenditega on see
võimalik. Seal saab määrata, millised nõuded on seadmele kehtestatud (nt parool) ja seadet on võimalik
kaugelt puhastada, kui see peaks ära kaduma.
Kasutada saab ka erinevaid MDM lahendusi. MDM (Mobile Device Managment) on lahendus, mis
võimaldab kõiki mobiilseid seadmeid keskselt hallata ning neile turvanõudeid rakendada (näiteks
lubatud rakendused, paroolide tugevusnõuded, krüpteeringu nõudmine, samuti erinevad
konfiguratsioonimuudatused ja sertifikaatide haldus). MDM puhul ei ole tähtis, kas seade on domeenis
või see on kasutaja isiklik seade. Kui vanasti tähendas MDM peamiselt mobiilsete seadmete nagu
nutitelefonid ja tahvelarvutid haldust, siis osa MDMe võimaldab hallata ka sülearvuteid.
MDM võimaldab tihtipeale tuvastada ka seadme asukohta ja vajadusel keskselt seadet puhastada.
Kuna MDM ja Office 365 poliitika on kontrollivad ja annavad asutuse IT osakonnale käsutuse seadme
üle, tuleks sellest kasutajat teavitada. Kasutajad ei pruugi soovida sellist kontrolli oma isiklikule
seadmele kehtestada, kuid sellisel juhul ei tohiks neil lubada oma nutitelefonis e-posti seadistada ega
muid asutuse teenuseid kasutada. Võimalik lahendus, kui teisiti kokkuleppele ei jõuta, võib olla asutuse
antud mobiiltelefon.
Tuntumad MDM lahendused on:
Microsoft Intune (võimaldab ka sülearvuteid hallata) https://www.microsoft.com/en-
us/enterprise-mobility-security/microsoft-intune
Cisco Meraki https://meraki.cisco.com/products/systems-manager
Sophos MDM https://www.sophos.com/de-de/solutions/initiatives/mobility.aspx.
Vmware AirWatch (võimaldab ka sülearvuteid hallata) https://www.air-watch.com/
Jamf Pro https://www.jamf.com/products/jamf-pro/
Ka Office 365 sisaldab MDMi, aga kuna ActiveSynci poliitika hõlmab juba kõike vajalikku ning on
kasutajale mugavam, ei pruugi selle seadistamine olla mõistlik.
5.3.1 Office 365 mobiilipoliitika loomine
Kui kasutusel on Exchange Online, siis pole nutiseadmete kontrollimiseks MDMi otseselt vaja. Exchange
ActiveSync võimaldab ühendust piirata ja ühenduses olevatele seadmetele nõudeid seadistada.
Office 365 ActiveSync seadistused on ka Exchange meiliserveri puhul sarnased. Seal saab määrata, millal
lubatakse seadmed Exchange ActiveSync teenusega ühendada. Täpsemalt saab selle kohta lugeda siit:
https://www.johnmcgrathonline.com/2018/05/25/mobile-device-and-application-management-mdm-
mam-exchange-activesync-eas/ (vt hardcopy BYOD_16.pdf).
Vaikimisi sätetes võivad kõik seadmed Exchange külge ühenduda ja eraldi kinnitust pole vaja. Soovitame
muuta seda nii, et Exchange ActiveSync Access Settings oleks Quarantine. Siis saadetakse ühenduse
taotlus määratud administraatoritele ja kasutaja saab teavituse, et ühenduse loomiseks tuleb pöörduda
IT osakonna poole. Peale seadme BYOD registris registreerimist võivad administraatorid telefoni
ühendamise lubada.
Samuti on võimalik teha reegleid, mis teatud seadmed ja rakendused kohe blokeerivad (näiteks keelatud
seadmete tabeli järgi). Selleks tuleks Device Access Rules alla teha uus reegel. Määrata Block Access ja
siis mobiili või rakenduse versioon, millega Exchange serveriga ei või ühendust luua. Powershell kaudu
on võimalik täpsemalt määrata, mis mudelit või rakenduse versiooni blokeeritakse. Täpsemalt saab käsu
ja selle parameetrite kohta lugeda siit: https://docs.microsoft.com/en-
us/Powershell/module/exchange/devices/new-activesyncdeviceaccessrule?view=exchange-ps (vt
hardcopy BYOD_17.pdf).
Seadistada tuleks ka Mobile Device Mailbox policy.
Vaikimisi poliitika ei nõua seadmetelt midagi ja lubab sünkroniseerimist kui seade ei vasta poliitikale.
Tuleks luua uus poliitika ja määrata see uueks vaikimisi poliitikaks. Kindlasti ei tohiks sünkroniseerimist
lubada kui seade ei vasta poliitikanõuetele. Veebiliidese kaudu saab ainult teatud omadusi muuta – saab
määrata, kas parool on kohustuslik, kas seade peab olema krüpteeritud, samuti parooli pikkust ja
keerukust. Soovitame kindlasti sisse lülitada parooli nõudmine, parooli pikkuse ja vahetamise sageduse
seadistus. Ülejäänud sätted tuleb määratleda vastavalt BYOD poliitikas määratletud nõuetele.
Rohkem omadusi nagu kaamera lubamine, SD kaardi lubamine, sõnumi saatmise lubamine jne saab
seadistada Powershell käsuga.
Uue poliitika loomiseks:
New-MobileDevice-mailboxPolicy -Name Nutipoliitika -PasswordEnabled $true -AlphanumericPasswordRequired $true -IsDefault $true
Sama poliitika sätete muutmiseks:
Set-MobileDevice-mailboxPolicy -Identity Nutipoliitika -AllowStorageCard $true -AllowPOPIMAPE-mail $false -AllowBluetooth Disable
See poliitika lubab SD kaardid, keelab POPIMAP e-posti kontod ja Bluetooth seadmed.
Täpsemalt saab Powershell käskude ja võimalike seadistatavate omaduste kohta lugeda siit:
1. Üldine teave - https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-
online/exchange-activesync/mobile-device-mailbox-policies (vt hardcopy BYOD_18.pdf)
2. New-MobileDevice-mailboxPolicy - https://docs.microsoft.com/en-
us/Powershell/module/exchange/devices/new-mobiledevice-mailboxpolicy?view=exchange-ps
(vt hardcopy BYOD_19.pdf)
3. Set-MobileDevice-mailboxPolicy - https://docs.microsoft.com/en-
us/Powershell/module/exchange/devices/set-mobiledevice-mailboxpolicy?view=exchange-ps
(vt hardcopy BYOD_20.pdf)
5.4 Muud soovitused
Kuna tööjaamad võimaldavad endas hoida ja töödelda rohkem informatsiooni kui mobiilsed seadmed,
peaks nende BYOD õigused olema rohkem piiratud.
Samuti võib kontole sisselogimise piirata ainult tööajaga. Nii on võimalik vähendada tõenäosust, et
kasutaja saab väljaspool tööaega, kui jälgimine ei ole nii suur, tööressurssidega kahtlaseid toiminguid
teha. Selle piirangu puhul tuleb kindlasti arvestada, et töötaja ei saa siis väljaspool traditsioonilist
tööaega tööd teha, antud piirang on kasutajapõhine ja kehtib ka siis, kui logida sisse tööandja antud
seadmesse. Kui on teada, et kasutaja peab tööd tegema ka väljaspool tööaega või kasutab ka ettevõtte
antud seadet, siis ei pruugi see olla hea piirang või tuleb selliseks olukorraks mõelda eraldi protseduur
(näiteks kui on vaja väljaspool tööaega tööd teha, siis annab kasutaja sellest IT-töötajatele teada ning
need lubavad seda sellel päeval).
Piiranguid saab muuta AD kaudu:
Tuleb minna Active Directory Users and Computers, avada kasutaja Properties, valida Account vaheleht ja
sealt valik Logon Hours… Sealt saab näiteks määratleda, et kasutaja kontoga sisselogimine on lubatud
ainult ajavahemikus 07:00-18:00. Näiteks:
Tasub teha ka eraldi BYOD grupp, kelle tegevusi failidega täpsemalt logitakse. Kui tavaliselt soovitatakse
logida ainult ebaõnnestunud tegevusi ja kustutamist, siis BYOD kasutaja puhul tuleb logida kõiki tegevusi
failidega. Nii on võimalik tuvastada, kui kasutaja hakkab näiteks faile enda arvutisse kopeerima. Logimise
seadistamisest on täpsemalt kirjutatud peatükis 7.
Kindlasti tuleb BYOD sülearvutitele kehtestada samad nõuded nagu teistele asutuste sülearvutitele
(krüpteering, VPN, viirustõrje asutuse poolt) ja soovitada kasutajatele luua oma seadmesse tööasjadeks
eraldi konto, mis poleks administraatori õigustega. Kui on Azure AD võimalus, siis võib arvuti lisada
Azure AD-sse ja määrata, et ettevõtte andmetele saab ligi kasutades just Azure AD kontot.
Ettevõtte andmetele ligipääsuks on soovitav kaaluda terminaliteenuse kasutuselevõtmist, sest siis
kasutatakse andmeid ettevõtte võrgus ja terminalis saab piirata andmete kopeerimist.
6 Rühmapoliitikate rakendamine Windows 10 põhises kohtvõrgus
Rühmapoliitika on Microsoft Windwos Active Directory lisa, mis võimaldab täiendavat kontrolli
kasutajate ja arvutite kontode üle. See võimaldab kasutaja arvutit keskselt hallata ja seadistada, andes
sellega lisaturbe võimaluse. Rühmapoliitka iseenesest on hulk süsteemiadministraatorite loodud
seadistusi, mis on seotud ühe või mitme Active Directory konteineriga (domeenid, OUd, saidid).
Lisavõimalusena on Microsoftil seadmete haldus läbi MDM (Mobile Device Management), kuid see
nõuab Office 365 litsentsi ning Microsoft Intune olemasolu, täpsemat teavet saab siit:
https://docs.microsoft.com/en-us/windows/client-management/manage-windows-10-in-your-
organization-modern-management (vt hardcopy Rühmapoliitika_1.pdf).
Rühmapoliitika eelised:
Lihtsustab IT osakonna tööd – uute kasutajate seadistamisel saab olemasolevaid GPOsid
kasutada.
Võimaldab poliitikate kaudu tarkvara levitada ja neile seadistused määrata.
Paroolipoliitika seadistus – saab määrata kasutajate paroolidele kehtestatavad nõuded.
GPO puudused:
Rakendumiseks on vajalik arvuti restart või kasutaja sisse logimine – puudub ülevaade, kas
kasutajad saavad poliitika kätte.
Poliitika uueneb vaikimisi 90 kuni 120 minuti järel. Liiga tihti uuendamine koormab võrku ja liiga
harva uuendamisel võib vajaliku poliitika levimine liialt kaua aega võtta.
Tarkvara paigaldus läbi Powershelli võib olla palju kiirem ja lihtsam.
6.1 Seadistamine
Rühmapoliitka objektid protsessitakse loogilises järjekorras:
1. Lokaalne poliitika
2. Saidi poliitka
3. Domeeni poliitika
4. OUde poliitika – rakendub ka hierarhiliselt
Rühmapoliitka seadistamine käib lokaalses tööjaamas Local Group Policy Editoris, selle saab avada
käsurealt gpedit.msc ja keskselt Active Directory serveris tuleb avada Group Policy Management CMD
gpme.msc.
Active Directory serveris käib rühmapoliitika halduse paigaldus järgnevalt: Serveri alt valida Add Roles
and Features ja paigaldada Group Policy Management.
Rühmapoliitikate seadistamise server. Administratiivtööriistade alt tuleb avada Group Policy
Management ja esmalt luua uus rühmapoliitika Group Policy Objects alla ning seejärel linkida vastavasse
OUsse. Soovitav on hoida rühmapoliitika objektide struktuur lihtne ja arusaadav. Kõiki poliitikaid ei ole
hea ühte poliitikasse lisada, eriti siis, kui erinevatele tööjaamadele on erinevad poliitikad, kuid need
asuvad samas domeeni OUs. Poliitika rakendumist vajalikele arvutitele on võimalik rakendada mitut
moodi - OUde, õigusgruppide või WMI filtrite järgi.
Lisaks on administraatoritele Group Policy Analyser, mis on Security Compliance Toolkiti osa.
Haldusvahend on mõeldud GPOde omavaheliseks võrdlemiseks ja tööjaamade seadistuste
auditeerimiseks rühmapoliitikate vastu. Täpsemalt saab teemaga tutvuda siin:
https://docs.microsoft.com/et-ee/windows/security/threat-protection/security-compliance-toolkit-10
(vt hardcopy Rühmapoliitika_2.pdf).
Samuti saab organisatsioonis seadistada ja kasutada Security Baseline template’i. Selle abil saab
kasutajate ja seadmete seadistusi sobivate turvaseadete jaoks võrrelda ja seadistust määrata. Täpsemalt
saab lugeda siit: https://docs.microsoft.com/et-ee/windows/security/threat-protection/windows-
security-baselines (vt hardcopy Rühmapoliitika_3.pdf).
PowerShell abil saab pärida kõiki rühmapoliitikaid käsuga:
Get-GPO -All | select DisplayName, ID, Description, CreationTime, ModificationTime, GpoStatus | Export-Csv c:\tmp\ruhmapoliitika.csv -NoTypeInformation -Encoding UTF8
Erinevate PowerShell käskude kohta millega saab hallata rühmapoliitikaid, võib veel lugeda siit
4sysops.com/archives/administering-group-policy-with-powershell/, vt Rühmapoliitika_12.pdf
6.2 Igapäevases praktikas kasulikuks osutunud GPOd Windows 10
tööjaamadele
6.2.1 Lokaalse tööjaama paroolide vahemälu seadistamine
Uue rühmapoliitika loomine: Group Policy Management paremklõps ja New. Edasi tuleb määrata
poliitikale nimi ja teha vajalikud seadistused.
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security
Options ja seadistada järgnevad alapunktid:
Interactive logon: Number of previous logons to cache (in case domain controller is not available)
– lubada ja 1 logon. Ühiskasutuses olevates tööjaamades tasub see kindlasti suuremaks
määrata.
Network access: Do not allow storage of passwords and credentials for network authentication –
lubada.
Lisatud on rühmapoliitika näidis nimega 18_GPO_Logon_cache.
6.2.2 Windows Defender Application Control
Windows Defender Application Controlis on palju kasulikke funktsioone, täpsemalt saab juurutuse ja
rakendamise kohta lugeda siit: https://docs.microsoft.com/en-us/windows/security/threat-
protection/windows-defender-application-control/windows-defender-application-control-deployment-
guide (vt hardcopy Rühmapoliitika_4.pdf).
AppLocker ja Device Guard on Windows Defenderi üks osa.
6.2.2.1 Application Control ja selle seadistamine:
Computer Configuration > Administrative Templates > System > Device Guard > Deploy Windows
Defender Application Control – lubada.
Määrata Application Controli poliitika ja selle fail. Täpsemalt saab lugeda siit:
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-
control/deploy-windows-defender-application-control-policies-using-group-policy (vt hardcopy
Rühmapoliitika_5.pdf).
6.2.2.2 AppLocker seadistamine
Applockeri kasutamiseks on vaja Enterprise versiooni, Pro puhul peab hakkama saama Software
Restriction Policies abil. AppLockeriga on võimalik määrata, milliseid rakendusi ja faile kasutaja saab
käivitada, sh skriptid, teegid (DLL), paketid ja installifailid. Seadistamine rühmapoliitikas: Computer
Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > AppLocker
Soovitav on reeglid automaatselt genereerida ning vajadusel lisareegleid keelata ja lubada.
Tuleb seadistada nii Windows Install Rules, Script Rules kui Packaged app Rules.
Lisatud on rühmapoliitika näidis nimega 19_GPO_Applocker.
AppLocker GPO sätteid on võimalik muuta ka PowerShell abil käskudega docs.microsoft.com/en-
us/windows/security/threat-protection/windows-defender-application-control/applocker/use-the-
applocker-windows-powershell-cmdlets vt Rühmapoliitika_13.pdf.
6.2.2.3 DeviceGuard
Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization
Based Security, sisse lülitada, lisaks Credential Guard Configuration valida Enabled with UEFI lock.
Põhjalikumalt saab lugeda siit: https://docs.microsoft.com/en-us/Windows/security/identity-
protection/credential-guard/credential-guard (vt hardcopy Rühmapoliitika_6.pdf).
Lisatud on rühmapoliitika näidis nimega 20_GPO_DeviceGuard.
Täpsemaid DeviceGuard sätteid on võimalik teha PowerShell abil: www.petri.com/enabling-windows-
10-device-guard vt Rühmapoliitika_14.pdf.
6.2.3 Tarkvarapiirangud
Software Restriction Policies on GPO funktsionaalsus, mis tuvastab arvutis käivitatud tarkvara ja
kontrollib nende programmide käivitumist. Microsoft ei arenda seda funktsionaalsust küll edasi, aga see
on senini väga laialdaselt kasutusel.
Computer Configuration > Windows Settings > Security Setings > Software Restriction Policies > Action >
New Software Restriction Policies
Designated File Types alla tuleks lisada järgnevad failitüübid: PS1, JSE, VBS, SCT, VBE, WSF (ja muud, kui
vaja).
Edasi valik Security Levels > Disallowed > Set as Default
Lisada lubatud programmide teekond Additional Rules > New Path Rule... > Security level: Unrestricted
Piiranguid/erandeid on võimalik teha ka sertifikaatide ja hashi põhjal ning soovitatav ongi seda just hashi
põhjal teha.
Eranditena tuleks kindlasti märkida järgnevad kohad:
C:\Program Files (x86)
C:\Program Files
%WinDir%\* välja arvatud:
%System32%\catroot2\*
%System32%\spool\drivers\color\*
%System32%\Tasks\*
%WinDir%\debug\WIA\*
%WinDir%\Tasks\*
%WinDir%\Temp\*
Lisatud on rühmapoliitika näidis nimega 21_GPO_Application Whitelisting.
6.2.4 Veebisirvija seadistamine rühmapoliitikaga.
Internet Explorer 11 ja Edge vaikesirvijaks seadistamine: Computer Configuration > Administrative
Templates > Windows Components > File Explorer > Set a default associations configuration file ja sisse
lülitada (sama moodi saab seadistada Chrome’i ja Firefoxi).
Kõik Internet Exploreri seadistused rühmapoliitikas asuvad: Administrative Templates > Windows
Components > Internet Explorer > Internet Control
Soovitav on sisse lülitada järgmised seadistused:
Compatibility View > Turn on Internet Explorer Mode for local Internet - lubada
Internet Control Panel > Advanced Page > Turn on Enhanced Prodected Mode - lubada
Internet Control Panel > Security Page > Internet Zone > Turn on Prodected Mode - lubada
Internet Control Panel > Security Page > Intranet Zone > Download signed ActiveX Controls -
lubada
Internet Control Panel > Security Page > Intranet Zone > Download unsigned ActiveX Controls -
lubada
Internet Control Panel > Security Page > Intranet Zone > Run signed ActiveX Controls and Plugins
- lubada
Internet Control Panel > Security Page > Intranet Zone > Turn on Protected Mode - lubada
Internet Control Panel > Security Page > Locked-Down Internet Zone > Turn on Protected Mode -
lubada
Internet Control Panel > Security Page > Locked-Down Intranet Zone > Turn on Protected Mode -
lubada
Internet Control Panel > Security Page > Locked-Down Restricted Sites Zone > Turn on Protected
Mode - lubada
Internet Control Panel > Security Page > Restricted Sites Zone > Turn on Protected Mode - lubada
Internet Control Panel > Security Page > Trusted Sites Zone > Download signed ActiveX Controls -
lubada
Internet Control Panel > Security Page > Trusted Sites Zone > Download unsigned ActiveX
Controls - lubada
Internet Control Panel > Security Page > Trusted Sites Zone > Run signed ActiveX Controls and
Plugins - lubada
Täpsemat teavet saab siit: https://docs.microsoft.com/en-us/Internet-explorer/ie11-deploy-guide/new-
group-policy-settings-for-ie11 (vt hardcopy Rühmapoliitika_7.pdf).
Lisatud on rühmapoliitika näidis nimega 22_GPO_Veebrisirvija.
6.2.4.1 Chrome’i seadistamine rühmapoliitikaga
Computer Configuration > Administrative Templates > Add/Remove Templates > Add > lisada
chrome.admx (https://support.google.com/chrome/a/answer/187202?hl=en vt hardcopy
Rühmapoliitika_8.pdf).
Allalaetud failid tuleb kopperida kausta C:\Windows\PolicyDefinitions.
Täpsem Chrome’i võimalike poliitikate kirjeldus on siin:
https://www.chromium.org/administrators/policy-list-3 (vt hardcopy Rühmapoliitika_9.pdf) ja
põhjalikuma juhendiga saab tutvuda siin: http://woshub.com/how-to-configure-google-chrome-via-
group-policies/ (vt hardcopy Rühmapoliitika_10.pdf).
Lisatud on rühmapoliitika näidis nimega 23_GPO_Chrome.
6.2.4.2 Firefoxi seadistamine rühmapoliitikaga
Computer Configuration > Administrative Templates > Add/Remove Templates > Add > lisada
firefox.admx (https://github.com/mozilla/policy-templates/releases)
Allalaetud failid tuleb kopeerida kausta C:\Windows\PolicyDefinitions.
Põhjalikumalt saab Firefoxi poliitikate kohta lugeda siit: https://github.com/mozilla/policy-
templates/blob/master/README.md (vt hardcopy Rühmapoliitika_11.pdf).
6.2.5 Tarkvara paigaldamine rühmapoliitika abil
Rühmapoliitika abil saab paigaldada vaid MSI tüüpi pakette ning nendele ei ole võimalik kaasa anda
argumente või lisaväärtusi nii, nagu seda saab teha näiteks käsureal WSUS Package Publisher või SCCM
puhul.
Rühmapoliitika kaudu tarkvara paigaldamiseks tuleb teha jagatud kaust, millele kasutajatel või arvutitel
on lugemisõigused ning paigaldatav MSI pakett tuleb sellesse kausta kopeerida.
Rühmapoliitika loomisel tuleb minna asukohta: Computer Configuration (või User Configuration) >
Polices > Software Settings > Software installation, tühjas aknas teha paremklõps ja valida New >
Package… olenevalt sellest, kas rakendus paigaldatakse kasutajale või arvutile. Seejärel tuleb liikuda
eelnevalt tehtud jagatud kausta ja valida sinna kopeeritud MSI pakett.
Järgnevalt küsitakse tüüpi, valikuteks on „Assigned“, „Published“ või „Advanded“ (Published paketti ei
saa kasutaja puus teha).
Assigned – Tarkvara paigaldatakse arvutisse või kasutajale peale arvuti käivitumist või kasutaja
sisse logimist.
Published – Tarkvara lisatakse arvutis programmide lisamise või eemaldamise nimekirja ning
kasutaja saab selle ise paigaldada.
Advanced – Lubab teha lisavalikuid tarkvara eemaldamiseks, tarkvara programmide
eemaldamise nimekirjast peitmiseks, ning mõningaid teisi sätteid:
Kui valikud on tehtud ja salvestatud, ilmub tarkvarapakett nimekirja ja seejärel tuleb rühmapoliitika
rakendada kasutajale, arvutile, rühmale või muule objektide kogumile. Rühmapoliitika kaudu tarkvara
paigaldamisel rohkem lisavalikuid ei ole. Kui on vaja täpsemaid valikuid või suuremat kontrolli nende üle,
tuleks kasutusele võtta WSUS Package Publisher, System Center Configuration Manager või mõni
kolmanda osapoole lahendus.
6.2.6 Muud turvalisusega seotud rühmapoliitikad
Järgnevad rühmapoliitikad, mille seadistamine piirab informatsiooni lekkimist asutusest väljapoole.
Nende seadistamine ei ole vajalik, kuid nad võivad teatud olukordades ja asukohtades kasulikud olla.
Computer Configuration/Administrative Templates/Windows Components/Camera
Allow Use of Camera: Disabled
Keelab kasutada arvuti veebikaamerat.
Computer Configuration/Administrative Templates/Windows Components/Data Collection and
Preview Builds
Disable pre-release features or settings: Disabled
Keelab Windowsi ja selle komponentide prooviversioonide paigaldamise. Võiks olla
tavakasutajatele keelatud ja testrühmale lubatud. Võib kaasa tuua paikamata turvanõrkusi.
Toggle user control over Insider builds: Disabled
Keelab kasutajal eelmise sätte muutmise.
Computer Configuration/Administrative Templates/Windows Components/Locations and Sensors
Turn off location: Enabled
- Keelab asukoha määramise ja seeläbi asukoha informatsiooni potentsiaalse edastamise
Microsofti või kolmandate osapoolte serveritele.
Turn off sensors: Enabled – keelab ka sõrmejäljelugejad
- Sarnaselt eelmisele keelab sõrmejäljelugejad, valgusandurid, güroskoobid ja teised
ümbruskonda tuvastavad seadmed.
Computer Configuration/Administrative Templates/Windows Components/Cloud Content/
Turn off Microsoft consumer experiences: Enabled
- Keelab reklaamrakenduste paigaldamise ning nende esile tõstmise start menüüs (Candy Crush,
Photoshop, Minecraft jms)
Computer Configuration/Administrative Templates/Windows Components/Windows Error Reporting
Do not send additional data: Enabled
- Keelab rakenduse veateatega koos täiendava kasutajainfo edastamise (failid, kaustateed,
kasutajaandmed).
Disable Windows Error Reporting: Enabled
- Keelab Windowsi rakenduste vigade korral tõrkeraportite koostamise.
Computer Configuration/Administrative Templates/Windows Components/OneDrive
Prevent the usage of OneDrive for file storage: Enabled
- Seadistada juhul kui ettevõte ei kasuta OneDrive’i. Selle sättega saab selle täielikult keelata.
Save documents to OneDrive by default: Disabled
- Lubab keelata File > Save menüüst failide salvestamisel vaikimisi asukohaks OneDrive
pakkumise.
Computer Configuration/Administrative Templates/Control Panel/Regional and Language
Options/Handwriting personalization
Turn off automatic learning: Enabled
- Selle sätte määramisel ei kasutata enam kirjakeele õppimise mehhanisme ega saadeta kogutud
informatsiooni Microsofti serveritele. See tähendab ka seda, et käsikirja tuvastamine ei muutu
ajapikku paremaks.
Computer Configuration/Administrative Templates/System/User Profiles
User management of sharing user name, account Picture, and domain information with apps:
Enabled, Always off
- Keelab kasutajal anda rakendustele luba kasutajakonto kohta informatsiooni kasutamiseks.
Turn off the advertising ID: Enabled
- Keelab reklaamipakkujatel koguda informatsiooni kasutaja eelistuste ja näidatud ning avatud
reklaamide kohta ehk kasutaja profileerimise.
Computer Configuration/Administrative Templates/System/Internet Communication
Management/Internet Communication settings
Turn off access to the Store: Enabled
- Keelab ligipääsu Microsofti rakenduse poele.
Turn off handwriting personalization data sharing: Enabled
- Keelab kirjakeele õppimise mehhanismide kogutud informatsiooni jagamise Microsofti
partneritele.
Turn off handwriting recognition error reporting: Enabled
- Keelab kirjakeele tuvastusvigade raporteerimise.
Turn off Internet download for Web publishing and online ordering wizards: Enabled
- Keelab internetist printimise ja tellimise viisardite alla laadimise.
Turn off Internet File Association service: Enabled
- Keelab internetist failitüübi järgi selle avamiseks rakenduse otsimise.
Turn off printing over HTTP: Enabled
- Keelab printimise üle ebaturvalise HTTP.
Turn off the "Order Prints" picture task: Enabled
- Keelab fotorakendustest piltide tellimise (Eestis kasutu, sest Eestisse saatvaid pakkujaid ei ole).
Turn off the "Publish to Web" task for files and folders: Enabled
- Keelab failide ja kaustade internetti jagamise.
Turn off Windows Customer Experience Improvement Program: Enabled
- Keelab kasutaja tegevuste jälgimise ning selle informatsiooni edastamise Microsoftile
rakenduste täiendamiseks.
Turn off Windows Network Connectivity Status Indicator active tests: Enabled
- Keelab internetiühenduse tuvastamiseks arvutil teatud serveritega ühendust võtta.
Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options
Accounts: Block Microsoft accounts: Users can’t add Microsoft accounts
- Seadistada juhul kui ettevõte ei kasuta Microsofti pilveteenuseid. Keelab arvutis konto
sidumise Microsofti kontoga.
7 Intsidendi halduse protsess
Intsidendiks loetakse IT-teenuse planeerimata katkemist või kvaliteedi langust. Intsidendi halduse
protsess vastutab intsidentide kogu elutsükli haldamise eest ning intsidendihalduse esmane eesmärk on
taastada IT-teenus kasutajatele nii kiiresti kui võimalik.
Turvaintsident on sündmus või sündmused, millega kaasneb andmete või muude infovarade
käideldavuse, tervikluse või konfidentsiaalsuse kadu või tekib oluline oht andmete käideldavuse,
tervikluse või konfidentsiaalsuse kao tekkeks (https://www.riigiteataja.ee/akt/119032012004 vt
hardcopy Intsidendi_haldus_1.pdf ).
Intsidentide võimalikult kiireks kõrvaldamiseks on vaja intsidendid avastada ja välja selgitada nende
tekkimise põhjused. Juhendis keskendume põhiliselt turvaintsidentidele ja kohtvõrgu seadistustele, mis
võimaldavad peale intsidendi esinemist tuvastada intsidendi juurpõhjuse.
Juhendis on kirjeldatud, kuidas turvaintsidente pahavara tuvastamise ning logimise seadistamise kaudu
avastada. Pahavara saab tuvastada nii Windowsi operatsioonisüsteemi omavahendite kui ka kolmandate
tootjate viirusetõrje/pahavara programmidega. Logimine on võimalik seadistada Windowsi
omavahenditega ning logide paremaks haldamiseks on need mõistlik eraldi kesksesse logiserverisse
koguda.
Intsidentide võimalikult kiireks ja automaatseks tuvastamiseks ning süsteemi pidevaks jälgimiseks on ka
erinevaid tasulisi tarkvaralahendusi. Need jälgivad automaatselt võrguliiklust, koguvad kokku kõikide
arvutite logid, analüüsivad olukorda ning teavitavad võimalikest ohtudest. IT-meeskonna ülesandeks on
teavitusi jälgida ning vastavalt vajadusele ohu kõrvaldamiseks kiiresti reageerida. Mõned näited
sobivatest lahendustest on IBM QRadar (https://www.ibm.com/us-en/marketplace/ibm-qradar-siem)
ning F-Secure RDR (https://www.F-Secure.com/en/web/business_global/rapid-detection-and-response).
Kuna nende lahenduste kasutamisega kaasneb rahaline kulu ning need eeldavad suuremat IT-
meeskonda, on nende kasutuselevõtmine mõistlik kõrge turvalisuse nõudega keskkonnas.
7.1 Pahavara tuvastus
7.1.1 Sissejuhatus (milleks seda on vaja, millised on võimalused, ELAM)
Tänapäeval on kõigil kasutusel kas ettevõtte antud või isiklik tööarvuti (tihti mobiilne ehk sülearvuti) ja
nutiseade. Need on kasutusel läbisegi ja seetõttu ohustavad pahavarad meid nii tööl kui ka kodus. Kuigi
peamine turvalisuse kaitse seisneb kasutaja enda Internetikäitumises, on endiselt vajalik Endpoint
protection kaitse ja intsidendi (pahavara) tuvastus.
Pahavara on tarkvara, mille eesmärk on ühel või teisel moel kasutaja seadmele kahju teha. Tihti on see
arvuti ressursi kasutamine kasutaja teadmata ründaja huvides, kas siis krüptoraha kaevamiseks või
ülemaailmsete rünnete läbiviimiseks. Mõni aeg tagasi oli väga populaarne kasutaja failide krüpteerimine
ja lunaraha nõudmine, mis ettevõtete puhul oli suurem, ohtlikum ja kulukam, kui see levis ka
võrguketastel.
Alates Windows 8 versioonist on Windowsis kasutusel ELAM (Early launch antimalware), mis tuli koos
Secure Bootiga ja kaitseb Windowsi boot seadistusi ja komponente ning laeb ELAM-draiverid. Täpsemalt
saab selle kohta lugeda: https://docs.microsoft.com/en-us/Windows/desktop/w8cookbook/secured-
boot (vt hardcopy Intsidendi_haldus_2.pdf).
Kõikidel turvatarkvaradel, ka Windows Defender Security Centeril on vajalik, et süsteemis oleks kõikide
osapoolte turbevärskendused paigaldatud, seetõttu on vaja kasutada tarkvara paikamist ka kolmandate
osapoolte tarkvaras.
Windowsil on tööriist Windows Malicious Software Removal Tool, mis aitab ründevara tuvastada ja
eemaldada. Selle kohta saab täpsemalt lugeda siit: https://support.microsoft.com/en-
us/help/890830/remove-specific-prevalent-malware-with-Windows-malicious-software-remo (vt
hardcopy Intsidendi_haldus_3.pdf).
7.1.2 Windowsi omavahendid
Windows 10’l on sisseehitatud Windows Defender Security Center, mis sisaldab palju kasulikke
vahendeid tööjaama turvalisuse tõstmiseks, ja millele on võimalik GPOga lisada helpdeski kontaktid.
Selleks peab kasutusel olema Windows 10 Enterprise versioon 1709 (või hilisem). Serveris saab teha
rühmapoliitika halduse Computer configuration > Administrative templates > Windows components >
Windows Security > Enterprise Customization, lubada see ning seadistada ka järgmised seaded:
Configure customized contact information, Configure customized notifications. Lisaks tuleb seadistada
vajalikud andmed: Specify contact company name, Specify contact e-mail address, Specify contact phone
number, Specify contact website.
WDSC hõlmab ja võimaldab seadistada järgnevaid kaitstavaid alasid ning on soovitav sisse lülitada:
Virus & threat protection – soovitav on sisse lülitada reaalajas skaneerimine ning lisaks ka
täiustatud anti-ransomware lisad ja seadistada kontrollitud kaustade ligipääsud. Täpsemalt saab
siit lugeda: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-
defender-exploit-guard/controlled-folders-exploit-guard (vt hardcopy Intsidendi_haldus_4.pdf).
Device performance & health – jälgib ja tuvastab arvuti jõudlusega seotud probleeme, kaasa
arvatud kettruumi otsasaamist.
Firewall & network protection – tuleks seadistada tööjaama tulemüür, seda on kirjeldatud
eespool.
App and browser control – kaitseb andmeid ja seadet kahtlaste koodijuppide eest, mis on
peidetud veebilehtedesse, rakendustesse ja failidesse. See funktsionaalsus tasub igal juhul sees
hoida. Siin all on ka Windows Defender Exploit Guard, mis lubab seadistada ja vähendada oma
töötajate rakenduste rünnakute võimalust (võimalik GPO-põhine lisamine). Sisaldab järgnevaid
lisasid:
Exploit protection – tegemist on funktsionaalsusega, mis kaitseb ja rakendub
operatsioonisüsteemi automaatsete protsesside ja rakenduse ärakasutamise kaitseks.
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-
exploit-guard/exploit-protection-exploit-guard (vt hardcopy Intsidendi_haldus_5.pdf)
Attack surface reduction rules (vajalik Windows Enteprise või Educational litsents) –
funktsionaalsus aitab tuvastada ja ennetada käitumuslikul pahavaral arvuti nakatamist
pahatahtliku koodiga. Võimalik seadistada GPOga ja Powershellist:
Set-MpPreference -AttackSurfaceReductionRules_Ids <rule ID> -
AttackSurfaceReductionRules_Actions Enabled.
Täpsemat infot saab siit: https://docs.microsoft.com/en-us/Windows/security/threat-
protection/Windows-defender-exploit-guard/enable-attack-surface-reduction (vt hardcopy
Intsidendi_haldus_6.pdf) ja logi on võimalik vaadata Event viewerist.
Network protection – aitab ennetada ja vähendada internetist pärit sündmuste rünnakuid
arvutile. Võimalik seadistada GPOga või Powershelliga:
Set-MpPreference -EnableNetworkProtection Enabled
Logi on võimalik vaadata Event viewerist.
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-
exploit-guard/network-protection-exploit-guard (vt hardcopy Intsidendi_haldus_7.pdf)
Controlled folder Access – aitab väärtuslike andmetega kaustu pahatahtlike rakenduste ja
ohtude (näiteks lunavara rünnakute) eest kaitsta. Seadistamiseks on vaja valida Virus & threat
protection settings > Controlled folder Access. https://docs.microsoft.com/en-
us/windows/security/threat-protection/windows-defender-exploit-guard/controlled-folders-
exploit-guard (vt hardcopy Intsidendi_haldus_8.pdf)
Kui on vaja lisada kaitstud kaustu, siis tuleb valida Protected folders ja Add a protected folder.
Kui kaitstud kaustadesse on vaja programme lisada, siis tuleb valida Allow an app through Controlled
folder Access ja Add an allowed app.
Family options – ettevõtte tasemel ei ole seda vaja seadistada.
Windows Defenderi võimaluste kohta saab põhjalikumalt lugeda siit: https://docs.microsoft.com/en-
us/windows/security/threat-protection/windows-defender-atp/windows-defender-advanced-threat-
protection (vt hardcopy Intsidendi_haldus_9.pdf)
7.1.3 Kolmanda osapoole vahendid
Pahavaratuvastust ja -kaitset pakuvad mitmed kolmanda osapoole tarkvara loojad. Tuntumad neist on F-
Secure, Eset jt.
F-Secure pahavara tuvastuse ja kaitse valikust on võimalik valida pilvepõhise ja lokaalsel serveril asuva
lahenduse vahel https://www.F-Secure.com/en/business/products. Nn maapealne lahendus on Business
Suite, see pakett sisaldab järgnevaid lisasid:
Keskne haldus – lihtne haldamine, tulemüürireeglite keskne seadistus ja haldus.
Turvapaikamine – peale Microsofti ka kolmandate osapoolte tarkvara uuendamine.
Täiendatud veebikaitse –kahtlaste ja nakatunud saitide ning sisu kontroll ja blokeerimine ning
ohtlike skriptide tuvastus, et kaitsta ärikriitilist veebitegevust.
Vajadusel Proxy kasutamine.
Seadmete kontroll – võimaldab piirata, lubada ja keelata füüsilisi seadmeid nt. USB-pulgad.
Mitmetasemeline Anti-Malware kaitse – ei ole kasutusel ainult ühet tüüpi mootor (nt.
signatuuripõhine, deepguard).
AD sünkroniseerimine ja kasutajate õiguste määramine.
Botneti kaitse.
Dataguard – lisatud krüptovara kaitse.
Programmide ja aplikatsioonide kontroll – võimaldab piirata programmide käivitamist,
installimist jms.
Pilvepõhine lahendus Protection Service for Business (PSB) ja lisad on samade omadustega, mis
maapealsed. Halduses on paar täiendavat võimalust:
Mobiilide haldus ja VPN
Rapid Detection and Reponse – võimaldab PSBle lisada mooduli, kus tehisintellekt analüüsib
reaalajas võrguliiklust ja annab intsidendi korral sellest teada.
Eset võimaldab samuti nii pilvepõhiseid kui ka maapealseid keskhaldusega lahendusi.
https://www.eset.com/us/business/small-business/. Mõlemad sisaldavad järgmiseid omadusi:
HIPS – käitumuslik tuvastus
pNAP – võrgu tasemel töötav kaitse
Tootesisene sandboxing – loob isoleeritud virtuaalse keskkonna
Tulemüür
Lunavara kaitse – jälgib programme käitumispõhiselt
Täiustatud mäluskänner – jälgib mälus jooksvaid protsesse
Botneti kaitse.
7.2 Logimine
Logimine on tähtis, sest see võimaldab intsidendi toimumist tuvastada ja selle juurpõhjust leida.
ISKE B 5.22 järgi mõistetakse IT-süsteemide käitamisel logimise all andmete käsitsi või automaatset
salvestamist sellisel kujul, mis aitab leida vastuseid järgmistele küsimustele: mida keegi põhjustas (st
kasutas), millal ta seda tegi ning milliseid vahendeid ta rakendas.
Nagu eespool mainitud, saab logimist teha ainult lokaalselt või koguda logisid ka eraldi kesksesse
logiserverisse. Keskne logiserver võimaldab logisid paremini analüüsida ja logide tervikluse ja
tõestusväärtuse paremini tagada. Kahjuks nõuab keskne logiserver palju ressurssi ega ole väiksemate
asutuste puhul mõistlik.
Juhendis tutvustame, kuidas logimisi Windows kohtvõrgus seadistada – kuidas täpsemalt Windowsi
serveri teenuseid ja ka tulemüüre või switche logida. Viitame ka erinevatele kesksetele logihalduse
võimalustele ja kirjeldame, kuidas neid seadistada, et logide terviklus tagada.
Logimiseks tasub läbi mõelda, milliseid logisid organisatsioonil on vaja (ISKE M 4.431).
7.2.1 Windowsi teenuste logimine
Teenused, mida Windowsi serverite puhul tasub logida, on AD, NPS, DNS, DHCP ning failiserveri puhul
failide poole pöördumised.
AD logimine annab ülevaate, kas kontodes on tehtud muudatusi, kas kasutajakontode sisselogimisel on
esinenud anomaaliaid (nagu kahtlane kellaaeg või kahtlane arvuti) või on need mingil põhjusel
ebaõnnestunud.
NPS logimine aitab jälgida, milliseid erinevaid ühendusi (VPN, 802.1x) on loodud ja milliseid ühendusi on
proovitud seda serverit kasutades luua.
DNS ja DHCP serveri logid aitavad võõra seadme võrgus olemise kahtluse puhul tuvastada, millal, mis
nime ja IP aadressiga seade võrgus oli.
Failide poole pöördumise logimine aitab tuvastada, kas keegi on proovinud ligi pääseda failidele, millele
tal õigused puuduvad, kui midagi on kustutatud, siis milline kasutaja need kustutas ja teatud juhtudel
(näiteks BYOD puhul või tähtsate kataloogide puhul) jälgida kõiki muudatusi, mis failidega tehakse.
Samuti tasub Windowsi serveri puhul logida kui serveri või teenuste töös esineb tõrkeid või
ülekoormust, kui süsteemipoliitikas on toimunud muutusi, milliseid muudatusi on logide endaga tehtud
jms. See tagab serveri tervikluse ja annab ülevaate serveri kohta.
Microsoft soovitab jälgida sündmuseid, mis on kirjeldatud dokumendis: https://docs.microsoft.com/en-
us/Windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor (vt hardcopy
Intsidendi_haldus_10.pdf).
7.2.1.1 Windowsi server, AD ja NPS logimine
Windowsi serveri logimiseks tuleb GPO kaudu auditeerimised sisse lülitada. Saame lähtuda Microsofti
Best Practices soovitustest: https://docs.microsoft.com/en-us/Windows-server/identity/ad-
ds/plan/security-best-practices/audit-policy-recommendations (vt hardcopy Intsidendi_haldus_11.pdf).
Selleks tuleb GPO luua selle OU külge, kus asuvad serverid (lisatud on rühmapoliitika näidis nimega
24_Logimine_Serveri Logimine) ja linkida ka selle OU külge, kus asuvad tööjaamad (lisatud on
rühmapoliitika näidis nimega 25_Logimine_Arvuti logimine). Domeenikontrollerite logimiseks tuleb GPO
linkida ka Domain Controllers OU külge (lisatud on rühmapoliitika näidis nimega 26_Logimine_DC
Logimine).
1. Computer Configuration – Policies - Windows Settings – Security Settings – Local Policies –
Security Options ja määrata Enabled omadus Audit: Force audit policy subcategory setting
(Windows Vista or later) to override audit policy category settings.
See omadus on vajalik, et auditeerimise alamkategooriatesse tehtavad muudatused
rakenduksid.
2. Computer Configuration – Policies - Windows Settings – Security Settings - Advanced Audit
Policy Configuration – Audit Policies ning muuta järgevad sätted Microsofti soovituste järgi:
a. Account Logon alt
i. Audit Credential Validation – määrata, et logitaks nii Success kui ka Failure
sündmuseid.
ii. Audit Kerberos Authentication Service – määrata, et logitaks nii Success kui ka
Failure sündmuseid.
iii. Audit Kerberos Service Ticket Operations – määrata, et logitaks nii Success kui ka
Failure sündmuseid.
iv. Audit Other Account Logon Events – määrata, et logitaks nii Success kui ka
Failure sündmuseid.
b. Account Management alt
i. Audit Computer Account Management – määrata, et logitaks nii Success kui ka
Failure sündmuseid.
ii. Audit Other Account Management Events – määrata, et logitaks nii Success kui
ka Failure sündmuseid.
iii. Audit Security Group Management – määrata, et logitaks nii Success kui ka
Failure sündmuseid.
iv. Audit User Account Management – määrata, et logitaks nii Success kui ka Failure
sündmuseid.
c. Detailed Tracking alt
i. Audit DPAPI Acitvity – määrata, et logitaks nii Success kui ka Failure sündmuseid.
ii. Audit Process Creation – määrata, et logitaks nii Success kui ka Failure
sündmuseid.
d. Logon/Logoff alt
i. Audit Account Lockout – määrata, et logitaks Success sündmuseid.
ii. Audit Logoff – määrata, et logitaks Success sündmuseid.
iii. Audit Logon – määrata, et logitaks nii Success kui ka Failure sündmuseid.
iv. Audit Network Policy Server – määrata, et logitaks nii Success kui ka Failure
sündmuseid (ainult serverite GPO puhul).
v. Audit Other Logon/Logoff Events – määrata, et logitaks nii Success kui ka Failure
sündmuseid (ainult serverite GPO puhul).
vi. Audit Special Logon – määrata, et logitaks nii Success kui ka Failure sündmuseid.
e. Policy Change alt
i. Audit Policy Change – määrata, et logitaks nii Success kui ka Failure sündmuseid.
ii. Audit Authentication Policy Change – määrata, et logitaks nii Success kui ka
Failure sündmuseid.
iii. Audit MPSSVC Rule-Level Policy Change – määrata, et logitaks Success
sündmuseid.
f. System alt
i. Audit IPSec Driver – määrata, et logitaks nii Success kui ka Failure sündmuseid.
ii. Audit Other System Events – määrata, et logitaks nii Success kui ka Failure
sündmuseid (ainult serverite GPO puhul).
iii. Audit Security State Change – määrata, et logitaks nii Success kui ka Failure
sündmuseid.
iv. Audit Security System Extension – määrata, et logitaks nii Success kui ka Failure
sündmuseid.
v. Audit System Integrity – määrata, et logitaks nii Success kui ka Failure
sündmuseid.
g. DS Access alt (vajalik ainult domeeni kontrolleri puhul)
i. Audit Directory Service Access – määrata, et logitaks nii Success kui ka Failure
sündmuseid.
ii. Audit Directory Service Changes – määrata, et logitaks nii Success kui ka Failure
sündmuseid.
Kui peale GPO rakendamist Local Security Policy’t vaadata, pole seal näha, et need oleks rakendunud.
Nende sätete rakendumist saab kontrollida käsuga
auditpol.exe /get /category:*.
Kõigi nende sündmuste logid kogutakse Event Viewer – Security logisse.
NPS logimine lülitati sisse punktis d.iv. ja neid on võimalik eraldi näha Custom Views - Server Roles –
Network and Policy Server.
7.2.1.2 DNS serveri logimine
DNS audit logi on vaikimisi sisse lülitatud. Logimise detailsust saab häälestada DNS Server konsoolis.
Paremklõps serveri nimel – Properties – Event Logging. All Events on vaikimisi sees.
DNS logisid on võimalik näha Applications and Services Logs – DNS-Server või Custom Views – Server
Roles – DNS Server (serveri teenuse logid, teenuse restart, tegevused jne) ja Applications and Services
Logs – Microsoft – Windows – DNS-Server- Audit (DNS kirjete loomise ja kustutamise logi).
Alates Windows 2012 R2st on võimalus sisse lülitada DNS analüütiline logi. See on asjakohane, kui on
vaja analüüsida kindlat päringuprobleemi, muul juhul ei ole mõistlik seda sees hoida. Logi nähtavale
toomiseks tuleb minna Event Vieweris – Applications and Services Logs – DNS-Server, paremklõps View –
Show Analytic and Debug Logs. Analüütilist logi on võimalik näha Applications and Services Logs –
Microsoft – Windows – DNS-Server-Analytic.
Isegi kui see on nähtavale toodud, on see vaikimisi välja lülitatud. Sisselülitamiseks teha paremklõps
Analytic peal ja Enable Log. Kui teha lihtsalt Enable log, siis kohe pole logi sisu näha, vaid see tuleb
nähtavale peale seda, kui teha Disable Log. Teine võimalus on teha paremklõps Properties peal ja valida
Do not owerwrite events (Cleat logs manually) ja seejärel Enable log. Sellisel juhul on logid kohe näha.
DNS serveri logimist on võimalik seadistada ka PowerShell käsuga docs.microsoft.com/en-
us/powershell/module/dnsserver/set-dnsserverdiagnostics?view=win10-ps vt Intsidendi_haldus_19.pdf.
7.2.1.3 DHCP serveri logimine
DHCP logisid on võimalik näha Event Vieweris Custom Views - Server Roles – DHCP Server (serveri
teenuse logid, teenuse restart, tegevused jne) ja Application and Services – Microsoft – DHCP-Server
(erinevad auditi logid, DHCP teenuse muudatuse logid).
Täpsem DHCP audit logi (DHCP päringud jms) on vaikimisi sisse lülitatud ja asub kaustas
C:\Windows\System32\dhcp\.
Kui see on mingil põhjusel välja lülitatud või on vaja sätteid muuta, saab seda teha mitmel viisil:
1. Käivitada Powershell käsk:
Set-DhcpServerAuditLog -Enable $True.
Kui soovitakse muuta logifaili asukohta ja suurust, saab seda teha sama käsu parameetritega:
Set-DhcpServerAuditLog -Enable $True -Path C:\Logs\DHCP -MaxMBFileSize 100
Sätete rakendumiseks on vajalik DHCP server teenuse restart.
Täpsem informatsioon antud käsu kohta: https://docs.microsoft.com/en-
us/Powershell/module/dhcpserver/set-dhcpserverauditlog?view=win10-ps (vt hardcopy
Intsidendi_haldus_12.pdf).
2. Haldusliidesest:
Käivitada Server Manager – Tools – DHCP, valida kas IPv4 või IPV6 (vastavalt vajadusele)
paremklõps Properties ja General vahelehel – Enable DHCP audit logging. Logi asukohta saab
muuta Advanced vahelehelt Audit Log file path.
7.2.1.4 Failiserveri logimine
Failiserver on asutuse üks kriitilisemaid teenuseid, sest seal asuvad tihtipeale igapäevased tööks
vajalikud failid ning need võivad sisaldada ka tundlikke andmeid. Saamaks paremat ülevaadet, milliseid
toimetusi failidega tehakse või failidega esineva intsidendi puhul selle põhjuse leidmiseks tuleks sisse
lülitada jagatud kaustade logimine.
Tavaliste jagatud kaustade puhul tasuks auditeerida kõigi kasutajate ebaõnnestunud tegevusi ning kõiki
õnnestunud kustutamisi, õiguste muutmist ning kaustade või failide omastamist.
Kui asutuses on kasutuses ka BYOD sülearvutid, siis nende seadmete omanike puhul tasub logida kõik
tegevused, sest on tähtis, et nad ei kopeeriks faile oma arvutisse.
Samuti võib olla mõni tundlikum kataloog, mille puhul on tähtis, et kõik tegevused oleksid logitud.
Failiserveri kataloogide logimise sisse lülitamiseks on vaja teha kaks tegevust:
1. Lülitada GPOga sisse Object Access auditeerimine. Selleks teha GPO selle OU külge, kus
failiserver asub. Lisatud on rühmapoliitika näidis nimega 27_Logimine_Failiserveri logimine. Kui
see pole juba muu GPOga määratud, siis lülitada sisse Computer Configuration – Policies –
Windows Settings – Security Settings – Local Policies – Security Options alt policy Audit: Force
audit policy subcategory settings (Windows Vista or later) to override audit policy category
settings.
Peale seda minna Computer Configuration – Policies – Windows Settings – Security Settings –
Advanced audit policy configuration – Audit Policies. Punkti Object Access alt:
a. Audit File System - määrata, et logitaks nii Success kui ka Failure sündmuseid.
b. Audit Handle Manipulation - määrata, et logitaks nii Success kui ka Failure sündmuseid.
c. Audit File Share - määrata, et logitaks nii Success kui ka Failure sündmuseid.
2. Kaustal, mida soovitakse logida, tuleb auditeerimine sisse lülitada. Selleks tuleb minna soovitud
kausta peale ja teha paremklõps Properties. Avanenud aknas valida Security vaheleht ja sealt
Advanced. Edasi valida vaheleht Auditing ja Add. Principal puhul valida Everyone, valida Type
Success ja jätta Applies to samaks, mis pakutakse. Seejärel valida Show advanced premissions,
eemaldada kõik teised linnuksed ning valida omadused Delete subfolders and files, Delete, Read
premisssions, Change premissions ja Take ownership.
Peale Seda valida uuesti Add, määrata Principal Everyone, Type Fail ning valida Full Control.
Kui teatud gruppide või kaustade puhul on vaja erinevalt logida, tuleb ka need reeglid
samamoodi luua. Näiteks, et logida BYOD kasutajate grupi kõiki tegevusi, tuleb valida
Principaliks vastav grupp, Type Success ning õigusteks Full Control (Type Faili ei ole vaja eraldi
teha, sest see on juba vaikimisi kõikidel kaustadel rakendatud).
Kui on vaja, et näiteks raamatupidamise kausta kõik tegevused oleks logitud, tuleb minna selle
kausta Auditing vahelehele ning sealt lisada reegel, kus Principal on Everyone ja premissions on
Full Control.
Failiserveri auditeerimine suurendab märgatavalt logide arvu. Security log suurust on soovitatav
suurendada vähemalt 500 MB peale ja arhiveerida logi siis, kui see on täis, või seadistada mingi
rotatsioon. Kui on vaja leida informatsiooni failide poole pöördumise kohta tasub peamiselt jälgida Event
ID 4663.
7.2.2 Süvalogimine
Süvalogimine on logimine, mis logib täpsemalt süsteemis toimuvaid tegevusi (protsesside loomine,
failide ning võrguühenduste muudatused), mis võimaldavad paremini tuvastada, kas serveris toimub
anomaaliaid või pahatahtlikke tegevusi.
Süvalogimine aitab turvaintsidendi korral intsidendi alget tuvastada, kui seda ei ole võimalik tuvastada
tavavahenditega. Näiteks kui on kahtlus, et serveris toimuvad mingid tegevused, mida ei tohiks olla, aga
pole olnud võimalik neid tuvastada või näiteks kui kasutaja arvuti nakatub pidevalt uuesti sama viirusega
ning pole suudetud leida selle juurpõhjust.
Süvalogimist ei ole vaja pidevalt sees hoida kui tegu ei ole just kõrge turvalisusega keskkonnaga, mille
kõik tegevused peavad olema väga detailselt pidevalt logitud.
Käepäraseks süvalogimise lahenduseks on Sysmon, mis võimaldab logida protsesside, draiverite jt.
detailsemaid muudatusi. Sysmoni koos tutvustuse ja paigaldusjuhendiga leiab aadressilt
https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon.
Sysmoni paigaldamisel võib kasutada vaikekonfiguratsiooni (installimisel käsuga sysmon -accepteula –i),
rakenduse detailsemaks häälestamiseks saab aluseks võtta konfiguratsioonifailide näidised
https://Github .com/SwiftOnSecurity/sysmon-config (vt hardcopy Intsidendi_haldus_13.pdf), mida võib
vastavalt oma vajadustele täiendada.
Sysmoni loodud logisid saab lugeda Event Vieweris – Applications and Services Logs – Windows – Sysmon
– Microsoft-Windows-Sysmon/Operational.
7.2.3 Võrguseadmete logimine
Võrguseadmete logid annavad palju informatsiooni selle kohta, mis võrgus toimub ning seda saab siduda
ka teiste logidega, et luua hea ülevaade ning paremini intsidente tuvastada. Kui võrguseadmed seda
toetavad, tasub kõigis võrguseadmetes (tulemüürid, switchid, WiFi seadmed) logimine sisse lülitada.
Kuna iga võrguseadme seadistus on individuaalne, tasub täpsemat logimise seadistuse infot uurida
vastava võrguseadme dokumentatsioonist. Samuti on dokumentatsioonis kirjas logide kesksesse
haldussüsteemi saatmise seadistused. Tuleb kindlasti jälgida, milliseid logisid sinna saadetakse, kuna
tulemüürid genereerivad palju logisid ning kõige saatmisel kesksesse logiserverisse tekib probleem.
Võrguseadmete ja muude seadmete logide omavahel sidumisel on tähtis, et kõigi seadmete kellaaeg
oleks ühtne. Windows domeenivõrgus soovitame selleks seadistada kõigi seadmete NTP serveriks
domeenikontrolleri serveri.
Kindlasti tasub logida ja keskselt säilitada võrguseadmete konfiguratsioonimuudatusi, kasutajakontode
muudatusi ning nende sisse- ja väljalogimisi (nii edukaid kui ka ebaõnnestunuid) (vt ka ISKE M 4.47).
Kui tulemüür seda toetab, tasub kindlasti sisse lülitada sissetungituvastuse ja -vältimise süsteemid ning
nende logimised, mis aitavad kaasa intsidentide tuvastusele ja ennetusele.
7.2.4 Logide keskhaldus
Logide keskne talletamine annab süsteemis toimuvast parema ülevaate, lihtsustab mistahes
analüüsimeetodi kasutamist ning lubab rakendada tõhusaid meetmeid logide tervikluse tagamiseks.
Logide keskseks halduseks on saadaval väga mitmeid erinevaid lahendusi, millel kõigil on oma head ja
halvad omadused.
Nii tasuliste kui ka vabavaraliste lahenduste funktsionaalsus on tavaliselt sama, aga vabavaraliste
lahenduste korral tuleb vajalikud päringud, mis kogutud logidest informatsiooni otsivad ja seda mugaval
kujul esitavad, ise luua. Tasuliste lahenduste puhul on taoline analüütiline pool tavaliselt juba loodud,
olemas on suur hulk erinevaid päringuid ja neid saab ka ise lisada. Tavaliselt eeldavad vabavaralised
lahendused administraatorilt rohkem seadistamist, tasulised on pigem out-of-box lahendused.
Erinevate lahenduste näited:
ELK stack https://www.elastic.co/elk-stack;
Splunk https://www.splunk.com/;
Azure Monitor https://docs.microsoft.com/et-ee/azure/azure-monitor;
Graylog https://www.graylog.org/ jt.
Juhendis kasutame logide keskseks talletamiseks vabavaralist ELK stack (Elasticsearch, Logstash, Kibana)
lahendust, mis võimaldab toimuvast paremat ülevaadet andva töölaua seadistamist ning logide
arhiveerimist. ELK stacki saab paigaldada nii Linuxi kui Windowsi serverile, juhendis keskendume
Windowsi versioonile ning serverina on kasutusel Windows Server 2016.
7.2.4.1 Logitasemed
Iga logiteade sisaldab tavaliselt informatsiooni teavituse taseme kohta, mis annab infot teate
kriitilisusest. Windowsi seadmetes on tavaliselt neli logitaset: informatiivne (rakenduse teavitus millegi
toimimise kohta), hoiatav (teavitus sündmuse kohta, millest võib potentsiaalselt viga tekkida), viga või
kriitiline (rakenduse töös tekkis tõsine viga). Ka teistel seadmetel ja tarkvaradel on tavaliselt erinevad
logitasemed, mille kohta saab informatsiooni nende dokumentatsioonist. Enne keskse logide kogumise
seadistamist tasub planeerida, millist informatsiooni oleks mõistlik kesksesse logiserverisse koguda. Kui
sinna koguda kõik tasemed, kasvab kasutatav kettamaht eksponentsiaalselt ning samuti on sellist mahtu
keeruline analüüsida.
7.2.4.2 ELK Stacki seadistamise juhend
ELK Stack on kolme vabavaralise toote kogum – Elasticsearch, Logstash ja Kibana. Elasticsearch on
otsingu- ning analüüsi andmebaas/mootor. Logstash on logide kogumise tööriist, mis võtab logisid vastu
mitmest sisendist, suudab neid teisendada ja andmeid edasi erinevatesse väljunditesse saata. Kibana on
Elasticsearch pistikprogramm, mis võimaldab Elasticsearchis olevaid andmeid visualiseerida. Koos
töötades kogub ja analüüsib Logstash logisid, Elasticsearch indekseerib ja hoiustab informatsiooni ning
Kibana pakub võimaluse kogutud andmete põhjal visuaalseid graafikuid luua.
ELK Stack vajab küll palju seadistamist ja sellel pole kõiki omadusi, mis tasulistel variantidel, kuid see
pakub siiski piisavalt võimalusi. ELK Stack on üsna ressursinõudlik, vaja on vähemalt 4 CPUd ja 8 GB mälu
(16 - 32 GB muudab töö mõistagi kiiremaks).
ELK Stacki Windowsi serverile installeerimiseks on mitmeid juhendeid:
1. https://medium.com/@samil.mehdiyev/elk-stack-on-Windows-server-part-2-installation-
d2a7200b65a6 (vt hardcopy Intsidendi_haldus_14.pdf)
2. https://logz.io/blog/installing-the-elk-stack-on-Windows/ (vt hardcopy
Intsidendi_haldus_15.pdf)
7.2.4.2.1 Logstashi seadistamine
Logstashi seadistamisel tuleb erinevate logide kogumiseks teha erinevad sisendid. Sisendeid
seadistatakse logstash.json failis (vaikimisi C:\ELK\logstash\bin\logstash.json).
Fail koosneb kolmest osast:
1. Input – erinevate logide puhul tuleb vastavalt tüübile teha erinevad sisendid.
2. Filter – erinevate sisendite ja sisendi tüübi järgi saab väärtustega teha muudatusi.
3. Output – üldjuhul on väljundiks Elasticsearch, mis talletab, arhiveerib ja indekseerib kõik logid.
Selleks, et Logstashi ja serverite vaheline suhtlus toimuks üle turvalise kanali, tuleb luua sertifikaat ja
privaatvõti ning need Logstashi konfiguratsioonifailis seadistada.
Sertifikaadi päringu loomiseks Windowsi serveris tuleb sinna installeerida OpenSSL:
https://blog.didierstevens.com/2015/03/30/howto-make-your-own-cert-with-openssl-on-Windows/ (vt
hardcopy Intsidendi_haldus_16.pdf).
Sertifikaadi saab pärida Windowsi CAd kasutades. Võib kasutada ka ise loodud sertifikaati või sertifikaadi
mujalt osta, aga kui Windows CA on võrgus olemas, siis on see kõige mõistlikum, sest kõik domeeniga
seotud masinad usaldavad seda sertifikaati.
Privaatvõtme, sertifikaadipäringu ja sertifikaadi loomiseks tuleb teha järgenvad sammud:
1. Peale programmi installi tuleb avada käsuviip ja minna OpenSSL kausta (näiteks cd C:\Program Files\OpenSSL-Win64\bin) ja seal käivitada käsk ELK kausta privaatvõtme loomiseks (näiteks C:\ELK). openssl genrsa 2048 -out C:\ELK\private\logstash.key
2. Luua sertifikaadipäring
openssl req -new -sha256 -key C:\ELK\private\logstash.key -out C:\ELK\certs\logstash.csr
Common name panna oma logstash serveri nimi (logserver.test.local).
3. Pärida sertifikaat. Selleks tuleb minna oma CA CertSRV veebilehele, valida sealt Request a
Certificate, advanced certificate request, Submit a certificate request by using a base-64-encoded
CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
Järgmiseks võtta loodud request faili sisu ning sinna kopeerida. Certificate Template võib olla
Web Server ning seejärel vajutada Submit. Sertifikaadifail tuleb alla laadida kui Base 64 encoded.
Fail tuleb ümber nimetada kui logstash.cer ja liigutada näiteks C:\ELK\certs kausta.
4. Laadida alla ka CA sertifikaat ja liigutada see C:\ELK\certs kausta.
5. Seadistada logstash.json failis iga inputi kohta, et kasutataks SSLi ja määrata sertifikaadi ja
privaatvõtme asukoht:
ssl_enable => true
ssl_verify => false
ssl_certificate_authorities => "C:\ELK\certs\root.cer"
ssl_cert => "C:\ELK\certs\logstash.cer"
ssl_key => "C:\ELK\private\logstash.key"
Näidisena on lisatud konfiguratsioonifail, kus on seadistatud Event Vieweri logide vastuvõtmine.
Erinevad filtrid ja nende tööpõhimõte on kirjeldatud juhendites:
https://www.elastic.co/guide/en/logstash/current/filter-plugins.html (vt hardcopy
Intsidendi_haldus_17.pdf).
Logisid arhiveeritakse Logstash outputi abil. Võimalik on määrata arhiivi asukoht ning sorteerida logid
aastate ja neid saatnud seadmete järgi kaustadesse. Soovi korral on võimalik arhiveeritavad logid kokku
pakkida. See konfiguratsioon on järgmine:
output {
file {
path => "E:\logarchive\%{+YYYY}\%{hostname}\log%{+YYYY-MM-dd}.gz"
codec => "rubydebug"
gzip => true
}
}
Logisid salvestatakse logiserverisse jaotusega iga hosti logi kuupäevade kaupa, salvestamise käigus dubleeritakse Logstash logid nii, et üks koopia andmetest jääb Elasticsearchi ja teine faili kujul arhiivi.
7.2.4.2.2 NXlogi seadistamine
Selleks, et logid jõuaksid serveritest ja mujalt kesksesse kohta, on vaja programmi, mis neid sinna
saadaks. Variante on mitmeid, praeguses dokumendis kasutame NXLOG programmi.
Windows serverisse tuleb paigaldada NXLOG ja teha soovitud sündmuste kogumiseks vajalikud
häälestused konfiguratsioonifailis.
NXLOG saab alla laadida lehelt https://nxlog.co/products/nxlog-community-edition/download.
NXLOG konfiguratsioon asub kaustas C:\Program Files (x86)\nxlog\conf.
Konfiguratsioonifailis tuleb näidata, milliseid sündmusi ja millisel tasemel soovitakse koguda.
Kuna kõikide teenuste logide formaat on erinev, tuleb need eraldi edasi saata ja logiserveris vastu võtta,
et oleks võimalik neid erinevalt parsida. Selleks on NXLOG konfiguratsioonis tehtud EventLog kohta
eraldi sisendid.
EventLog sisendis saab määrata erinevaid logimise tasemeid.
Samuti tuleb NXlog certs kausta kopeerida domeeni CA sertifikaat ja määrata see konfiguratsioonis kui
CAFile C:\Program Files (x86)\nxlog\cert\root.cer.
7.2.4.3 Logide terviklus
Selleks, et logisid intsidendi juurpõhjuse leidmiseks kasutada, on vaja tagada logide terviklus ja
tõestusväärtus (logisid ei ole muudetud).
Ligipääs arhiveeritud logifailidele tuleb piirata ning nende failide poole pöördumised täiendavalt logida.
Kuna ELK Stack hoiab failide koopiaid (üks koopia Elasticsearchis ja teine arhiivis), tekib võimalus neid
omavahel võrrelda ning seeläbi logide terviklus tagada.
7.2.4.3.1 Arhiveeritud logide turvamine
Arhiveeritud logide ligipääsu piiramiseks saab teha järgmist:
Piirata arhiivikataloogide puhul õigused selliselt, et failidele oleks ligipääs ainult kasutajal SYSTEM ning
ainult selleks ettenähtud kasutajal, näiteks: domeen/arhiveerija. Kataloogi omanikuks tuleb määrata
sama kasutaja.
1. Kasutaja parool on kättesaadav ainult paroolide peakasutajale, mitte tavaadministraatoritele.
2. Selle kasutaja sisse logimist logiserverisse tuleb piirata – tal ei tohi olla ligipääsu üle võrgu (faili
share’de) ja RDP-ga.
3. Kui arhiveerimiseks määratud kasutaja õigustes on vaja süsteemile ligi saada, saab domeeni
administraator seda ajutiselt lubada. Selle muutmisele on vaja peale panna ka auditeerimine:
3.1. Lülitada sisse Local Security Policys Audit Authentication Policy Change ja jälgida järgmisi
evente:
3.1.1. EventID 4718 – kui kasutaja eemaldatakse Deny access to this computer from the Network
või Deny log on through Remote Desktop Services alt.
3.1.2. EventID 4717 – kui kasutaja lisatakse Deny access to this computer from the Network või
Deny log on through Remote Desktop Services alla.
3.2. Local Security Policyga tuleb administraatoritel keelata endale omaniku rolli võtmine. Sellega
võetakse administraatoritelt võimalus arhiveeritud kataloogis õiguste muutmiseks. Muudatuste
jälgimiseks tuleb sisse lülitada Authorization Policy Change. Jälgida tuleb evente:
3.2.1. EventID 4705 – Kasutajalt võeti ära õigus Take ownership of files or other objects.
3.2.2. EventID 4704 – Kasutajale anti õigus Take ownership of files or other objects.
Lisaks on logide tervikluse tagamiseks teisi variante:
1. Logide aheldamine
2. Ajatembeldamine
3. Räsi loomine ja igapäevane kontroll
7.2.4.3.2 Logide aheldamine
Üks võimalus logide kaitsmiseks on need omavahel krüptoaheldada. Krüptoahel kujutab endast seda, et
iga logikirje sisaldab logikirjet ja eelmise logikirje põhjal loodud räsi. Kui muuta mingit logikirjet, saab
selle kohe avastada, sest ahel läheb katki.
Selle loomiseks on mitmeid lahendusi, RIA pakub tasuta tarkvara Pythoni baasil. See lahendus töötab nii
Windowsi kui Linuxi peal. Selle saab alla laadida siit: https://www.ria.ee/sites/default/files/content-
editors/publikatsioonid/slog.zip
Windowsis tuleb selleks paigaldada ka Python 2.6 (RIA leheküljel olev slog nõuab kindlalt seda Pythoni
versiooni) ja Python for Windows Extension. Need saab alla laadida siit:
https://www.python.org/ftp/python/2.6/python-2.6.amd64.msi
ja siit:
https://Github .com/mhammond/pywin32/releases/download/b221/pywin32-221.win-amd64-
py2.6.exe
Peale Pywin installi anda kindlasti ka käsk:
python C:\Python26\Scripts\pywin32_postinstall.py –install
Samuti lisada C:\Python26 PATH muutuja juurde.
Rakenduse Windowsi installiks tuleb slog zip pakett kõigepealt luua Linuxi serveris (selleks võib kasutada
ka Windows Subsystem for Linux lahendust https://docs.microsoft.com/en-us/windows/wsl/install-
win10 ) alla laetud securelog kausta:
.create_zip.sh
Loodud zip fail tuleb alla laadida ja serveris näiteks kausta c:\slog lahti pakkida.
Programmi installeerimiseks minna käsuviiba kaudu sinna kausta ja anda käsk:
slogdsvc.py install
Konfiguratsioonifailis (slogd.conf) tuleb määrata, millist logifaili peab jälgima ning kuhu kirjutatakse räsi.
Logiräsi kontrollimiseks anda käsud:
slogverify.py -l logi_ahela_failinimi
Tulemus on stiilis:
=== Analyzing file E:\Logchain\log.txt.0.20190413_162434 ===
First record in this file has sequence number of 0
Last record in this file has sequence number of 3844
Kui faili on muudetud, siis:
=== Analyzing file E:\Logchain\log.txt.0.20190413_162434 ===
First record in this file has sequence number of 0
Error on line 2347: Invalid linking info, log line probably tampered
Last record in this file has sequence number of 2347
ELK Stack puhul on seda võimalik kasutada vaikimisi slog võimalustega ainult siis, kui salvestada logi
arhiiv ühte logifaili, mis pole kokku pakitud. Logifailide rotatsioon tuleks teha käsitsi või automatiserida
teiste vahenditega kui Logstash ise.
7.2.4.3.3 Ajatembeldamine
Ajatembeldamine on logi tõestusväärtuse tagamise võimalus. Ajatempel näitab, et sellel ajahetkel on
taoline logi eksisteerinud. Selleks on vaja logifailile lisada usaldusväärse ajatempliteenuse osutaja antud
ajatempel. Ajatempel näitab, et sellel ajahetkel on taoline, sellise sisuga logi olemas olnud. Ajatempel
koosneb logi pealt loodud räsist ja ajatempli teenusepakkuja poolt sellega seotud ajast.
Riigiasutustel on võimalik ajatempli jaoks kasutada GuardTime lahendust, Eestis pakub ajatempli teenust
ka SK: https://www.sk.ee/teenused/ajatempliteenus (vt hardcopy Intsidendi_haldus_18.pdf).
7.2.4.3.4 Räsi loomine ja kontroll
Salvestatud logide muutmiskatse õigeaegse avastamise tagamiseks tuleb luua task, mis loob
igapäevaselt kõikide failide kohta räsi ning kontrollib, et failid pole muutunud. Informatsioon muutumise
kohta saadetakse peakasutaja e-postile.
Lahenduseks saab kasutada näiteks Microsofti tööriista Microsoft File Checksum Integrity Verifier:
https://www.microsoft.com/en-us/download/details.aspx?id=11533
Failide hash salvestatakse eraldi XML andmebaasi, mis asub C:\Windows kaustas: fciv.exe -add E:\logarchive -r -XML C:\Windows\loghashes.xml
Muudatuste kontrollimiseks tuleb käivitada käsk:
fciv -v -XML C:\Windows\loghashes.xml
Skript failide kontrolliks:
REM Lisame tänase kirje xml andmebaasi
C:\skripts\fciv.exe E:\logarchive -r -XML C:\Windows\loghashes.xml
REM kontrollime kas eelmise korraga võrreldes on midagi muutnud:
C:\skripts\fciv -v -XML C:\Windows\loghashes.xml > C:\Windows\loghashes.log
Powershell C:\skripts\e-mail.ps1
e-mail.ps1 skript:
$E-mailFrom = "[email protected]"
$E-mailTo = "[email protected]"
$Subject = "Hash verification tulemus"
$Body = "Lisatud on verification log"
$Attachment = "C:\Windows\loghashes.log"
$SMTPServer = "Ettevõtte meiliserver"
Send-MailMessage -from $E-mailFrom -to $E-mailTo -subject $Subject -body $Body -Attachment $Attachment -SMTPServer $SMTPServer
8 Segamudeli soovitused
8.1 Erinevate OS masinate halduspoliitika
RIA on seisukohal, et Windows 10 on turvalisem kui varasemad Windowsi versioonid ja selle kasutamine
on asutuse võrgus soovituslik. Paratamatult on olukordi, kus pole võimalik kõiki tööjaamu koheselt
Windows 10 peale uuendada.
Sellises olukorras tuleb luua vastav poliitika, millised vanemad Windows OS versioonid on lubatud ja
millised piirangud neil masinatel on. Peab arvestama, et lubatud ei tohiks olla vanemad Windowsi
versioonid, mida Microsoft enam ei toeta. Samuti tuleb seda poliitikat pidevalt uuendada kui mõni
versioon aegub. Hetkel oleks lubatud operatsioonisüsteemid Windows 7 (kuni 14.01.2020) ja Windows
8.1 (kuni 10.01.2023).
Samuti tuleb vanematel Windows OS seadmetel ebaturvalised funktsioonid välja lülitada ja vaadata, et
ka vanemad seadmed saaksid vajalikud uuendused. Tuleb arvestada, et paljud turvalisuse lisad nagu
näiteks Device Guard töötavad ainult Windows 10 peal.
Soovitused, mida teha:
1. Seadista WSUS või SCCM, et need kaasaks ka vanema OSi uuendusi.
2. Lülitada kõigil seadmetel välja SMB1.
3. Windows 7 arvutitel lülitada välja Desktop Gadgets.
4. Lülitada välja AutoRun
5. Otsustada, kas vanemaid seadmeid lubada failiserverile ligi. Lülitada serveris sisse SMB Security
Enhancments:
https://docs.microsoft.com/en-us/Windows-server/storage/file-server/smb-security (vt
hardcopy Segamudel_1.pdf)
Võimalusel uuendada tööjaamad Windows 10 peale.
8.1.1 Aegunud ebaturvaliste funktsioonide välja lülitamine GPOga
Keelata Windows Sidebar ja Gadgets: Computer Configuration > Policies > Administrative Templates >
Windows Components > Desktop Gadgets, sisse lülitada järgnevad seadistused:
Restrict unpacking and installation of gadgets that are not digitally signed – lubada.
Turn off desktop gadgets – lubada.
Turn Off user-installed desktop gadgets – lubada.
Lisatud on rühmapoliitika näidis nimega 28_segamudel_Keela Win Gadgets ja Sidebar.
Keelata autoplay ja autorun: Computer Configuration > Policies > Administrative Templates > Windows
Components > AutoPlay Policies ja seadistada järgnevad parameetrid:
Default behavior for AutoRun – lubada ja valida Do not execute any autorun commands.
Turn off Autoplay – lubada ja valida All Drives.
Turn off Autoplay for non-volume devices – lubada.
Lisatud on rühmapoliitika näidis nimega 29_segamudel_Keela autoplay.
Keelata SMBv1: (täpsem Microsoft juhend: https://support.microsoft.com/en-us/help/2696547/detect-
enable-disable-smbv1-smbv2-smbv3-in-windows-and-windows-server vt hardcopy Segamudel_2.pdf).
Computer Configuration > Preferences > Windows Settings > Registry > New > Registry Item
Järgmiste parameetritega: MRxSMB10
Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\services\mrxsmb10
Value name: Start
Value type: REG_DWORD
Value data: 4
LanmanWorkstation
Action: Replace
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\LanmanWorkstation
Value name: DependOnService
Value type REG_MULTI_SZ
Value data: Bowser, MRxSmb20, NSI
Lisatud on rühmapoliitika näidis nimega 30_segamudel_SMBv1
8.1.2 Serverite GPOd, mis nõuavad kõrgemat turvalisust
SMBv1 keelamine serveril: Computer Configuration > Preferences > Windows Settings > Registry > New >
Registry Item
Järgnevate parmeetritega: LanmanServer
Action: Create
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value name: SMB1
Value type: REG_DWORD
Value data: 0
Lisatud on rühmapoliitika näidis nimega 31_segamudel_SMBv1_server.
8.2 Automaatne paikamine
Juhul, kui ettevõttes on kasutusel vanemaid Windows operatsioonisüsteeme (näiteks Windows 7, 8 või
8.1), tuleks nendele vajalikud tarkvarauuendused WSUSis ja SCCMis Products valikute all lubada
samamoodi nagu seda tehakse Windows 10 puhul. Soovitav on nende lubamiseks teha eraldi reeglid ja
grupid ning Auto Approve või Deployment reeglid, et neid oleks lihtne eemaldada, kui nende eluiga läbi
saab.
9 Võrgu ja võrguseadmete füüsiline turvalisus
ISKE annab turvaliste serveriruumide ja nõrkvoolupaigaldiste rajamiseks piisavalt detailsed juhised.
Asutuse IT-meeskond peab tagama, et algselt kavandatud turvataset nende tegevuse või
tegevusetusega ei kahjustataks.
1. Serveriruum peab olema lukustatav ja varustatud signalisatsiooniga (ISKE B2.4) – andmeturbe
eest vastutaja roll on tagada, et uks ka tegelikult lukus püsib ja kõrvalistel isikutel serveriruumi
võtmele ligipääsu ei ole (ISKE M2.17).
2. Serveriruumi külastuste üle tuleb arvestust pidada.
3. Ka kõik ülejäänud seadmekapid ja võrgusõlmed peavad olema volitamata ligipääsu eest kaitstud
– kappide uksed peavad olema lukus ja nende asukoht videovalve vaateväljas. Erilist tähelepanu
tuleb pöörata hoonete üldkasutatavates ruumides (koridorid, trepikojad jms) paiknevate
nõrkvoolurajatiste kaitsele.
4. Serveriruumist väljapoole paigutatud (dubleerivad) varundusseadmed peavad asuma lukustatud
ruumis või seadmekapis.
5. Serveriruum võib olla algselt kavandatud tuleohutusnõuetele vastavalt ning organisatsiooniliste
meetmetega tuleb tagada, et olukord sellisena ka püsiks – see ei ole koht pakkematerjali,
koristusvahendite jms hoidmiseks.
6. Serveriruumis paiknevaid seadmeid toitvate UPSide võimsus on sageli kavandatud üksnes nende
soetamise hetkel kaitset vajanud seadmete vajaduste katmiseks. Serverite ja võrguseadmete
lisandudes tuleb kontrollida, kas UPSid ka tegelikult lisanduva koormusega toime tulevad.
Seadmete lisamisel ja ümberpaigutamisel on kindlasti vaja kontrollida, kas uus toiteskeem
vastab kavandatule – piiratud ligipääsuga seadmekappides on eksimise võimalus suur (toite
jaotuspaneelide ja serverite toitejuhtmete ebakorrektse märgistuse korral võivad UPSi taha
saada seadmed, mis seal ei peaks olema ja vastupidi; harvad ei ole ka UPSide soovimatud
jadaühendused).
7. IT-ruumis veetorude vältimise nõue (ISKE M1.24) on üldjuhul täidetud, praktikas ilmneb
probleeme lokaalsete jahutusseadmete kondensvee ärajuhtimiseks mõeldud torustiku
korrashoiuga. Äravoolutorustik peab olema kavandatud selliselt, et võimaliku lekke korral ei
jõuaks vesi seadmekappide ega toiteseadmeteni.
8. ISKE M5.61 ja M5.62 kirjeldavad andmesidevõrkude segmenteerimise võimalusi. Väikeses
asutuses on tööjaamad ja serverid reeglina samas võrgusegmendis ning eraldi segmenti
kasutatakse üksnes külalistele mõeldud WiFi ühenduse isoleerimiseks. Sama põhimõtet tuleb
kasutada ka avalikus tsoonis (koosolekuruumid, koridorid jms) paiknevate arvutivõrgu pesade
ühendamisel – külalisel ei tohi olla võimalust oma sülearvuti ühendamiseks asutuse sisevõrku.
ISKE M2.333 kirjeldab nõupidamisruumide turvalist kasutamist detailsemalt.
9. ISKE B2.12 soovitab aktiveerida ainult need ühendused ja pistikupesad, mida tõepoolest
vajatakse. Kõik muudatused kaabelduses tuleb jooksvalt dokumenteerida (ISKE M5.143).
10. ISKE M1.32 kirjeldab meetmeid, mida on vaja rakendada prinditud materjalide kaitseks
volitamata lugemise või kopeerimise eest. Väikesel asutusel ei ole nende meetmete täismahus
rakendamine otstarbekas, samas tuleb ühiskasutatavate printerite asukoha valikul
turvanõuetega siiski arvestada.
10 Tööjaamade varunduslahendused
Et tagada andmete käideldavus, on tähtis tööjaamade varundus. Tööjaamade puhul võib esineda
kõvakettarikkeid, kasutaja poolt failide kogemata kustutamist, krüptoviiruste rünnakut jms, mille
tulemusena kasutaja arvutis olevad failid pole enam kasutatavad.
Seetõttu on väga tähtis, et ka tööjaamade varundus on üldisesse andmevarunduse kontseptsiooni
loomisesse kaasatud (ISKE M 6.33).
Kuna suure tõenäosusega pole piisavalt vaba ruumi, et tööjaamu täielikult varundatuna hoida, tuleb
varunduspoliitikas määratleda, milliseid katalooge arvutist varundatakse ning kasutajaid teavitada, et
nad oma vajalikke faile neis kataloogides hoiaksid ning hoiatada, et teistest asukohtadest pole faile
võimalik taastada.
Tavaliselt on nendeks kataloogideks kas kasutaja Desktop ja My Documents või kogu kasutajaprofiil. Kui
kasutajaprofiil on täielikult varundatud, tuleks kasutajaid kindlasti teavitada, et nad isiklikke suuremaid
faile (nagu pilte, muusikat ja videosid) profiili kataloogides ei hoiaks.
Varundamiseks on mitmeid võimalusi ja tuleb kaaluda, milline on kõige sobivam lahendus. Oluline on
administreerimise lihtsus, varunduse keskne haldamine ja mahukontroll.
Kui kasutusel on Office 365 OneDrive, on võimalik seadistada, et My Documents ja Desktop oleks
sünkroniseeritud OneDrive’i peale. Juhend selleks:
https://support.office.com/en-us/article/back-up-your-documents-pictures-and-desktop-folders-with-
onedrive-d61a7930-a6fb-4b95-b28a-6552e77c3057 (vt hardcopy Varundus_1.pdf).
Ka Google Drive’i on võimalik andmeid varundada:
https://www.cloudwards.net/how-to-use-google-drive-to-backup-your-data/ (vt hardcopy
Varundus_2.pdf).
Andmeid saab varundada ka vajalikke dokumente pilvesalvestuse (OneDrive, Google Drive jms)
sünkroniseerimise kataloogi lohistades. Faile võib varundada ka näiteks kasutades PowerShell skripti:
https://medium.com/@pablo127/how-do-i-make-quick-automatic-backup-with-using-powershell-
9fa8de3f1784 (vt hardcopy Varundus_6.pdf). Antud skript on küll välise ketta jaoks, aga muutes skriptis
varunduse asukohta (muutuja $pathToPrefix) OneDrive või muu pilvesalvestuse toote kataloogi peale,
saab seda varundust seadistada ka sinna.
Üks võimalus kasutajate andmete varundamiseks on GPO abil vajalikud kataloogid serverisse suunata
ning need serveri varunduse kaudu katta.
Tavaliselt tasub serverisse suunata My Documents ja Desktop kataloogid.
GPO seadistamiseks tuleb luua GPO selle haru külge, kus asuvad kasutajad. GPOs tuleb muuta sätet User
Configuration – Policies – Windows Settings – Folder Redirection. Sealt tuleb valida Desktop, teha
paremklõps ning valida Settings valikus Basic – Redirect everyone’s folder to the same location. Kui valida
Advanced, on võimalik määrata, et vastavalt grupile suunatakse kataloogid erinevasse asukohta (näiteks
kui teatud kasutajate puhul on vajalik pikaajalisem varundus, saab nende kataloogid suunata sellisesse
asukohta, mille varundust hoitakse kauem).
Target Folder location puhul jätta valik Create a folder for each user Under the root path ning määrata
serveris jagatud kataloog (serveri kataloogi õigused tuleb määrata vastavalt juhendile
https://support.microsoft.com/en-us/help/274443/how-to-dynamically-create-security-enhanced-
redirected-folders-by-usin vt hardcopy Varundus_3.pdf), kuhu kasutajate kataloogid suunatakse.
Sama seadistus tuleb teha ka My Documents kataloogi puhul.
Selleks, et need kataloogid oleks kättesaadavad ka väljaspool sisevõrku, tuleb tagada, et Offline Files
oleks sisselülitatud. Seda saab teha näiteks rühmapoliitikaga. Rühmapoliitikas tuleb minna User
Configuration – Policies- Administrative Templates – Network Offline Files. Valida säte Specify
administratively assgined Offline Files. Valida Enabled ning Files alt määrata kasutaja kataloogide
asukoht.
Lisatud on rühmapoliitika näidis 32_Varundus_FolderRedirect.
Selle seadistuse puhul tuleb arvestada, et mõnikord ei tööta Windows Offline Files oodatult ja seetõttu
võib kataloogidele ligipääsuga probleeme esineda. Selle parandamiseks on alternatiivina olemas
Windows Work Folders, mis võimaldab hoida profiili lokaalsena, aga saab seadistada nende serveriga
sünkroniseerimise. Selle seadistamise juhend https://docs.microsoft.com/en-us/windows-
server/storage/work-folders/deploy-work-folders (vt hardcopy Varundus_4.pdf).
Ka mitmed kolmandad osapooled pakuvad tööjaamale varundustarkvara. Sellisel juhul on vaja kas eraldi
NAS seadet või tuleb varundus teha serveri kettale (siis tuleb selle serveri ketas kindlasti serveri
varundusest välistada, muidu hakkab serveri varundus kasutama suurt hulka kettaruumi). Samuti
eeldavad need tööjaama ja serverisse agendi installi.
Erinevad tarkvarad on näiteks:
1. Microsoft DPM - Microsofti backup teenus, mis võimaldab varundada domeeni arvuteid ja seda
keskselt hallata. Eelduseks on seadistatud DPM server. https://docs.microsoft.com/en-
us/system-center/dpm/back-up-workstations?view=sc-dpm-2019
2. Veeam Endpoint Backup – seda saab tasuta kasutada, kuid tasuta verisooni pole võimalik
keskselt hallata. Siiski on seda võimalik kasutada koos Veeam Backup & Replication serveriga,
mis seda võimaldab
https://www.veeam.com/Windows-endpoint-server-backup-free.html.
3. Druva Insync – tasuline tarkvara, mis võimaldab varundust keskselt hallata. See eeldab kas Druva
pilve või oma serveri seadistamist. Arvutitesse tuleb paigaldada agent
https://www.druva.com/solutions/endpoint-backup/.
4. Acronis Backup
https://www.acronis.com/en-us/business/backup/workstation/
Windows 10s on ka File History, mis tasub sisse lülitada. See varundab kasutaja andmed, mis asuvad
Libaries, Desktop, Contacts and Favorites kataloogides. See eeldab teise salvestuslokatsiooni olemasolu -
kas teine ketas arvutis, eemaldatav USB ketas või ka jagatud kaust serveris või NAS peal. Teine variant on
kasutada Backup and Restore (Windows 7) tööriista, mis võimaldab andmeid varundada/taastada nii
nagu seda tehti Windows 7 puhul https://www.thewindowsclub.com/use-windows-7-back-up-and-
restore-tool-windows-10 (vt hardcopy Varundus_5.pdf).
11 Lõppkasutaja turvakoolituse korraldamine
Lõppkasutaja turvakoolituste korraldamine on GDPR rakendamisel eriti aktuaalseks muutunud.
Koolitus- ja teavitusprogrammi loomist ning käigushoidmist kajastab ISKE moodul B1.13. Viidatakse
vajadusele võrdselt koolitamisega tegeleda ka teavitustöö ning töötajate üldise infoturbe alase
teadlikkuse tõstmisega.
Kodus töötamise võimaluse üha laiem kasutuselevõtmine muudab vältimatuks selle, et töötaja peab
suutma teadlikult hallata ka kogu kodust IT-alast tegevust. Ainult tööandja rakendatud
sunnimeetmetega ei õnnestu vältida seda, et arvutit võivad kasutada ka töötaja lapsed vms. Seega peab
lõppkasutajakoolitus hõlmama turvateemasid laiemalt – käitumist sotsiaalmeedias, avalike
pilveteenuste kasutamist, WiFi turvalist kasutamist jms.
Koolituskava võiks hõlmata:
asutuses kehtestatud IT turvareeglite tundmaõppimist, turvanõuete ja riskide selgitamist;
kaasaskantavate seadmete kasutamisega seotud riske ja nende ennetamise meetodeid;
ligipääsuõiguste volitamata kasutamise tagajärgede kajastamist;
spetsiaalseid infoturbealaseid teadmisi, mida töötajad oma erialaste ülesannete täitmiseks
vajavad (ISKE M2.557);
turvaintsidentidele adekvaatse reageerimise õpetamist (esmased tegevused intsidendi
avastamisel, teavitusahel ja edasiste juhiste saamine, turvalisuse valdkonna kontaktisiku
määramine (ISKE M3.46));
potentsiaalsete ohtude ja enamlevinud ründeviiside äratundmist (Phishing, Social Engineering,
meetodid veebilehtede usaldusväärsuse hindamiseks jms), selliste rünnete tagajärgede
hindamist;
sotsiaalmeedia pakutavaid võimalusi ja nendega kaasnevate ohtude analüüsi;
avalike pilveteenuste, sh andmetalletusteenuste (Dropbox jms) kasutusvõimalusi ja sellega
kaasnevaid riske;
hiljutiste avalikuks tulnud turvaintsidentide analüüsi koos põhjuste ja võimalike ennetusviiside
kirjeldamisega.
ISKE soovitab võimalike koolitusmeetoditena:
kontaktkoolitus;
infoturbega seotud teabekogu, blogi vms;
infoturbe alased ajakirjad;
organisatsioonisisesed teabeüritused;
organisatsioonivälised seminarid, messid, konverentsid;
spetsiifilised infoturbe teemasid kajastavad videomaterjalid;
e-õppe programmid;
rollimängud.
Meetodite valikul tuleb lähtuda asutuse üldisest töökultuurist ning konkreetsetest sihtrühmadest.
Kogemused näitavad, et parema ja kestvama koolitustulemuse tagavad reeglina asutusevälised
spetsialistid. Koolitamine vajab pidevat enesetäiendamist ja esinemiskogemust, ent asutuse IT-
spetsialistil on raske ennast koolitajana tasemel hoida.
Koolituskava võiks tagada lõppkasutaja turvateemade kajastamise vähemalt kord aastas. Lisaks
seniõpitu meenutamisele ja kinnistamisele saab nii kasutajani viia teadmised uuematest riskidest ja
ilmsiks tulnud intsidentidest.
Õpitulemuste edukuse kontrollimiseks sobivad koolitusele vahetult järgnevad testid koos hilisema
järelkontrolliga. Siin on väga heaks vahendiks veebipõhised testkeskkonnad.
