IT-ympäristön kokonaisuus
IT-infrastruktuurin modernisointi alkaa aina lopulta olemassa olevan IT-ympäristön arvioinnista. Tässä kohtaa pitää myös arvioida yrityksen olemassa olevia työnkulkuja ja sitä, miten niitä voitaisiin parantaa.
Ilman tätä arviota IT-modernisointi on lähinnä vain IT-muuttopalvelu, joka siirtää dataa erilaiseen ja uuteen toimistoon.
Uudessa toimistossa voi olla uusi ja hieno kahvikone (Teamsin chatti) sekä hienoja tiimikohtaisia huoneita (Teamsin tiimit), mutta jos näitä ei hyödynnetä tehokkaasti töissä (Teamsin / Sharepointin automaatio sekä sovellukset), niin ei niillä ole tokikaan suurta hyötyarvoa yritykselle.
Tarkoituksena tässä on tuoda ilmi, että jo olemassa olevien työjärjestysten ja toimintatapojen arvio olisi hyvä tehdä vähintään vuositasolla.
Muuten mahdollisesti “väliaikaisesta” toimintamallista tulee juuri niin pysyvä, kuin väliaikaiset ratkaisut tuppaavat olemaan. Eli pysyviä.
Yksinkertainen (ja kauhea) esimerkki tästä on vaikka se, että yrityksen kaikki yhteisesti työssä käytettävät salasanat ovat tallessa siinä kuuluisassa jaetussa Excel -tiedostossa. Tiedosto on verkkolevyllä, ja sitä voivat kaikki muuttaa tai lukea.
Eli kun joku muokkaa tai avaa tiedoston, eivät sitä voi muut avata. Ja kun tiedostoa on muokattu, voi olla, että jollakin on vielä esimerkiksi vanha versio tiedostosta auki ja tarvittu salasana on muuttunut. Tai jos tiedosto poistetaan, niin koko salasanakavalkaadi pitää tehdä uudelleen jokaiseen palveluun.
Puhumattakaan valtavasta tietoturvariskistä.
Tässä merkittävästi parempi toimintamalli on salasanojen ja monivaiheisen autentikaation sovellus, joka on saatavilla sekä verkkoselaimiin, tietokoneelle että mobiililaitteille. Näin monivaiheista tunnistautumista voidaan vaatia lähes joka tilanteessa pakotetusti -> tietoturvan taso nousee astronomisesti vanhaan malliin verrattuna. Näin myös salasanat sekä monivaiheisen tunnistautumisen koodit ovat saatavilla nopeasti ja tarkasti oikealle henkilölle / tiimille määriteltynä. Tämä on merkittävästi nopeampaa, kuin vain pelkän monivaiheisen tunnistautumisen koodin kaivaminen esimerkiksi erillisestä autentikaatiosovelluksesta tai puhelimen tekstiviestistä.
Seuraava esimerkki on valmiiden tiedostojen tarkistus ja kuittaus. Tiedostojen työnkulussa ennen lähetystä vastaava henkilö tarkistaa tiedoston. Mutta vain yksi henkilö voi tehdä tarkistuksen, koska tämä on määritelty yksilöoikeuksilla. Tiedot ovat kuitenkin sellaisia, joita usea vastuuhenkilö voisi hyväksyä. Ja kun tämä henkilö on joko lomalla tai kiireinen, hidastuu tiedostojen tarkistus merkittävästi. Jos vastuuta jaetaan usealle henkilölle / tiimille, nopeutuu prosessi.
Kolmantena esimerkkinä on se yleisin tilanne, eli yksi iso verkkolevy, johon on laitettu kaikki yrityksen data kansiorakenteeseen. Tämä on usein ollut ratkaisu, kun tiedostosäilytys on ollut kallista. Nykyisten halpojen hintojen ja palvelujen johdosta tämä tieto olisi merkittävästi järkevämpää jaotella sopiviin tiimeihin ja vastuuhenkilöihin. Näin tieto ei keskittyisi yhteen isoon klönttiin, vaan jokaisella tiimillä olisi oma vastuudatansa, jota ylläpidetään ja seurataan. Ja kun uutta tietoa tulee esimerkiksi asiakkailta tai sitä luodaan yrityksen sisällä, voidaan se siilottaa helposti oikealle vastuutiimille.
Näissä kaikissa esimerkeissä olemassa olevaa työnkulkua tai toimintatapaa muutetaan merkittävästi.
Eli vaikka modernisoinnissa järjestelmät tuodaa tulevaisuutta kestävälle tasolle, niin ilman yllä mainittua työnkulkujen samanaikaista arviointia ja päivitystä ei muutos ole kovin merkityksellinen.
Juurisyiden arviointi on aina erittäin tärkeää, jotta parannuksia syntyy.
Mutta, siirrytään siihen IT-kokonaisuuteen.
IT-puoli
Miten siis tämä koko modernisointi lopulta nivotaan yhteen ja uudeksi, moderniksi ympäristöksi.
Aluksi koko olemassa oleva IT-ympäristö on hyvä jaotella muutamaan erinäiseen kriittiseen lohkoon:
- IT-laitekanta / pääsylaitekanta (tietokoneet, palvelimet, mobiililaitteet)
- Yritykselle kriittiset työnkulut ja palvelut + ratkaisut
- Yrityksen data, sen hallinta ja pääsyoikeudet
- Toimisto + potentiaalinen data (toimistoverkko, tulostimet)
- Käyttäjätilit
Tämäkin on vain karrikoitu esimerkki, mutta yleisesti nämä kaikki yllä mainitut palvelukokonaisuudet riittävät kattamaan koko yrityksen IT-infrastruktuurin.
Kun näistä kaikki on arvioitu ja suunnitelmat modernisoinnille tehty, voidaan modernisointi infran osalta aloittaa.
Alla on vielä hieman havainnollistava kuva potentiaalisesta hybridimallisesta infrastruktuurista, joka oli vielä muutama vuosi sitten moderni.
Tämänkaltainen Active Directoryyn pohjautuva IT-ympäristö ja IT-infrastruktuuri on tälläkin hetkellä pienillä muutoksilla käytössä lähes kaikissa Microsoftin järjestelmiin pohjautuvissa yrityksissä. Eli n. 90% maailman Fortune 1000 -yrityksistä.
Kuva on toki englanniksi, ja avaan sitä tässä hieman alle. Harmaalla pohjalla oleva data on joko yrityksen toimistoverkossa tai paikallisessa datakeskuksessa sijaitsevaa dataa. Vain Azure / O365 on Microsoftin pilviratkaisussa (kuvassa oikealla alhaalla), ja kaikki muu valkoisella pohjalla oleva kuvaa Internetiä ja sen yli kulkevaa dataa.
Kohta 1. kuvaa mahdollista yrityssovelluksen kirjautumisportaalia. Tässä voi olla joko self-hosted portaali, tai ihan vain kolmannen osapuolen tarjoama kirjautumisportaali kyseessä (esim. Citrix Cloud -tyyppinen malli). Portaali kuitenkin vaatii soveltuvat tunnukset, joko Guest -tai Internal -tyyppistä mallia.
Tässä kohtaa pitää myös mainita julkinen DNS, joka on pakollinen minkä vain domainpohjaisen yrityksen IT-infrastruktuurin ylläpidossa. Se on yleisesti primäärinen ohjauskeino nimi@yritys.com -tyyppisten domanien ohjauksessa.
Kohta 2. kuvaa yrityksen sisäistä toimistoverkkoa. Kyseessä on joko Hosted Private -tyyppinen datakeskuksen verkko (johon on S2S VPN-yhteys toimistolta + VPN Gatewayltä) tai ihan vain tyypillinen toimistoverkko, johon otetaan samaisella Gatewayllä yhteys.
Kohta 3. kuvaa Traditionaalista Active Directory -toteutusta, eli vähintään kahta Domain Controller -palvelinta. Toteutettu joko toimistolla olevalle palvelimelle tai Hosted Private -ympäristöön.
Kohta 4. Kuvaa tässä tapauksessa tietokantapalvelimia, jotka ovat varsin yleisiä vähänkään monimutkaisemman IT-infrastruktuurin kanssa. Samaa tietokantapalvelinta voidaan myös käyttää esimerkiksi SCCM-palvelimeen sekä myös SCOM-palvelimeen, tai oikein toteutettuna ne on eriytetty omille palvelimilleen / palveluihinsa.
Kohta 5. kuvaa sitä varsinaista yrityssovellusta, johon kirjaudutaan kohdan 1. portaalin kautta. Tässä voi olla kyseessä esimerkiksi yrityksen oma verkkokauppasovellus sekä mahdollisesti verkkosivusto, jonka kautta siihen päästään sisään.
Kohta 6. kuvaa Azure Active Directory Connect -palvelua. Tämä palvelu synkronoi toimiston Active Directoryn tunnukset julkipilveen, eli tässä tapauksessa Azure Active Directoryyn. Synkronointi perustuu aina Active Directory -pohjaan.
Kohta 7. kuvaa VPN-yhteyden Gateway -palvelinta. Tämä on joko Hosted Private -datakeskuksessa, tai toimistoverkon palvelimella. Kyseinen yhteys on yleisesti pullonkaula silloin, kun suurin osa yrityksestä on kotitoimistolla työskentelemässä. Varsinkin, kun kyseessä on Full Tunnel VPN -ratkaisu (joka on ainoa oikea ratkaisu hybridimallissa).
Yllä oleva lisäys kuvaan vielä havainnollistaa tätä pullonkaulaa, sekä kohdan 2. aiheuttamaa pullonkaulaa. Eli VPN-yhteyden kautta ollaan ensin toimistoverkkoon yhteydessä, josta sitten vasta ollaan esimerkiksi sähköpostiin yhteydessä. Ja tässä aina nopeus on rajoitettu juuri siihen nopeuteen, mitä toimistoverkon VPN-yhteyden konfiguraatio antaa myöden. Samassa yhteydessä myös pitää huomioida, että samainen VPN-yhteyden rajoitus tulee ilmi, kun ihan vain toimistoverkosta ollaan yhteydessä datakeskukseen, josta sitten ollaan yhteydessä vasta O365:n järjestelmiin. Kyseessä on siis S2S -VPN -tunneli toimistoverkosta datakeskuksen toimistoverkkoon, joka rajoittaa yhteyden nopeuden usein 100 / 200 MBs -luokkaan VPN-yhteyden salauksen johdosta.
Kohta 8. kuvaa lopulta niitä käyttäjien tunnuksia, joita käytetään @yritys.com -domainin kirjautumiseen. Samassa ovat myös ne ulkoiset tunnukset, jotka kirjautuvat suoraan verkkopalveluihin sisään tai käyttävät yrityksen verkkosivuston verkkokauppaa.
Kohta 9. kuvaa sekä yleisesti käytössä olevaa verkkolevyratkaisua (Network Drive / Network Share), että muita mahdollisia erillisiä yrityssovelluksia sekä palvelimia, joita yritys tarvitsee. Tähän voivat kuulua esimerkiksi dokumentinhallinnan palvelimet (DMS), SCCM sekä SCOM-palvelimet että esimerkiksi asiakkuuden hallintajärjestelmiä (CRM) tai 3D -mallintamiseen käytetty CAD-järjestelmä. Nämä vaihtelevat merkittävästi yrityskohtaisesti, ja kyseinen osa voi olla erittäin laaja ja tärkeä osa yritysinfrastruktuuria, tai vain pelkkä verkkolevyratkaisu.
Kohta 10. kuvaa niitä laitteita, mitä ei hallita lähtökohtaisesti mitenkään, mutta niillä on kuitenkin pääsy yrityksen O365:n resursseihin. Yleisin esimerkki tästä on aivan tyypillinen älypuhelin, jolla on synkronoituna esimerkiksi yrityksen sähköposti. Kyseessä on Suomalainen standardilaite, eli työsuhdepuhelin. Muita vaihtoehtoisia laitteita ovat kotitietokone, jolta silloin tällöin tarkistetaan sähköposti tai Teamsin tiimin viestittelyt, jotka ovat O365:ssä saatavilla. Listaan voi myös lisätä esimerkiksi minkä vain verkkoselaimen (Chrome, Firefox, Safari yms.) jolla voidaan kirjautua O365:n portaaliin.
Nämä yksittäiset laitteet ovat hybridiyrityksessä yksittäinen SUURIN riskitekijä. Jos yritys sallii tällaisten pääsylaitteiden käytön ja pääsyn O365:n resursseihin, tai peräti suoraan yrityksen resursseihin, voidaan olettaa seuraavaa.
Kaikki yrityksenne data on jo vuotanut kolmannelle sekä haitalliselle osapuolelle.
Kun näitä laitteita ei suojata tai hallita mitenkään, niin on erittäin suotavaa olettaa jo suoralta kädeltä, että yrityksen kaikki näiden pääsylaitteiden oikeuksien piirissä oleva data on päässyt sellaisille tahoille, joille se ei kuuluisi. Tähän kuuluvat myös mitkä vain verkkoselaimet (Chrome, Safari, Firefox, yms.) joilla on mahdollisuus käsitellä yrityksen O365:n dataa.
Tämä kulminoituu lopulta ihan siihen yksinkertaiseen tilanteeseen, että se on mahdollista.
Voidaan toki edelleen ajatella, että eihän tämä nyt meille voi tapahtua, tai että ei meidän datamme ketään kiinnosta. Tämähän ei tietenkään pidä paikkaansa, vaan kaikki data lähtökohtaisesti kiinnostaa rikollisia osapuolia.
Siksi nämä lokaatiot pitääkin tuoda modernisoinnin piirissä mukaan hallinnan ja pääsyoikeuksien alle. Vaihtoehtoisesti O365:n yritysresursseihin pääsy voidaan estää hallitsemattomilta laitteilta ja lokaatioilta, mutta tämä onnistuu tehokkaimmin vain modernisoidussa ympäristössä. Muissa ympäristöissä pitää vielä luottaa siihen, että Active Directory ja toimiston + datakeskuksen verkko ovat kunnossa. Eli hybridimallissa toimisto ja datakeskuksen datayhteys on aina pullonkaulana.
Mitenkö tämänkaltainen ympäristö esimerkiksi sitten modernisoitaisiin?
Kohti modernia IT-infrastruktuuria
Kaikki yllä mainitut kohdat ovat hyvinkin helposti modernisoitavissa.
Jaa että mitenkö? Illustroin tätä väitettäni saman tien kuvalla.
Moderni IT-puoli
Avataanpa jokainen kohta vielä tarkemmin. Harmaalla pohjalla oleva tieto on samassa paikassa, eli Azure AD:ssä / O365:ssä. Paikallisessa datakeskuksessa ei ole mitään, ja toimistolla vain tästä järjestelmästä erillinen toimistoverkko. Valkoisella pohjalla oleva kuvaa Internetiä ja sen yli kulkevaa dataa, alemmassa kuvassa tämä on vielä erikseen hieman illustroituna.
Kohta 1. Muuttuu niin, että kirjautumisportaaleita / järjestelmiä on vain yksi, eli Azure + O365 -pohjainen kirjautuminen. Näin kaikki autentikaatio saadaan yhden järjestelmän monitoroinnin alle, ja kulkemaan Azuren kattavan auditointipohjan kautta. Ja myös kaikki pilviapplikaatiot (AWS, Google, Facebook, YouTube yms.) saadaan osaksi tätä monitorointia ja hallintaa. Näin yrityksen datan liikkuvuuden ja pääsyn seuraaminen on merkittävästi paremmalla tasolla, kuin hybridiympäristössä. Siellä kaiken autentikaation saattaminen hybridiympäristön AD-pohjan alle on, kauniisti sanottuna, erittäin työllistävä projekti. Azureen taasen yhdistyvät kattavasti suorien, sisäänrakennettujen ja dokumentoitujen toteutusten kautta lähtökohtaisesti kaikki modernit palvelut. Eli tunnusten integroiminen muihin järjestelmiin on merkittävän vaivatonta.
Kohta 2. tarjoaa kaikista merkittävimmän muutoksen ympäristöön. VPN-yhteydestä ja toimistoverkosta tulee tässä tapauksessa tarpeeton. Tämä selittyy niinkin yksinkertaisella asialla kuin sillä, että kaikki data on SSL/TLS-salauksen takana suojattuna. Eli myös toimistoverkon kautta tuleva liikenne on jo suoraan suojattua. Näin erillistä palvelinkeskuksen kautta kulkevaa VPN-toteutusta ei tarvita, joka muodostuisi pullonkaulaksi ja riippakiveksi. Tai edes potentiaalisesti toimistoa tai sen verkkoa.
Näin myös yrityksen verkon nopeus on työntekijämäärä x 100 MBs (keskimääräinen kotiverkon nopeus). Eli potentiaalisesti jäljelle jäävää toimistoverkkoa voidaan keventää merkittävästi, ja Internal DNS / DHCP-konfiguraatio muuttuu merkittävän kevyeksi toteuttaa. Normaalisti näitä molempia varten tarvitaan omat palvelut ja ylläpito, mutta tässä tapauksessa molemmat hoituvat helposti jo pelkästään verkkolaitteiden oman palomuurilaitteen kautta. Isommissa toimistoverkoissa (käyttäjämäärä koko ajan + 300) voi dedikoiduille pfSense -tyyppisille räkkipalomuuripalvelimille olla kuitenkin vielä selvä tarve. Lähtökohtaisesti tämä kuitenkin poistaa juuri toimistoverkon sekä paikallisten palvelinkeskusten aiheuttaman pullonkaulan yrityksen IT-ympäristöön.
Alla oleva hieman muokattu kuva vielä illustroi sitä, että jokainen oma Azuren palvelunsa saa tässä suoran, salatun, turvatun sekä nopeusrajattoman yhteyden Internetiin, jonka kautta taasen yhteys on edelleen turvattu hallitulle, monitoroidulle ja automaattisesti päivitetylle päätelaitteelle asti.
Eli kaikki VPN-yhteyden hyvät puolet ilman sen aiheuttamia rajoituksia ja vaatimuksia. Kaikkia yllä mainittuja pääsyoikeuksia voidaan vielä yrityksen tarpeen mukaan rajata, ja esimerkiksi palomuuripalvelu sekä kuormantasaus on sisäänrakennettuna Azuren Virtual Network -ratkaisuun sekä Azure Virtual Desktop -toteutukseen. Eli nämä on oletusarvoisesti suojattu haitalliselta pääsyltä.
Kohta 3. onkin tässä järjestyksessä mielenkiintoisin alue. Eli Azure Active Directory Domain Services (AADDS). Palvelu, jota parjattiin turhana. Azure Virtual Desktop on kuitenkin muuttanut tätä merkittävästi. Näiden kahden palvelujen yhdistämisellä saadaan mikä vain on-prem, legacy AD-autentikaatioon perustuva yritykselle kriittinen sovellus modernisoitua skaalautuvaksi Azure -pohjaiseksi ratkaisuksi. AADDS siis tarjoaa automaattisesti ylläpidetyt ja hallinnoitavissa olevat Domain Controllerit sekä oman alidomainin Azuren tenantin alle. Tämän kautta saadaan tehokkaasti ja erittäin pienellä ylläpitovaivalla AD-autentikointi toteutettua niitä sovelluksia varten, jotka sitä vielä vaativat. Usein tämä on ollut kynnyskysymys mahdollisissa modernisointiprojekteissa. AADDS + Azure Virtual Desktop kuitenkin tarjoaa suoran virtualisoinnin ja modernisoinnin vaihtoehdot, joita ei kannata sivuuttaa.
Kohta 4. porautuu nimenomaan siihen, että tuotantosovelluksista voidaan karsia kaikki sovellushallinnan ja monitoroinnin SQL-palvelinrakenteet pois. Näin myös voidaan tämä kapasiteetti joko jättää kokonaan pois, tai vaihtoehtoisesti siirtää sitä nimenomaan virtualisointiin sekä tuotantosovellusten tehostamiseen. Ideaalitilanteessa kuitenkin myös kaikki kriittiset tuotantosovellukset, jotka pohjautuvat AD-autentikaation, modernisoitaisiin sovellustarjoajan pilvipohjaisiin kokonaisuuksiin. Tämä ei kuitenkaan aina ole mahdollista, joten AADDS + Azure Virtual Desktop onkin tässä tilanteessa merkittävän hyvä vaihtoehto.
Kohta 5. tarkentaa verkkosovellusten virtualisointia. Nekin saadaan hyvin tarvittaessa hallintaan ja pääsyn piiriin Azure App Proxy -palvelun kautta. Tässä applikaatiopalvelimelle (tai yhdyspalvelimelle) toteutetaan App Proxy, joka hoitaa sen jälkeen mahdollisten web-applikaatioiden pääsynhallinnan ja sallimisen. Näin http -pohjaiset sovellukset saadaan sellaisenaan toteutettua tietoturvallisesti verkon yli Azure -pohjaisessa ympäristössä. Ja autentikaatio toimisi suoraan O365:n tunnuksilla sekä ryhmäkohtaisella pääsyoikeusmäärittelyllä.
Kohta 6. Taasen kuvaa nimenomaan sitä AADDS:n osaa, joka on erittäin tärkeässä roolissa. Normaalissa AD Connect-ratkaisussa Active Directory on aina ankkuriarvo. Azure AD DS -pohjassa näin ei kuitenkaan ole. Siinä Azure Active Directoryn tunnusta käytetään aina ankkuriarvona, jolloin pieninkin riski mahdollisille sähköpostin tai muulle tunnusten katkeamiselle on olematon. Näin myös mahdollinen AD:n synkronointivirhe ei tyhjennä koko yrityksen käyttäjälistausta ja aiheuta väliaikaista katkosta sähköpostiliikenteessä. Reverse AD Sync on siis erittäin arvokas palvelu, ja tätä ei voida toteuttaa edes siinä tilanteessa, että Active Directoryn palvelinkonfiguraatio tehdään manuaalisesti Azureen. Reverse AD Syncin saa vain Azure Active Directory Domain Services-palvelun kautta.
Azure Virtual Desktopin selvät edut tuo ilmi Microsoftin oma kuva asian tiimoilta, joka on alla:
Kohta 7. tuokin esille tuon VPN-yhteyden ja sen, että sitä ei enää vaadita. Toki, yhdessä tietyssä reunatilanteessa Split Tunnel VPN on hyödyllinen: SMB-portin reitityksen ja Azure Files -verkkolevyn kanssa. Tässä taustalla on se, että verkkoyhteyden tarjoajat (ISP, kuten Elisa tai Telia) edelleen vanhojen toimintaperiaatteidensa takia (tai omien laitteistojensa suojelemiseksi) estävät oletusarvoisesti myös salatun SMB-portin liikenteen. Tässä tilanteessa tarvitaan ns. Private Endpoint -toteutusta, joka reitittää kaiken käyttäjän hallitun tietokoneen SMB-liikenteen Open VPN -pohjaisen P2S – Split Tunnel VPN-yhteyden kautta. Tässä hyvä puoli on se, että vain Azure Filesin data siirtyy tässä Split Tunnel VPN-yhteyden kautta. Eli tämä ei vaikuta muihin O365:n ja Azuren palveluihin, ja on vaatimuksena vain, jos ISP estää kotiverkossa tämän SMB-portin (445) -liikenteen. Eston voi poistaa muutamillakin eri keinoilla myös olemalla yhteydessä paikalliseen verkon toimittajaan.
Taustalla tässä on siis SMB 2.1 sekä SMB 1.0 -pohjaisten datasiirtojen tietoturvattomuus. Azure Files käyttää kuitenkin aina ja pakotetusti vähintään tietoturvallista SMB 3.0+ -protokollaa kun dataa siirretään tai käsitellään Internetin yli. Eli kun esto on tehty vain porttikohtaisesti, pitää se kiertää jollain soveltuvalla tavalla. Muuten VPN-yhteys on tässä modernissa ympäristössä täysin tarpeeton.
Kohta 8. tuo esille sen, että käytössä on vain yksi tunnus: O365:n / Azuren kirjautumistunnus. Tämähän on myös siitä mukava tunnus, että lähestulkoon jokaisella yrityksellä tämä on jo valmiiksi olemassa. Tunnus tulee lähtökohtaisesti automaattisesti konfiguroitua, kun Officen sähköpostipalvelua otetaan käyttöön. Tämän takia tunnukset ovatkin jo suurella osaa yrityksistä valmiina, ja migraatio on merkittävästi yleisesti luultua helpompi tämän osalta. Kaikki O365:n kirjautumisten tilanteet ovat myös hallittavissa ja seurattavissa suoraan Azuren erittäin kattavan monitoroinnin kautta. Näin esimerkiksi mahdolliset kirjautumisyritykset ulkomailta voidaan helposti havaita ja estää. Eli ns. Zero Trust -malli tulee tässä automaattisesti käyttöön.
Kohta 9. on tuotantosovellusten kohdalla se, joka aiheuttaa myös aina paljon kysymyksiä. “Miten sitten tiedostot ja tiedostopalvelimet tehdään siellä modernissa ympäristössä?”. Tähän on tosiaan muutamakin vaihtoehto. Paras vaihtoehto on kuitenkin aina ensin arvioida kaikki tarpeellinen data ja siihen liittyvät työnkulut läpi.
Usein tässä piilee kuitenkin se vaara, että projektin toteutuksessa voi näin kestää merkittävän kauan. Jonka takia usein data siirretäänkin vain nopeasti johonkin pilvilokaatioon. Suosituksemme on aina ainakin pintapuolisesti arvioida, miten olemassa olevia datarakenteita ja datan työstämisen tapoja voitaisiin edes hieman parantaa, ja miten niitä voitaisiin tulevaisuudessa, mahdollisen modernisoinnin jälkeen parantaa.
Näin ainakin suunnitelma on sitten valmiina, eivätkä työnkulut jatku samalla tutulla kaavalla kuin aina ennenkin.
Mutta. Tiedostorakenteen muutokseen on kaksi hyvää vaihtoehtoa: Suora kaiken siirto Teamsin tiimeihin (Sharepoint taustalla) tai osan siirto Teamsiin ja osan siirto Azure Filesiin. Pelkkää Azure Filesia emme suoraan suosittele, koska tässä ei suoraan modernisoida rakenteita tai toimintatapoja.
Azure Filesia tulee käyttää silloin, jos yhtä suurta datakokonaisuutta ei voida suoraan mäpätä käyttäjille (datarakenteessa yli 300 000 tiedostoa / kansiota). Koska synkronointi perustuu OneDriven synkronointiin, on erittäin suurien kappalemäärien kanssa tehtävä kompromisseja. Myös yli 300 000 tiedoston sekä kansion määrät toimivat Teamsin ja Sharepointin kautta hyvin, mutta kokonaisen tällaisen rakenteen metadatan synkronointi ja mäppäys aiheuttaa yksittäisen koneen potentiaalisia jumiutumisia. Taustajärjestelmään tämä ei vaikuta, mutta yksittäinen tietokone jumiutuu tässä tilanteessa. Siksi datan kulkuja ja rakenteita pitääkin erikseen tässä arvioida ja modernisoida ja mäppäyksen tarvetta arvioida tarkkaan. Jos tämä ei kuitenkaan ole mahdollista, tarjoaa Azure Files parhaan ja toimivimman kokonaisuuden datan hallintaan suurten tiedostomäärien kokonaisuuksien hallinnan kohdalla. Toki, tässä piilee taasen omat rajoituksensa, jotka vaativat joka tapauksessa datan pilkkomista ja tarkentamista (Täydet NTFS -oikeudet suoraan tietokoneelle mäpättäessä).
Toinen usein esille tuleva “ongelma” on tulostinpalvelin. Miten voimme selvitä ilman sellaisen järjestämistä ja ylläpitoa? No helposti. Sitä ei vain enää nykymaailmassa yksinkertaisesti tarvita.
Tähän ratkaisuna pienemmissä tulostustarpeissa on Direct IP -pohjainen, PowerShelliin perustuva tulostinmääritys ja tulostus ja suuremmissa tarpeissa Printix -tyyppinen pilvitulostusratkaisu. Molemmat vaihtoehdot korvaavat täysimääräisesti tulostinpalvelimen tarpeen.
Kohta 10. tuo esille muutoksen tärkeimmän osa-alueen. Yrityksen hallinnan ulkopuolisten laitteiden pääsy kaikkiin työresursseihin on estetty. Tämä mahdollistaa Zero Trust -pohjaisen tilanteen, jossa jokainen kirjautuminen on oletusarvoisesti turvaton (Conditional Access + Azure AD). Näin vain tiettyjen ehtojen täyttyessä kirjautuminen ja resurssien käyttö on sallittua. Tämä estää blankkona jo mahdolliset tilanteet, joissa hallitsemattomista lokaatiosta voitaisiin päästä yrityksen resursseihin käsiksi.
Samalla myös jokainen lokaatio, josta dataa käsitellään, on yrityksen hallinnan alla. Tässä tilanteessa yrityksen tärkein asia on suojattu, eli yrityksen data. Näin mahdollinen inhimillisen virheen riski poistetaan, ja yrityksen sekä työntekijän tilanne on erittäin turvattu.
Tätä ei useinkaan oteta huomioon pilvipalveluita käyttöön otettaessa, ja usein edelleen kaikki pohjataan vain ylläkin kuvattuun “Perimeter Defence” -malliin. Tässä vain tietty alue suojataan (toimiston / on-prem datakeskuksen verkko), mutta esimerkiksi ne laitteet ja lokaatiot, jotka pääsevät joko tähän järjestelmään tai O365:n sähköposteihin tai Teamsiin sisälle, ei huomioida ollenkaan tai tarpeeksi hyvin. Eli juuri jos esimerkiksi verkkopohjainen sähköpostidatan käsittely sallitaan, työsuhdepuhelimia ei valvota mitenkään tai verkkoselainpohjainen sähköpostin käsittely sallitaan MFA:n käytön kanssa.
Koko modernisoinnissa tärkein muutos on juuri hallitsemattomien laitteiden pääsyn estäminen suoraan. Myös hybridiympäristössä tämä on mahdollista, mutta usein niin työlästä, että siihen ei lähdetä. Tai pääsy sallitaan tiettyjen ehtojen täyttyessä (esim. MFA-vaatimus). Tässä tilanteessa toki tietyt ehdot täyttyvät, mutta mikään ei estä sitä, että MFA-vaatimuksen laite on silti saastunut jo valmiiksi ja lähettää dataa esimerkiksi kolmannelle osapuolelle. Lähtökohtaisesti pahin tilanne on se, että dataa ei kryptata, vaan sitä seurataan ja viedään yrityksen huomaamatta.
Hallitsemattomalta laitteelta tai selaimelta voidaan esimerkiksi ottaa taustalla dokumenteista tai koko laitteesta ruutukaappauksia, jotka sitten lähetetään kyseisen laitteen / selaimen kautta kolmannelle osapuolelle internetin välityksellä. Kyseiset kuvankaappaukset analysoidaan automatisoidusti esimerkiksi OCR:n avulla, ja näin kaikki käsitelty dokumentin data on vuotanut kolmannelle, kriminaaliselle osapuolelle. Ja tämän kohteeksi joutunut yritys ei tiedä asiasta mitään, koska seurantaa tai estoa tälle ei hallitsemattomalla laitteella tai selaimella ole.
Eli pelkkä MFA:n vaatiminen ei tässä tapauksessa ole laisinkaan riittävä ratkaisu.
Kryptolukitus ei siis ole se suurin uhkatekijä. Siinä vaiheessa riski vasta tiedostetaan, ja jo kehittyneemmät tahot ovat tarvitsemansa datan vieneet sekä analysoineet.
Lopputulema
Yllä oleva esimerkki on siis yleistys suhteellisen yleisestä yrityksen infrakokonaisuudesta. Jokaisella yrityksellä on kuitenkin oma kokonaisuutensa, joka hieman tästä poikkeaa esimerkiksi kriittisten yrityssovellusten osalta. Näiden osalta päteekin aina seuraava suositus:
JOS VAIN MAHDOLLISTA, NIIN MODERNISOIKAA YRITYSSOVELLUKSET PaaS / SaaS -pohjalle!
Näin vähintään olemassa olevia palvelurakenteita tulee arvioitua ja muutettua jo arvioinnin kautta. Voi esimerkiksi käydä niin, että arvioinnissa jokin vanha ja “kriittinen” palvelukokonaisuus voidaankin TÄYSIMÄÄRÄISESTI korvata modernilla ratkaisukokonaisuudella (Teams, automaatio, sovellusjakelu yms.).
Kun kuitenkin niitä kriittisiä palvelukokonaisuuksia löytyy, mitä ei voi modernisoida (tai niiden riippuvuussuhteet tätä vaativat), niin on yllä mainittu ja modernisoitu kokonaisuus usein se paras ja pisimmälle tulevaisuutta kestävä ratkaisu. Tämä johtuu siitä, että siinä otetaan kaikki seuraavat osa-alueet huomioon:
- IT-laitekanta (tietokoneet, palvelimet, mobiililaitteet)
- Yritykselle kriittiset työnkulut ja palvelut + ratkaisut
- Yrityksen data, sen hallinta ja pääsyoikeudet
- Toimisto + potentiaalinen data (toimistoverkko, tulostimet)
- Käyttäjätilit
Avataanpa näitä hieman:
IT-laitekanta siis tosiaan tässä muuttuu täysin, mutta vain sovelluspohjaisesti. Eli jokainen yrityksen dataa käsittelevä laite tai palvelu on tässä turvattu. Tämä ei yritykseltä vaadi lisäpanostuksia, vaan kuuluu nimenomaan soveltuvaan palvelukokonaisuuteen. Usein tätä ulkoistetaan ihan vain sovellus- ja laitehallinnan monimutkaisuuden takia. Tässä järjestelyssä on tarkoitus yksinkertaistaa IT-ympäristö mahdollisimman pitkälle ja ylläpitää sitä mahdollisimman pitkälle automatisoidusti. Näin työntekijöiden turhaan työhön käyttämä aika minimoidaan, ja aikaa jää merkitykselliseen työpanokseen.
Myös mobiililaitteet tulevat tässä hallinnan ja/tai pääsyn eston alle. Näitä ei usein juuri huomioida tarpeeksi hyvin, ja oletetaan että niiltä ei dataa käsiteltäisi. Tosiasiassa, millä vain verkkoselaimella tai laitteella, millä on sähköpostiin tai Teamsiin pääsy, voi käsitellä ja siirtää hyvinkin helposti yrityksen dataa. Toinen on myös se tilanne, että mobiililaite varastetaan. Tässä tilanteessa yrityksen vaihtoehdot ovat potentiaalisesti hyvin rajatut, jos laitetta tai sen pääsyä ei voida estää mahdollisen ylläpidon kautta. Potentiaalisesti, ilman hallintaa, koko yrityksen data vuotaa yksittäisen puhelinvarkauden johdosta. Modernissa mallissa tämä on helppo estää ja hallita.
Päivitykset ja laitteiden asennukset taas ovat täysin automatisoituja SCCM:n sijaan Intunen ja AutoPilotin kautta. Tämä sovelluskombinaatio mahdollistaa yrityksen kaikkien sovellusten päivitykset, jakamiset ja monitoroinnin ilman erillistä panostusta kalliisiin lisäratkaisuihin. Esimerkiksi Windowsin päivitykset putoavat dedikoidulta WSUS-palvelimelta pois, joka ei enää vie tai vaadi ylläpitoa IT:stä. Windows Update for Business (WUfB) -palvelu korvaa tämän tarpeen täysimääräisesti. Päivitykset näet jaellaan tässä Intunen kautta, jolloin päivitykset tulevat tehokkaasti myös kotitoimistolla oleville laitteille, ja täysin ilman VPN-vaatimuksia. Sama koskee kolmannen osapuolen päivityksiä. Tähän ratkaisuna on muutamakin erilainen vaihtoehto. Jos tarve on vain muutamalle yleiselle sovellukselle, hoitaa Chocolatey Public Reposity -palvelukokonaisuus tarpeen erittäin hyvin. Jos tarve on kuitenkin suurempi, voidaan Chocolatey -palvelin konfiguroida asiakkaan omaan Azureen, ja luoda jokainen dedikoitu sovelluspaketti tätä kautta. Vielä suuremmissa tarpeissa C4B on paras vaihtoehto Chocolatey Software | Pricing
AutoPilot taasen tekee jokaisesta laitetoimituksesta käyttäjille täysin automatisoituja. Enää laitteita ei tarvitse erikseen alustaa toimistolla tai IT:n toimesta ennen toimitusta käyttäjälle. Laitteet ovat suoraan tehtaalta jo käyttövalmiita, eli ne voidaan heti toimittaa käyttäjän kotitoimistolle, tai tarvittaessa yrityksen toimistolle. Näin esimerkiksi uusi työntekijä pääsee suoraan sisään työympäristöön saman tien, eikä ensi viikolla kaikkien pitkäveteisten oikeusmäärittelyjen jälkeen. Alla on vielä selkeä dokumentointi tämän palvelun eduista: Overview of Windows Autopilot | Microsoft Docs
Samalla myös tietoturvan lisäyksen hoitaa Microsoft Defender for Endpoint, joka integroituu saumattomasti koko tähän ratkaisupohjaan ja on saatavilla myös Apple ja Android -laitteille. Sanomattakin on selvää, että se toimii myös Windowsilla. Kun kyseessä on täysin Microsoftin jo olemassa oleviin palveluihin integroitu ratkaisu, toimii se paremmin tässä yhteydessä kuin mikään muu vastaavanlainen, traditionaalinen ohjelmisto. AutoPilotin ja Intunen kanssa tämä järjestelmä toimii saumattomasti yhteen, ja tarvittaessa estää kaiken laitteen pääsyn ja alustaa + tyhjentää laitteen suoraan mahdollisen uhkatilanteen kohdalla. Tässä tilanteessa esimerkiksi yllämainitun puhelimen varkauden kohdalla olisi riski täysin mitätön. Laite olisi ensinnäkin pakotetusti salattu, se voitaisiin tyhjentää heti kun se on yhteydessä internettiin ja sillä olevat dokumentit eivät olisi saatavilla ilman internet-yhteyttä.
Intune tarjoaa myös mahdollisuuden yhdistää mobiililaitteiden sovellus -ja laitehallinnan sekä Googlen “Managed Google Play Store” että “Apple Business Manager” -palveluihin. Näiden kautta sekä Androidin että macOS / iOS -laitteiden täysimääräinen hallinta ja automatisaatio on mahdollista.
Laitekanta myös yksinkertaistuu merkittävästi, kun palvelinkantaa tässä yhteydessä saadaan karsittua. Näin esimerkiksi päivitysten ja haavoittuvuuksien hallinta on merkittävän paljon helpompaa, kun kaikki data on jo oletusarvoisesti SSL/TLS-salauksen ja Bitlockerin tai mobiililaitteen salauksen alla.
Tästä siirrytäänkin hyvin juuri näihin kriittisiin työnkulkuihin ja palvelukokonaisuuksiin. Näissä tosiaan aina ensimmäinen etenemissuunta modernisaatiossa on niiden tarpeellisuuden ja modernisoinnin mahdollisuuksien arviointi. Nämä työnkulut ja toimintamallit ovat kuitenkin juuri niitä tärkeimpiä yrityksen tulonlähteitä, joten on selvääkin selvempää, että niitä on erittäin suotavaa arvioida ja PARANTAA!
Näin sekä yrityksen tuottavuus että jatkuvuus ovat selvästi paremmalla mallilla. Samalla myös tulee arvioitua yrityksen toimintamallien jatkuvuutta. Ei ole mitenkään poissuljettua, että nykyinen toimintamalli tai tapa on täysin vanhentunut jo nyt, tai jo muutaman vuoden päästä. Tällainen arvio on hyvä tehdä vähintään muutaman vuoden välein. Jos nykyisessä digitaalisessa maailmassa tätä ei tehdä aktiivisesti, voi yrityksen koko toimintamalli vanhentua, ja tästä tilanteesta on vaikea nousta.
Mutta jos tämänkaltainen suora kriittisten palveluiden modernisointi ei ole mahdollista, on mainitsemamme muutos Azure AD DS -pohjaan sekä Azure Virtual Desktoppiin erittäin validi. Näin yrityksen datan käsittely on varmasti modernilla, vähintään 10+ vuotta kestävällä ratkaisupohjalla. Se on myös kuitenkin juuri yhteensopiva vanhempien ratkaisumallien kanssa AD-yhteensopivuuden kautta, ja tarjoaa lähes rajatonta skaalautuvuutta yrityksen kasvun yhteydessä. Ja usein vähentää kuitenkin kustannuksia lisensoinnin ja tehostamisen kautta, mutta tämän varaan ei pidä modernisoinnissa tähdätä. Kulusäästöjä syntyy parhaiten silloin, kun olemassa olevia toimintamalleja päivitetään. Suorassa siirtämisessä kulurakenne hyvin harvoin muuttuu merkittävästi.
Datan käsittelyn ja pääsyoikeuksien kohdalla tulee myös toinen merkittävä muutos. Kaikki data on lähtökohtaisesti vain yhden tunnuksen takana, eli Azure Active Directoryn (/ O365) tunnusten saatavilla. Tämä yksinkertaistaa merkittävästi käyttäjien päivittäistä kirjautumisten määrää, ja tunnusten pyörittelyä. Jo tällä saadaan pelkästään merkittävä hyötyarvo päivittäiseen työhön, kun tunnuksia ei tarvitse erikseen arpoa jokaiseen palvelukokonaisuuteen. Tunnukset saadaan myös näin tehokkaasti turvattua ja yrityksen monitoroinnin alle. Näin kaikki mahdolliset kolmannen osapuolen kirjautumiset saadaan seurantaan ja sitä kautta kitkettyä pois. MFA on oletusarvoisesti vaadittu, joka on yksittäisesti SUURIN tietoturvatoimi, mitä yritys voi nykymaailmassa vaatia. Helpottava tekijä tässä on myös se, että jokainen ratkaisu vaatii jonkinasteisen tunnuksen, jotta dataa voidaan käsitellä. Näin jokainen jo hiemankin epäilyttävä kolmannen osapuolen datan käsittelyyn liittyvä tilanne saadaan selville ja estettyä. Tämä onnistuu soveltuvaan palvelukokonaisuuteen sisältyvän Defender ATP -järjestelmän ja Cloud App Security + Label Managementin kautta. Kyseessä on erittäin tehokas hallintatyökalu tiedostojen turvallisuuden määrittelyyn. Nämä ovat tehokkaasti saatavilla ja toiminnassa vain modernisoidussa ympäristössä Compliance -palvelurakenteen kautta.
Tämän kattavan kokonaisuuden kautta esimerkiksi “Confidential” tai “Highly Confidential” -materiaali saadaan kattavasti seurantaan, ja esimerkiksi tällaisen materiaalin lähetys voidaan suoraan estää yrityksen sisäisistä resursseista. Näin inhimillisen virheen riski on minimaalinen, ja mahdollinen GDPR-loukkauksen riski on olematon. Myös DLP-politiikka tulee samassa yhteydessä arvioitua kattavasti yrityksen datan osalta, eli siis Data Loss Prevention -menettely.
Kaikki pääsyoikeudet on myös keskitetty juuri Azure AD:n oikeuksien ja tunnusten alle, eli ne ovat hyvin seurattavissa ja automatisoitavissa sekä dynaamisten ryhmien, että Azuren Privileged Identity Managementin kautta. Eli pääsyoikeuksien kesto voidaan automatisoida ja määritellä, jolloin pitempiaikainen tunnusten pääsy poistuu sitten, kun sille ei enää ole tarvetta. Eli oikeudet voidaan määrätä varmasti vain väliaikaisesti sekä monitoroidusti, jolloin taas inhimillisen virheen riskiä voidaan vähentää merkittävästi.
Toimiston tilanne tässä esimerkissä käy tosiaan tukalaksi. Eli se tulee lähinnä tarpeettomaksi eikä yksinään rajoita yrityksen kasvua. Usein isommissakin yrityksissä on jonkinasteinen yritysverkko, johon pitää sekä toimistolta että kotitoimistolta yhdistää VPN-ratkaisulla. Tähän on ihan yksinkertainen syy: Tietoturva. VPN-ratkaisu on juuri tässä tapauksessa hyvä ratkaisu. Modernisoidussa ympäristössä tämä VPN-yhteys tehdään kuitenkin täysin tarpeettomaksi, ja näin koko yritysverkon pullonkaula poistetaan. Toimistoverkossa VPN-yhteys on piilotettu päivittäisestä käytöstä S2S -tunneleilla, jotka ovat merkittävän kalliita ja rajoittavia ylläpitää, tai SD-WAN-toteutusten avulla, joka on vielä kalliimpaa ja vaikeampaa ylläpitää. Pienelläkin toimistolla turvatun verkkoyhteyden ja VPN-yhteyden kulu on n. 1000 – 2000€ / kk. Tämä arvio on vielä vain kevyessä yhteydessä, eli n. 100-500 MB/s -nopeudessa. Esimerkiksi yli 1 Gbit/s -nopeuden kanssa kulu voi kasvaa jo erittäin kohtuuttomaksi. Samalla myös vaatimus sille, että toimistoverkko on toiminnassa koko ajan, poistuu. Näin myös työskentely esimerkiksi mobiililaitteen jaetun yhteyden yli on erittäin helppoa. Alla vielä on selvästi illustroitu tyypillinen VPN-toteutus, ja missä pullonkaula ilmenee.
Tämän päivityksen merkitystä usein vähätellään merkittävästi, mutta lopulta tämä vapauttaa sekä yrityksen että työntekijät työskentelemään mistä vain. Tietoturva toimii aukottomasti sekä hallittujen laitteiden että SSL/TLS-salauksen kautta. Eli kaikki data on aina oletusarvoisesti suojattu vähintään SSL/TLS-salauksella. VPN-ratkaisuissa voidaan tätä kiertää esimerkiksi sillä, että VPN-yhteyden lisäksi muuten ei turvaa ole verkkolevyillä ja niitä käsitellään tietoturvattoman yhteyden kautta. Alla oleva kuva illustroi mahdollista Split Tunnel VPN-ratkaisua, jossa kaikki muu data, paitsi O365:n data kulkee VPN-tunnelia pitkin. Eli kyseessä on siltikin vielä hyvin vanhankantainen ja rajoittava VPN-yhteys.
Modernit ja oikeat ratkaisut tässä ovat kaksi seuraavaa VPN-yhteyden vaihtoehtoa:
- Ei VPN-yhteyttä lainkaan -> ideaalitilanne ja Zero Trust -mallin ilmentymä. App Proxyn kautta tehtävä suojaus sellaisille sisäisille web-applikaatioille, jotka sitä tarvitsevat
- Rajoitettu VPN-yhteys vain Azure Filesin reititystä varten, jota tietyt ISP:t vaativat vanhankantaisen portin 445 -eston vuoksi.
Molemmissa tilanteissa AD on jo korvattu pelkällä Azure AD -palvelulla. App Proxyn kohdalla vain siis juuri tietylle web-pohjaiselle, Azuren ympäristössä olevalle sisäiselle sovellukselle on tarvetta tälle ratkaisulle. Näitä molempia voidaan myös vapaasti yhdistää, jos tarvetta on sekä webbiapplikaatioille että Azure Filesin verkkolevyille.
Mitä tulee toimiston muihin toteutuksiin, niin niistä voidaan suurelta osin luopua. Esimerkiksi kattavasti turvattu, perimeter defence -pohjainen verkko menettää merkityksensä, kun kaikki toimistoverkossa käsiteltävä data on jo suoraan SSL/TLS-suojattua. Eli kevytkin toimistoverkon suojaus riittää, kun datan suora vuotaminen vaatisi SSL/TLS-salauksen purkamista. Ratkaisuun on kuitenkin hyvä yhdistää verkkolaitepohjainen palomuuri sekä toimiston sisäinen DNS ja DHCP-ratkaisu. Näin toimistoverkossa työskentely on kuitenkin merkittävän tehokasta, ja pitemmällä aikavälillä yritys voi kattavasti arvioida toimiston kokoa sekä tarvetta. Jos nimittäin toimistoa voidaan merkittävästi pienentää etätyön kautta, on se vähintään jo usean työntekijän kuukausipalkkaa vastaava vähennys / kk. Viimeistään pari viime vuotta koronan kanssa ovat todistaneet, että etätyö on sekä tehokasta että toimivaa asiantuntijayrityksille. Ja tämä modernisointi mahdollistaa sen parhaassa ja tietoturvallisimmassa muodossa.
Myös toimiston tulostimen määritys on tässä helppoa ja tehokasta. Oletusarvoisesti määritys tapahtuu Direct IP-pohjalla, jolloin tulostimen omaa sisäistä tulostuspalvelinta käytetään osana ratkaisua. Jokaisessa modernissa tulostimessa näet on tulostinpalvelin sisäänrakennettuna. Ja jos halutaan tietoturvallista tulostusta esimerkiksi kotitoimistolta toimistolle, konfiguroidaan sitä varten etä- ja turvatulostuksen Printix -pilvipalveluratkaisu.
Ja vielä, käyttäjätilit. Näitä käsiteltiinkin jo yrityksen datan pääsyssä, mutta itse käyttäjätilien erillinen arviointikin on suotavaa. Usein näitä on yrityksellä merkittävän paljon vanhanmallisissa tai hybridipohjaisissa Active Directory-järjestelmissä, ja niiden pääsyä ja monitorointia on hyvin vaikea seurata. Tämä johtuu siitä, että AD rakennetaan usein hyvin korkeaksi muuriksi, mutta sallivaksi sisäiseksi kokonaisuudeksi, ja sitä se on oletusarvoisestikin. Siihen pitää erikseen rakentaa estoja, että esimerkiksi AD:ssä oleva yksittäinen käyttäjätunnus ei voi saada kaikkien yrityksen työntekijöiden yleisiä tietoja sekä tietokoneiden yleisiä tietoja haltuunsa. Eli mikä vain tunnus tai tietokone, joka on modernisoimattomassa ympäristössä ja yhteydessä AD-ympäristöön. Modernisoidussa ympäristössä tämä on pelkästään estetty jo sillä, että laitesynkronointi ja käyttäjäsynkronointi on eriytetty Azure Active Directoryn ja Intunen välille. Eli oletusarvoisesti tietokone tai käyttäjätunnus ei voi kutsua tietoja ristiin muista vastaavista yrityksen laitteista ja käyttäjätunnuksista. AD:ssä tämä mahdollista, ja sitä kutsutaan ns. Global Catalog -pohjaiseksi palvelimeksi. Sen kautta voidaan ym. tietoja kutsua, ja oletusarvoisesti se konfiguroidaan AD-ympäristöön ensimmäiseksi Domain Controlleriksi. Azure Active Directoryssä ja Intunessa tämä on estetty oletusarvoisesti, ja vain tietyn tunnustason omaavat tunnukset voivat pyytää näitä tietoja.
Käyttäjätilien yksinkertaistaminen on myös merkittävän tärkeässä roolissa. Usein jossain vaiheessa yritysten käyttäjätilien käsittelyssä tullaan siihen vaiheeseen, että tunnuksia on vain käyttäjille liikaa ja liian useaan järjestelmään. Azuren / O365:n kanssa kaikki nämä tunnukset saadaan yhdistetty tähän yhden tunnuksen alle, ja sen kautta myös saadaan esimerkiksi salasanan vaihto pakotettua ja synkronoitua muihin mahdollisiin palveluihin, jotka on yhdistetty Azureen. Lähestulkoon jokainen yrityspalvelu mahdollistaa tunnusten yhdistämisen Azureen, ja näin tunnusten tietoturvan hoitamisesta ja ylläpidosta tulee merkittävästi helpompaa sekä keskitetympää.
Erillisiin pilvipalveluihin taasen luo turvaa mainittu Cloud App Security, joka on Microsoftin variantti ns. CASB-sovelluksiin (Cloud App Security Broker). Tässä siis monitorointi seuraa ja arvioi, mihin kaikkiin verkkopalveluihin (Facebook, Twitter, AWS) esimerkiksi käyttäjien tunnukset siirtävät yritysdataa. Näin ne tarpeettomat palvelut voidaan sulkea datan siirron ulkopuolelle, johon yrityksen dataa ei tulisi siirtää. Samalla se myös kuuluu suoraan jo soveltuvaan palvelupakettiin. AD-pohjaisessa (hybridi)toteutuksessa kyseessä on merkittävän kallis ja vaikea ratkaisu toteuttaa.
Näin myös käyttäjien tunnukset ovat aina suojattuja yritysdatan ohella. Lopulta koko tämä modernisointikokonaisuus tähtää vain siihen, että yrityksen data on mahdollisimman turvallisesti ja helposti saatavilla yrityksen työntekijöille. Näin työn tekeminen tehostuu ja toimintamallit ovat varmasti modernilla pohjalla. Tästä myös koko IT-ympäristöä on helppo kehittää, ja kaikki mahdolliset lisäpalvelut ovat helposti yhdistettävissä jo olemassa olevaan järjestelmään ilman merkittävää vaivaa ja ylläpitokatetta.
Kaikki tämä lopputuleman kokonaisuus on saatavilla hyvin joustavilla lisenssivaihtoehdoilla yrityksille Microsoftin puolelta. Eli juuri ne tarvitut ja halutut toiminnallisuudet saadan tästä käyttöön. Jo yleisimmällä lisenssillä (M365 BP) saadaan suurin osa em. palvelukokonaisuudesta käyttöön. M365 E5 -lisenssillä korvataan käytönnössä kaikki vanhan IT-infran palvelut yhden käyttäjälisenssin kautta ja tarjotaan merkittävästi lisätietoturvaa ja datan valvontaa, jota ei olisi saatavilla hybridiympäristössä. Eli samalla tällainen toteutus tuo selviä etuja mahdolliseen budjetointiin, kun jokaiselle työntekijälle saadaan selvä kustannusarvio yrityksen järjestelmien käytön suhteen. Tyypillisesti tämä kuva on merkittävän vaikeaa saada, kun järjestelmät ovat jakautuneet useaan erilaiseen lokatioon. Modernissa järjestelmässä yhden käyttäjän kuluttaman IT-budjetin hintalappu on helppo arvioida:
Vaadittu M365 lisenssi + laitteet + mahdolliset muut yksittäiset lisensoidut sovellukset + mahdolliset muut palvelut / kk.
Eli esimerkiksi 20€ + 50€ + Adobe CC = 90 – 100€ / kk
Kun kyseessä on myös kuukausilaskutettu palvelu, voidaan se katkaista nopeasti ilman ylimääräistä kustannusta usean vuoden ajalta.
Parhaan lisätiedon jokaisesta M365:n lisenssistä saa seuraavan, aivan mahtavan Aaron Dinnagen verkkosivuston kautta:
Mistäkö tiedämme tämän kaiken? Kokemuksesta, ja yli kymmenestä suoritetuista vastaavanlaisesta IT-ympäristön täydellisestä modernisointiprojekteista erikokoisissa yrityksissä. Nämä toteutettiin yksin koronavuoden (v. 2020) aikana asiakkaillemme. Emme myös enää toteuta muita IT-ympäristöjä, koska tämä on ainoa tulevaisuutta kestävä kokonaisvaltaisen IT-ympäristön ratkaisumalli.
Kun asian tiimoilta ilmenee kysymyksiä, niin avaamme vastauksia näihin erittäin mielellämme!
Loppukevennys: Jos joku hullu tänne asti pääsi, niin kiitän ja onnittelen teitä! Toivon mukaan tämä herätti edes hieman kysymyksiä ja mietteitä, jos ei mitään muuta.
Tämän kasaan turauksessa meni kuitenkin ihan tarpeeksi pitkään.