Microsoft 365 pakub ettevõtte produktiivsuse tööriistu, mille hulgas on ka head tuttavad kontoritöö rakendused Word, Excel, Outlook jne. Kuid Microsoft 365 pole ainult kontoritarkvara installimine kasutajatele, see on palju enamat. Microsoft 365 oluline osa on ka halduse ja infoturbe tööriistad.

Sõltuvalt ettevõtte suurusest ja vajadustest on olemas erinevad Microsoft 365 paketid – E3 või E5, Microsoft 365 for Business, mis on erineva võimekusega.

Microsoft 365 for Business on pigem väiksematele firmadele sobiv ning jaguneb veel omakorda kolmeks paketiks: Microsoft 365 Business Basic (veebipõhine), Microsoft 365 Business Standard (lisanduvad Office´i töölauarakendused) ja Microsoft 365 Business Premium (lisanduvad seadmehaldus ja täiendavad turvalahendused).

Microsoft 365 E3 ühendab Microsoft 365 parimad kontorirakendused põhiliste turva- ja seadistusvõimalustega. E3 aitab parandada produktiivsust ja koostööd, kaitsta töötajate ja ettevõtte andmeid.

Microsoft 365 E5 sisaldab kõiki Microsoft 365 tööriistu keskmistele ja suurematele ettevõtetele. Sellel on ka täielikud võimalused identiteedihalduseks, infoturbeks nii pilves kui kohapeal, Power BI ärianalüütika ja palju muud.

11 erinevat etappi Microsoft 365 juurutamiseks

Mõistlik on alustada Microsoft 365 juurutamist erinevates osades. Siin on 11 erinevat etappi, mida oleks hea juurutusprojektis järjest rakendada.

Vaatame kõiki neid erinevaid osasid juurutusest kindlasti ka infoturbe ja halduse vaatest, enne kui live´i läheme, et ei tekiks tehnilist võlga. Üks tüüpiline viga, mida tehakse, on keskendumine liiga palju produktiivsuse lahendustele, sest need on kõigi jaoks kõige tuttavamad – põhiliselt juba varasemast teada Office´i rakendused. Kuid see on juurutuses vaid üks osa üheteistkümnest. Kõik muud etapid on ka olulised. Juurutus ei lõpe Exchange Online´i aktiveerimisega.

Natuke nukraks teevad ka väited, et Teamsi juurutamiseks läks tubli kaks pikka töötundi. Seda ma ei usu. Ilmselt selle ajaga paigaldati Teams ja tehti pilves algsed seadistused, kuid see pole veel kogu juurutusprotsess.

Ühtse arusaama tekitamine

Korralik juurutusplaan hakkab minu meelest pihta ühtse arusaama loomisest, täpsete ärivajaduste väljaselgitamisest ja vastustest küsimusele, miks me need teenused juurutada tahame. Need osad tuleb kõigepealt paika panna. Siis selgub juba, mis mahus ning mis funktsionaalsust ettevõte vajab. Kas tahame suuremat produktiivsust, mobiilsust või hoopis paremat turvalisust? Seda tuleks ka töötajatele kommunikeerida, miks neid muudatusi ette võetakse ja mille jaoks Microsoft 365 ettevõttes täpsemalt kasutusele tuleb. Sisemiselt peab olema ühine arusaam nii IT-, infoturbeosakonna kui juhtkonnaga, miks see juurutusprojekt ette võetakse.

Töö käigus on veel tähtis, et ei tekiks sisemisi konflikte. Näiteks kui IT-osakond tahab, aga infoturve on selle vastu selliseid olukordi tuleks vältida.

Riskide analüüs aitab samuti konflikte vähendada. See annab teada, mis tegelikult juhtub, kui liigume oma majasisestest teenustest pilveteenustele. Kas saame niimoodi riske maandada või peame mingeid riske taluma? Need küsimused võiks olla läbi räägitud juba kõige esimeses faasis.

Selged ja mõõdetavad eesmärgid tuleb samuti kohe alguses defineerida ja muidugi ka tegelikud ärivajadused.

Kui pilveteenusele juba üle läheme, Siis ei tee me ju seda mõneks kuuks. Tegemist on otsusega pikema aja peale. Muidugi võib ka pilves nii-öelda peksa saada, kui rumalaid otsuseid tehakse, kuid sealgi on vaja turvameetmed kasutusele võtta.

Identiteedi mudelid

Kui esimene faas läbitud, siis teises faasis keskendume juba identiteedi mudelile. Identiteet on meie uus kontrollipaneel, kus kõik käib kasutajate kaudu: litsentsid, seadmed, õigused, teenustele ligipääs.

Microsoft pakub nelja erinevat mudelit identiteedi osas sõltuvalt ettevõtte suurusest.

Ainult pilve ehk Cloud Only identiteedi puhul on tegemist kõige lihtsama identiteedi lahendusega. Sel juhul toimub kasutajate haldus otse veebipõhise Azure AD portaali kaudu ja ühtegi kasutajat ettevõtte sisesest domeenikontrollist ei sünkroniseerita. „Ainult pilv“ lahendus sobib ideaalselt alustavatele ettevõtetele või ainult mõnda üksikut serverit omavale firmale. Seda lahendust on kasutusele võtnud ka suuremad ettevõtted, kus näiteks kunagi alustati Exchange Online teenuse tarbimist ja teatud põhjustel pole seda tänaseni muudetud. Viimaselt juhul on kasutajatel kaks erinevat kontot ja parooli, mis on kasutajakogemuse seisukohast üsnagi ebamugav.

Sünkroniseeritud identiteedi mudel ehk Synchronized Identity puhul sünkroniseeritakse olemasolevad kasutajad majasisesest domeenikontrollerist otse Azure AD´sse. Selle seadistamiseks tuleb kasutusele võtta üks täiendav server, kuhu paigaldatakse Azure AD Connect teenus. See on sünkroniseerimise tööriist, mis teatud regulaarsusega sünkroniseerib ettevõttesiseses domeenikontrolleris olevad andmed vastavalt seadistustele otse Azure AD´sse.

Federeeritud identiteedi ehk Federated Identity mudeli puhul on tegemist kõige kallima ja keerukama lahendusega. Selle kasutusele võtmiseks on vaja nelja erinevat serverit ja koormusjaotureid. Esimese asjana tuleb seadistada Active Directory Federation Services ehk ADFS teenus ning peale seda saab sisse lülitada federeeritud identiteedi. ADFS keskkond peab olema kindlasti kõrge käideldavusega, sest selle mittetöötamise korral ei ole võimalik ka pilveteenustele ligi pääseda. Federeeritud identiteedi puhul puudub vajadus sünkroniseerida kasutajate parooliräsisid, mis võib olla turvaosakonna nõue pilveteenuste kasutuselevõtul.

Tegelikult tuuakse selle lahendusega kõik sinu enda majja, ise pead vastutama ka selle eest, et taristu töötaks autentimise osas. See oli mingil ajal väga popp, aga ettevõtted on selle juurest praegu ära liikunud, kuna keerukust on rohkem ja tuleb palju teenuseid ise üleval pidada, et seda pakkuda.

Pass-Through sünkroniseerimine (ülaloleval pildil) pole aga nii keeruline, kui federeeritud mudel. Identiteedid sünkroniseeritakse pilvega Azure AD Connecti abiga.

Need on neli erinevat mudelit, mille seast lahendus valida, kui ettevõttel hetkel midagi veel pole. Kindlasti tuleks läbi arutada, millist teed pidi neist neljast lahendust valides minna. Poole projekti pealt oleks juba raske muutma hakata, võiks aga teha kohe alguses teadliku otsuse.

Pilvepõhiste infoturbeteenuste juurutamine

Microsofti infoturbeteenustest oli juttu juba eelmises artiklis. Nüüd ongi aeg need teenused kasutusele võtta ja valida, millised annavad meile alati selge pildi turvaolukorrast, logidest ja toimunud intsidentide tõrjest.

Kui tahate Exchange´i, Teamsi, Onedrive´i või mõnda muud rakendust juurutada, siis peab mõtlema, kus hoida logisid, kõik tuleb põhjalikult läbi arutada ja valida, millised Microsofti infotureteenused kasutusele võtta. Nii-öelda toorelt pole mõtet pilve minna, kui ei tea, kust toimunu kohta pärast infot leiab. Ettevõtetel võib nüüd ühtäkki tekkida olukord, et teenused on jaotatud kahe poole vahel – oma majas ja pilves.

Küberintsidentide käsitlemine

Peaksime peale infoturbeteenuste valikut üle vaatama ka küberintsidentide käisitlemise. Siin tuleb hinnata juba esialgse riskianalüüsi põhjal, mida meil täpselt vaja on, kas oskame ikka logisid vaadata, kus ja kaua neid logisid hoitakse.

Administreerimismudeli defineerimine

Ka sellest olen juba blogis rääkinud. Siin etapis vaatamegi, kuidas pilveteenuste administreerimine peaks käima, millised on ohud, millised lahendused, milliseid turbesätteid peaksime administraatorite kontodele rakendama. Eraldi on juba juttu olnud ka tsonaalsest administreerimismudelist ja pilvepõhisest privilegeeritud ligipääsu haldusest.

Siin on veel vaja üle vaadata täiendavate litsentside ostmise vajadus. E5 puhul tuleb hankida täiendavad turbelahendused, mida tahame rakendada administraatorite kontode kaitseks.

Administraatorite infoturbe koolitamineon ka väga oluline – seal peab näitama, mis muutuma hakkab. Piisab majasisesest koolitusest või võib veel ka vastavalt koolitajalt tunde juurde võtta, kui vaja.

Produktiivsuse rakenduste paigaldamine ja seadistamine

See osa on tavaliselt äripoolele kõige arusaadavam, kuna tegemist on kõigle teada-tuntud rakendustega ja need kasutajatele paigaldataksegi. Selle juures peab analüüsima, mida üldse on ettevõtte töötajatele vaja – Exchange Online´i, Teamsi, Office´ist tuntud rakendusi jne, midagi veel? Käime selles etapis läbi ja vaatame üle teenuste sätted, kas rakendused ikka on seadistatud nii, nagu soovitud? Analüüsime siin samuti nii sise- kui välis-suhtlust. Kindlasti on oluline, mis on teenuste ja rakenduste välimine osa erinevate partneritega, kes palgatud või kes teevad projekte väljastpoolt – kuidas nemad firma andmetele ligi saavad? Kas külaliskutseid saab saata? Kas külalised peavad samuti tegema kahefaktorilist kontrolli?

Seadistusi on palju, aga nende puhul on vaja leida tasakaal turvalisuse ja produktiivsuse vahel.

Pigem tuleks kasutajale kombineerida erinevatest vajadustest enda versioon, defineerida selle juures infoturbe baassätted ning kindlasti mitte kasutada vaikimisi sätteid.

Produktiivuse faasis töötame veel välja tingimuslikud reeglid Azure Active Directory jaoks. Tingimuslike reeglite kohta vaata juba lähemalt Microsofti vastavalt lehelt.

Mis alustel üldse kasutaja teenustele ligi saab? Ettevõttes on vajalik see ära määrata, mitte jätta nii, et igaüks võib minna poodi, ostab suvalise seadme ja saabki niimoodi ettevõtte teenustele ligi. Sellepärast ongi tingimuslik ligipääs vajalik, et määrata, kust ja millega andmetele ligipääsu saab (mõnikord ka see, millal saab). See on produktiivsuse faasis oluline ära teha.

Kasutajate koolitus ja kommunikatsioon

Turundus- ja kommunikatsiooniosakonnaga koos tuleb selles etapis vaadata, kuidas näiteks kasutajatele selgitada mitmefaktorilist kontrolli, miks see vajalik on, kui teenused on saadaval näiteks vaid Eestis, millele keegi saab ligi ja millele mitte. Kasutajatega tuleb sellest rääkida, sest neil on vaja vastuseid küsimustele, miks mobiilis e-posti lugemiseks on vaja see seade ettevõtte haldusse võtta jne. Kommunikatsioonis tuleb ära põhjendada, mida see võib endaga kaasa tuua, kudias andmed võivad isiklikust seadmest lekkida jne.

Viimased kolm faasi: Proof of concept, piloot, Rollout

Juurutusprojekti lõpus hakkame suurendama osalejate arvu, kes Microsoft 365 peale järjest üle lähevad.

Väiksema grupi peal analüüsime enne lahendust veendumaks, et me pole midagi ära unustanud. Kui kõik on okei, suurendame kasutajaskonda nii-öelda pilootkasutajate etapis kõige toimimise testimiseks ning lõpuks laiendame kasutajaskonna üle kogu ettevõtte – need on pilootprojekti ja rollout´i etapid.

Igas faasis on oma tegevused ja väljundid, enne kui liigume edasi järgmisse etappi.

Tehnilised tegevused on siinjuures tegelikult kõige lihtsamad, organisatsiooni kaasatoomine ja mõistmine, mida see kõik endaga kaasa toob, nõuab aga eraldi ja põhjalikumat lähenemist.

Näiteks Teamsi rakendamine pole ainult lõbus chat ehk vestlusaken. Üsna halvasti on see rakendus kasutusel, kui ainult chatiks kasutatakse. Teamsiga saab rakendada erinevat automaatikat, lihtsustada äriprotsesse. Sellesse tuleb kaasata vajalikke inimesi. Litsentsid maksavad, investeering parematesse töövahenditesse peab aga end tagasi tooma suurema produktiivsuse ja töövõimekuse kasvuga.

Microsoft 365ga pilve minnes tegutse teadlikult ja targalt ning kui pilve üle oled läinud, tee edasi tööd juba produktiivsemalt ja paremini uute töövahendite abiga.

Kui Sul Microsoft 365 juurutuse kohta küsimusi, võta Lakeforest Consult`iga julgesti ühendust.