Yrityksen liikkuvuus- ja turvallisuuspaketti eli Enterpise Mobility + Security – Osa 3

Kirjoittaja on pitkän linjan IT-ammattilainen, Centero Oy:n toimitusjohtaja ja asiantuntija, Juha Haapsaari.

Liikkuvuus ja pilvipalvelut asettavat sisällön suojaamiselle yhä enemmän vaatimuksia.

Liikkuvuus ja pilvipalvelut asettavat sisällön suojaamiselle yhä enemmän vaatimuksia.

Edellisen, huhtikuussa julkistetun blogisarjan 2. osan jälkeen onkin tullut Microsoftilta jonkin verran muutoksia tämän blogisarjan aihealueen palveluiden suhteen. Lähinnä uusien ominaisuuksien johdosta Enterprise Mobility Suite on jaettu kahteen eritasoiseen pakettiin ja nimikin on muuttunut. Uusi nimi on EM+S eli Enterprise Mobility + Security. Koska tässä blogisarjassa ei ole ollut tarkoituksena käydä teknisiä ominaisuuksia läpi, emme tässä käy uusia ominaisuuksia tarkemmin läpi, mutta todettakoon, että erityisesti tuonne tietoturvapuolelle niitä on tullut.

Identiteetin hallinta

Kun palveluita siirretään yhä enemmän julkisen pilven puolelle, korostuu erityisesti tunnistautumiseen liittyvät asiat. Tämä johtuu siitä, että meillä ei ole julkisissa pilvipalveluissa samanlaista kontrollia itse alustaan tai verkkoihin. Aikaisemmin, kun palvelut olivat omassa verkossaan, meillä oli palomuuri suojaamassa sisäverkossa olevia palveluita. Usein jopa linjattiin, että palvelua ei voinut käyttää, kuin sisäverkosta. Tällöin pystyttiin itse päättämään mistä ja millä ehdoilla yhteyksiä pystyi muodostumaan.

Nyt kun palvelut eivät ole omassa verkossa, pystyy kuka tahansa yrittämään kirjautumista niihin pilven kautta. Tällöin meidän täytyy keskittyä vahvasti siihen, miten ja millä ehdoilla tunnistautuminen tapahtuu, ja sen jälkeen vasta pääsemme miettimään varsinaisia käyttöoikeuksia ja sitä mitä kukin tunnistettu käyttäjä saa tehdä.

Azure AD

Microsoftin pilviekosysteemissä Azure AD on koko identiteetin hallinnan sydän. Siellä meillä ovat käyttäjätunnukset, joilla voidaan kirjautua eri pilvipalveluihin. Azure AD integroituu myös suoraan tuhansiin muihin pilvipalveluihin sekä on-premises palveluihin, jolloin myös näihin voidaan kirjautua Azure AD:n tunnistautumista hyödyntämällä.

EM+S-paketissa tulee mukana Azure AD Premium -käyttöoikeus, joka mahdollistaa meille lisää ulottuvuuksia sekä joustavuutta ja turvallisuutta tunnistautumiseen. Kun lähdetään miettimään tunnistautumisen parantamista, voidaan lähteä hahmottamaan asiaa jälleen kohtuullisen simppelin vaatimusmatriisin avulla.

Tunnistautumisen vaatimukset

Jotta pääsee alkuun vaatimusten määrittelyssä, kannattaa aloittaa, kuten niin usein, pienellä Excel-leikillä. Tästä voit ladata Excel-pohjan asioiden miettimiseen, jota voi lähteä jalostamaan omiin tarpeisiin paremmin sopivaksi.

Lataa esimerkkimatriisi Excel-muodossa klikkaamalla kuvaa.

Lataa esimerkkimatriisi Excel-muodossa klikkaamalla kuvaa.

Matriisiin kannattaa miettiä ensin muutamia vaatimusluokkia sisällölle, jotka voisivat olla esimerkiksi tämän tyylisiä:

  1. Bisnekselle kriittinen
  2. Bisnekselle tärkeä
  3. Vain sisäiseen käyttöön (oletusluokka uudelle sisällölle)
  4. Sisäiseen ja yhteistyökumppaneiden käyttöön
  5. Julkinen

Miksi vaatimusluokat mietitään sisällölle, kun kerran tunnistautumisesta puhutaan? Tämä sen takia että sisältö on se, mitä meidän oikeasti tulee suojata. Sitä kautta kannattaa alkaa purkamaan osa-alueita, joilla sisällönsuojauksen vaatimusluokat täytetään. Näistä osa-alueista tunnistautuminen on yksi osa-alue.

Tämän jälkeen voisi miettiä, millaisten vaatimusten tulee täyttyä tunnistautumisen osalta, jotta kunkin vaatimusluokan sisältöön pääsee käsiksi. Näitä vaatimuksia voisi olla:

  1. Ei vaadi tunnistautumista
  2. Vaatii perustunnistautumisen (käyttäjätunnus + salasana)
  3. Vaatii monivaiheisen tunnistautumisen internetistä
  4. Vaatii monivaiheisen tunnistautumisen
  5. Vain organisaation laitteilta pääsy
  6. Vain sisäverkosta pääsy

Nyt kun nuo kaksi ulottuvuutta on mietitty, päästään linkittämään tunnistautumisen vaatimuksia eri sisällön vaatimusluokkiin. Bisnekselle kriittisen sisällön saamiseksi voitaisiin vaatia esimerkiksi,

  • että käyttäjä on sisäverkossa,
  • on tunnistautunut monivaiheisesti ja
  • käyttää organisaation hallitsemaa laiteta.

Sisällön suojaaminen tunnistautumisella

Kun vaatimusluokille on mietitty tunnistautumisen vaatimukset, sijoitetaan sovellukset matriisiin. Pääsääntöisesti sisältöä luetaan sekä muokataan jonkin sovelluksen avulla, joten siksi kannattaa matriisiin sijoittaa sovelluksia eikä suoraan sisältöä. Toki yleisen sisällön suhteen voi matriisiin laittaa suoraan sisältöön liittyviä vaatimuksia, kuten esimerkiksi tiedostojaot, intranetsisältö jne. Näissä tapauksissa voi matriisiin laittaa sisällön vaatimukset, mutta nekin roolien kautta, joista lisää seuraavassa kappaleessa.

Usein sovellusten sisällä on myös eri rooleja, jolloin kannattaa jokaisen sovelluksen eri rooleille miettiä erikseen, mitkä vaatimukset tällä roolilla pitää täyttyä, jotta sisältöön pääsee sovelluksen kautta käsiksi. Vaikkapa Sharepointissa on useita eri rooleja, ja sitä kautta oikeuksia erilaiseen sisältöön. Jonkin roolin kautta voi päästä vain sisältöön, jota saa lukea ilman monivaiheista tunnistautumista, mutta sitten taas toisella roolilla päästään kriittiseen dataan, jossa kenties vaaditaan monivaiheista tunnistautumista. Yleensä kannattaa miettiä perustaso itse sovellukselle, jota kaikki roolit oletuksena käyttää ja sitten tekee tästä tarpeen mukaan variaatioita eri rooleille.

Jos otetaan esimerkkisovellukseksi vaikkapa CRM-järjestelmä ja siitä kaksi eri roolia:

  • pääkäyttäjä ja
  • myyntihenkilö

CRM-sovelluksen pääkäyttäjällä on pääsy tärkeään dataan, ja tällöin voitaisiin aina vaatia monivaiheista tunnistautumista, sekä pääsyä vain organisaation hallitsemilta laitteilta. Taas myyntihenkilöllä ei ole CRM:ssä pääsyä erittäin tärkeään dataan, vaan ainoastaan sisäiseen käyttöön luokiteltuun dataan, tällöin tässä luokituksessa voisi sallia järjestelmän käytön ilman monivaiheista tunnistautumista sisäverkosta, mutta sitten organisaation verkon ulkopuolelta monivaiheinen tunnistautuminen kuitenkin vaadittaisiin.

Vaatimusten määrittely

Kun matriisi vaatimuksista on tehty voidaan hyödyntää EM+S-paketin tarjoamia palveluita näiden vaatimusten täyttämiseen. Voidaan esimerkiksi määrittää päätelaitteiden hallintaan ehdollisia pääsypolitiikoita, kuten vaatimus että sisältöön voi päästä vain luotetulta laitteelta. Azure AD:n monivaiheinen tunnistautuminen voidaan ottaa käyttöön tietyille sovelluksille ja rooleille huomioiden päätelaitteen sijainti sekä määrittää sisällön suojausasetuksia Azure Information Protection (entinen Azure Rights Management Service) -palvelun avulla.

Kun matriisi on mietittynä, on näiden vaatimusten käyttöönotto pilvipalveluissa yksinkertaisesti vain konfiguraation määritys matriisin vaatimusten mukaiseksi. Tämän lisäksi Azure Information Protection -palveluun voidaan myös määrittää konfiguraatiota dynaamiseksi. Jos esimerkiksi organisaation jonkin käyttäjätunnuksen riskiluokka vaihtuu, voidaan pakottaa käyttäjää käyttämään hetken aikaa monivaiheista tunnistautumista tai vaihtamaan tunnuksen salasana.

Riskiluokan vaihtuminen tapahtuu myös määritellyn konfiguraation mukaisesti pohjautuen Azure-palveluiden dataan ja koneälyyn. Esimerkkinä voisi olla vaikkapa se, että tunnuksella kirjaudutaan lyhyen ajan sisällä kahdesta eri paikasta joiden maantieteellinen etäisyys toisistaan on niin iso, että käyttäjä ei ole voinut fyysisesti vaihtaa sijaintia näin nopeasti. Tällöin riskiluokka voisi automaattisesti nousta, ja käyttäjälle asetettaisiin lisää vaatimuksia tunnistautumiseen, kunnes riskiluokka palautuu normaaliksi.

Yhteenveto

Identiteetin hallinta on yhä tarkeämpi osa tietoturvaa, kun palvelut siirtyvät julkiseen pilveen ja samoja tunnistetietoja hyödynnetään eri palveluissa. Tämän vuoksi tunnistautumisen suojaukseen ja määrityksiin kannattaa panostaa, mutta kaikki kuitenkin pohjautuu sisällön asettamiin vaatimuksiin. Tässä matriisi on erittäin hyvä työkalu, joka ehdottomasti pitäisi täyttää yhdessä yrityksen osa-alueiden vastuullisten kanssa.

Samoin ylin johto on hyvä ottaa mukaan tuomaan isot linjat siitä, mikä on organisaatiolle kriittistä, tärkeää jne. IT on hyvä olla mukana jotta vältetään tilannetta, jossa kaikki järjestelmät ja sovellukset ovat erittäin bisneskriittisiä.

Kannattaa siis panostaa kunnolla matriisin miettimiseen. Sharepoint-listat muuten ovat erinomainen ja helppo työväline matriisin rakentamiseen ja tiedon ylläpitoon. Kun matriisi on luotu, päästään mallintamaan vaatimuksia itse järjestelmiin. Tässäkin kannattaa lähteä kevyesti liikkeelle ja tutustuttaa sekä opastaa käyttäjät siihen, mitä vaatimuksia jatkossa tarvitaan sisällön eri luokille.

Laske säästösi

Automatisoi sovelluspäivitykset ja lopeta pikkusoftien kanssa painiminen. Centero Software Manager säästää aikaa, rahaa ja hermojasi.

« Edellinen artikkeli: WSUS-palvelusi saattaa olla hajonnut – Tarkasta se!
» Seuraava artikkeli: Tietoturvallinen tulostaminen säästää rahaa -webinaarin nauhoite ja materiaali