Mobiililaitteiden hallinta: konfiguraatio ja näyttö

Laitehallinta tukee tietoturvaa vain niiden laitteiden ja asetusten osalta, jotka se todella kattaa. MDM-hallintapaneeli, joka näyttää vaatimustenmukaiset laitteet, edellyttää toista kysymystä: mitkä laitteet puuttuvat? Siitä seuraa kolmas kysymys: kuvaako ”vaatimustenmukainen” tehokasta konfiguraatiota vai pelkästään päätelaitteelle osoitettua politiikkaa?

Teknologiajohtajan tehtävä on tehdä näistä vastauksista toistettavia. Mobiililaitteiden hallinnan tulisi kytkeä toisiinsa laitteiden omistajuus, konfiguraatio, sovellusten käyttöoikeudet, poikkeamiin reagointi ja näyttö. Tavoitteena ei ole vihreä hallintapaneeli. Tavoitteena on puolustettava selvitys siitä, mitkä päätelaitteet pääsevät liiketoiminnan tietoihin, miten ne on suojattu ja mitä tapahtuu, kun suojaus pettää.

Mitä MDM hallitsee – ja mitä ei

Mobiililaitteiden hallinta (MDM) tarkoittaa päätelaitteiden hallinnointia keskitetyn palvelun ja alustan tukemien hallintamekanismien avulla. Tuotteesta, käyttöjärjestelmästä ja rekisteröintitavasta riippuen sillä voidaan ottaa käyttöön konfiguraatioprofiileja, jakaa sovelluksia, raportoida laitteen tilaa, rajoittaa valittuja toimintoja ja antaa etäkomentoja. Laajemmat päätelaitteiden hallintatuotteet voivat kattaa puhelinten ja tablettien lisäksi kannettavat ja pöytäkoneet.

Nämä ominaisuudet eivät ole yhdenmukaisia. Täysin hallittu yrityksen puhelin ja henkilökohtainen puhelin, jossa on hallittu työprofiili, tarjoavat erilaiset kontrollit ja telemetrian. Jotkin alustat käyttävät sisäänrakennettuja hallintapalveluja; toiset edellyttävät lisäagentteja. Jatkuvaa yhteyttä tai välitöntä suorittamista ei pidä olettaa.

MDM ei myöskään korvaa identiteetinhallintaa, päätelaitteiden uhkien havaitsemista, haavoittuvuuksien hallintaa tai tietojen luokittelua. Se voi konfiguroida näitä kontrolleja tai toimittaa niille signaaleja, mutta niiden toiminta on varmistettava erikseen. Hallitulla laitteella voi silti olla liialliset sovellusoikeudet, mitätöimätön istunto tai haavoittuva sovellus.

Määritä kontrolliväite ennen asetusten valintaa. Esimerkiksi: ”Yrityksen kannettavien, jotka pääsevät tuotannon hallintaympäristöön, on oltava rekisteröityjä, salattuja, tuettuja ja äskettäin arvioituja.” Tämä lausuma yksilöi laitejoukon, resurssin ja havaittavat ehdot. ”Kaikki laitteet ovat turvallisia” ei tee niin.

Kytke päätelaitteiden hallinta ISMS:ään

ISO/IEC 27001 koskee rajattua tietoturvallisuuden hallintajärjestelmää, ei tietyn päätelaitetyökalun hankintaa. Sen kohdat 4–10 asettavat hallintajärjestelmän vaatimukset. Liite A tarjoaa 93 kontrollin viitekokonaisuuden, jonka sovellettavuus arvioidaan riskien arvioinnin ja käsittelyn kautta; se ei ole yleispätevä MDM-konfiguraation tarkistuslista.

Soveltamisalaselvitys (Statement of Applicability) kirjaa tarvittavat kontrollit, niiden sisällyttämisen perustelut, toteutuksen tilan ja liitteen A kontrollien poissulkemisen perustelut. MDM-käyttöönotto tarjoaa osan asiaankuuluvien kontrollien toteutuksesta ja näytöstä, mutta ei todista koko ISMS:ää.

Hyödyllisiä kytköksiä ovat:

Nämä kytkökset kuvaavat osuuksia, eivät vastaavuutta. Esimerkiksi kirjautumiskonfiguraation käyttöönotto ei osoita, että pääkäyttäjäoikeudet on hyväksytty asianmukaisesti. Käytä liitettä A käsittelevää opastamme päätelaitetoimenpiteiden kytkemiseen laajempaan ISMS:ään sen sijaan, että laitteiden vaatimustenmukaisuutta käsiteltäisiin erillisenä pistemääränä.

Määritä laitejoukko ennen vaatimustenmukaisuuden mittaamista

Aloita laitteista, jotka tallentavat, käsittelevät tai käyttävät ISMS:n soveltamisalaan kuuluvia tietoja. Ota tarvittaessa mukaan yrityksen omistamat ja henkilökohtaiset laitteet, alihankkijoiden päätelaitteet, jaetut laitteet ja väliaikaiset lainalaitteet. Sopikaa tuetut käyttöjärjestelmät, rekisteröintisäännöt ja yksityisyyden rajat.

Rakenna luettelo pysyvien tunnisteiden eikä pelkkien näyttönimien varaan. Hyödyllisiä kenttiä ovat omaisuustunniste, hallintatunniste, osoitettu käyttäjä, omistajuus, alusta, rekisteröintitapa, liiketoiminnallinen tarkoitus, rekisteröintipäivä, viimeisin yhteys ja käytöstä poiston tila. Kirjaa jaettujen laitteiden haltijat nimenomaisesti.

Täsmäytä MDM-luettelo riippumattomiin lähteisiin. Hankintatiedot paljastavat laitteet, joita ei koskaan rekisteröity. Identiteettien kirjautumistiedot ja sovellusten käyttölokit voivat paljastaa päätelaitteita, jotka puuttuvat hallinnasta. Päätelaitesuojauksen tiedot voivat paljastaa päällekkäisiä agentteja tai muualla hallittuja laitteita. Tarkista, mitä tunnisteita kukin lähde todella tarjoaa, ennen kuin yrität yhdistää niitä.

Luokittele poikkeamat sen sijaan, että jättäisit ne hiljaisesti pois:

• Soveltamisalassa ja rekisteröity: arvioi konfiguraatio ja tietojen tuoreus.
• Soveltamisalassa mutta hallitsematon: rekisteröi, rajoita pääsyä tai hyväksy rajattu poikkeus.
• Käytöstä poistettu mutta yhä aktiivinen: tutki ja mitätöi jäljellä oleva pääsy.
• Päällekkäinen tai uudelleenasennettu: täsmäytä tiedot menettämättä historiallista näyttöä.
• Soveltamisalan ulkopuolella: dokumentoi syy ja raja, joka estää asiaankuuluvan pääsyn.

Nimittäjällä on merkitystä. ”98 % vaatimustenmukaisia” rekisteröidyistä laitteista voi kätkeä merkittävän hallitsemattomien laitteiden joukon. Raportoi kattavuus erillään konfiguraation vaatimustenmukaisuudesta ja säilytä täsmäytyksen päivämäärä ja ratkaisemattomat tietueet.

Rakenna perustaso, jota voidaan testata

Päätelaitteiden perustason tulisi muuntaa riskipäätökset asetuksiksi ja varmennuskriteereiksi. Sen tulisi erottaa alustat ja omistusmallit sen sijaan, että teeskenneltäisiin jokaisen asetuksen toimivan kaikkialla.

Seuraava on käytännöllinen lähtökohta, ei yleispätevä lakisääteinen tai ISO:n edellyttämä tarkistuslista:

Määritä, mitä ”tuntematon” tarkoittaa. Päätelaitetta, joka ei ole raportoinut salauksen tilaa, ei ole todistettu salatuksi. Käsittele puuttuvaa tai vanhentunutta telemetriaa erillisenä tilana, jolle on selkeä toimintatapa, sen sijaan että muuttaisit sen hyväksytyksi.

Päivitysikkunoiden tulisi heijastaa haavoittuvuuden vakavuutta, altistumista, käytettävissä olevia lieventäviä toimia ja operatiivisia rajoitteita. Dokumentoi aktiivisesti hyödynnettyjen haavoittuvuuksien hätäkäsittely ja prosessi päivityksille, jotka rikkovat välttämättömiä sovelluksia. MDM:n käyttöönottoraportit auttavat selvittämään asennustilan; ne eivät yksinään kerro, onko ratkaisematon haavoittuvuusriski hyväksyttävä.

Erota sovellusten kohdalla jakelu ja hallinta. Hyväksytyn sovelluksen asentaminen ei estä käyttäjiä asentamasta vaihtoehtoja, ellei alusta ja konfiguraatio tue tällaista rajoitusta. Määritä, kuka saa hyväksyä ohjelmistoja, mikä edellyttää arviointia ja miten vanhentuneet tai kielletyt sovellukset poistetaan.

Jokainen perustason poikkeus tarvitsee omistajan, kohteena olevat laitteet, liiketoiminnallisen syyn, riskiarvion, korvaavat toimenpiteet, hyväksynnän ja vanhenemispäivän. Tukematon käyttöjärjestelmä, jolla on rajoittamaton pääsy arkaluonteisiin tietoihin, ei saa jäädä pysyvästi yleisen ”liiketoiminnan vaatimus” -merkinnän alle.

Ota konfiguraatio käyttöön sekoittamatta osoittamista onnistumiseen

Käytä pilottiryhmää, joka edustaa kutakin tärkeää alustaa, omistusmallia ja liiketoiminnan käyttötapausta. Testaa tavallinen työ, matkustaminen, toiminta ilman verkkoyhteyttä ja palautuminen, ei pelkästään onnistunutta rekisteröintiä ylläpitäjän työpöydällä.

Varmista ennen laajaa käyttöönottoa hallinnan edellytykset: ylläpitäjäroolit, rekisteröintioikeudet, tarvittavat varmenteet tai palvelutunnukset sekä niiden uusimisen omistajuus. Hallintapalvelu voi menettää tehonsa varmenteen vanhentuessa, vaikka sen politiikka-asiakirjat pysyvät ennallaan.

Seuraa konfiguraatiota erillisten tilojen kautta: kohdennettu, toimitettu, sovellettu, arvioitu ja voimassa. Jos alusta tarjoaa vähemmän vaiheita, dokumentoi rajoitus ja lisää turvallinen varmennustapa. Tarkasta ristiriitaiset profiilit, vanhentuneet agentit, tukemattomat asetukset ja käyttäjien toimet, jotka estävät valmistumisen.

Käytä vaiheittaista käyttöönottoa hyväksytyllä peruutus- tai palautuspolulla. Kirjaa perustason versio, kohderyhmät, pilotin tulokset, hyväksyntä ja käyttöönoton epäonnistumiset. Kuvakaappaus politiikkaeditorista todistaa aiotut asetukset; laiteraportit ja testit osoittavat, toimivatko asetukset.

Suojaa itse hallintataso. Käytä nimettyjä ylläpitäjätilejä, asianmukaista vahvaa todennusta, vähimpien oikeuksien rooleja ja lokitusta. Rajoita massapyyhinnän ja konfiguraatiota muuttavia oikeuksia. Tarkasta ylläpitäjät ja palvelutunnukset, koska hallintapalvelun vaarantuminen voi vaikuttaa moniin päätelaitteisiin kerralla.

Varmenna salaus ja palautus erikseen

Tarkista kannettavissa toteutettu tallennustilan suojaus, ei pelkästään ”ota salaus käyttöön” -politiikkaa. Ymmärrä puhelimissa ja tableteissa käyttöjärjestelmän salausmalli, lukitustilan toiminta ja hallinnan näkyvyys. Tallennetun tiedon salaus ja salattu verkkoliikenne ovat erillisiä väitteitä.

Päätä, mikä paikallinen tallennustila on katettu, sallitaanko siirrettävät tallennusvälineet ja miten liiketoiminnan tiedot voivat poistua hallituista sovelluksista. Suojattu järjestelmälevy ei automaattisesti suojaa vietyä tiedostoa salaamattomalla ulkoisella asemalla.

Palautusjärjestelyt edellyttävät omaa kontrollisuunnitteluaan. Määritä, missä palautusaineistoa säilytetään, kuka voi hakea sen, miten haku valtuutetaan ja kirjataan ja milloin vaihto tai korvaaminen on tarpeen. Älä sisällytä palautussalaisuuksia yleiseen auditointinäyttöön tai tukipalvelun tiketteihin.

Testaa palautus nimetyllä testipäätelaitteella hyväksyttyä menettelyä käyttäen. Säilytä valtuutus ja lopputulos, ei salaisuutta. Konsolin kenttä, joka osoittaa avaimen olemassaolon, ei todista, että valtuutettu henkilöstö pystyy palauttamaan laitteen tarvittaessa.

Verkkoliikenteen suojaus riippuu myös sovellusten ja palvelujen konfiguraatiosta. MDM voi jakaa varmenteita tai verkkoasetuksia, mutta se ei voi osoittaa, että jokainen sovellus käyttää asianmukaisesti konfiguroituja salattuja yhteyksiä. Laajempi elinkaari on kuvattu artikkelissa salaus ja avaintenhallinta.

Kytke laitteen tila pääsypäätöksiin

Vaatimustenmukaisuussignaalilla on rajallinen arvo, jos vaatimustenvastaiset päätelaitteet säilyttävät rajoittamattoman pääsyn. Kytke laitteen luottamus- tai vaatimustenmukaisuustiedot identiteettien ja sovellusten pääsynhallintaan, kun se on tuettua. Selvitä tarkasti, mitkä resurssit valvovat ehtoa ja mitkä pääsypolut ohittavat sen.

Testaa tarvittaessa selainpääsy, natiivisovellukset, etähallinta, vanhat todennustavat ja olemassa olevat istunnot. Hallitsematon selain voidaan estää, kun taas aiemmin valtuutettu asiakasohjelma jatkaa toimintaansa. Istuntojen mitätöinnin toiminta ja signaalien tuoreus edellyttävät nimenomaista testausta.

Käytä riskiperusteisia rajoituksia. Arkaluonteiset hallintajärjestelmät voivat edellyttää tiukempia päätelaite-ehtoja kuin vähäriskiset yhteistyöresurssit. Määritä hätäpääsy- ja palautusmenettelyt, jotta vikaantunut vaatimustenmukaisuuspalvelu ei johda dokumentoimattomiin pysyviin ohituksiin.

Laitteen lukituksen avaamisen todennus ei ole sama asia kuin sovelluksen todennus. Näytön lukitus suojaa valvomatonta päätelaitetta; monivaiheinen tunnistautuminen ja valtuutus suojaavat pääsyä resursseihin. MDM voi tukea konfiguraatiota, mutta identiteetintarjoajan ja sovellusten näytön on tuettava näitä erillisiä väitteitä.

Käsittele henkilökohtaiset laitteet, katoamiset ja työsuhteen päättymiset harkiten

Päätä henkilökohtaisten laitteiden osalta, onko hallinta koko laitetta koskevaa, työprofiilikohtaista, sovelluskohtaista vai ei lainkaan saatavilla. Kerro, mitä ylläpitäjät näkevät, mitä he voivat muuttaa, mitä liiketoiminnan tietoja kerätään ja mitä voidaan poistaa. Älä oleta, että sijainnin seuranta tai henkilökohtaisten sovellusten näkyvyys on tarpeen tai saatavilla.

Jos työntekijöiden laitetelemetria sisältää henkilötietoja, arvioi sovellettavat tietosuojavelvoitteet. Yleinen tietosuoja-asetus (GDPR) edellyttää oikeusperustetta ja asiaankuuluvien käsittelyperiaatteiden noudattamista; 32 artikla noudattaa riskiperusteista lähestymistapaa tietoturvaan eikä edellytä yleistä salausta kaikissa olosuhteissa. Työntekijän suostumusta ei pidä olettaa riittäväksi. Teetä valvonta- ja poistomenettelyille asianmukainen tietosuoja- ja työoikeudellinen arviointi.

Erota liiketoiminnan tietojen valikoiva poistaminen koko laitteen pyyhkimisestä. Varmista kunkin rekisteröintitavan tuettu toiminta ja kerro siitä ennen rekisteröintiä. Työprofiilin poistaminen voi jättää henkilökohtaiset tiedot koskemattomiksi, kun taas täydellisellä pyyhkimisellä on olennaisesti erilaiset seuraukset.

Kadonneen laitteen kohdalla reagoinnin tulisi tunnistaa päätelaite ja käyttäjä, arvioida altistuminen, rajoittaa pääsyä, mitätöidä asiaankuuluvat istunnot tai tunnistetiedot, antaa tuetut lukitus- tai pyyhintäkomennot ja kirjata tulokset. Etäpyyhintä riippuu yhteyksistä ja alustan ominaisuuksista. ”Komento jonossa” ei tarkoita ”tiedot poistettu”.

Työsuhteen päättymismenettelyjen tulisi kattaa sekä laitteen palauttaminen että pääsy tietoihin. Mitätöi pääsy riippumatta siitä, saadaanko laite takaisin. Poista työprofiilit tarvittaessa, säilytä säilytysvaatimusten alaiset tiedot ja poista luettelotiedot käytöstä vasta vaadittujen tarkistusten jälkeen. Testaa näitä prosesseja turvallisessa laajuudessa testitileillä ja -laitteilla.

Säilytä näyttö, joka tukee rajattua väitettä

Näyttöpaketin tulisi antaa tarkastajalle mahdollisuus rekonstruoida, mitä suojattiin tiettynä ajanjaksona. Säilytä päivätyt viennit, laitejoukkojen määrät, poikkeuspäätökset ja korjausmerkinnät. Sisällytä riittävästi asiayhteyttä, jotta tiettyyn ajankohtaan sidottu arviointi voidaan erottaa jatkuvan toiminnan näytöstä.

Hyödyllisiä tuotoksia ovat:

• Soveltamisalan ja luettelon täsmäytys, mukaan lukien ratkaisemattomat hallitsemattomat laitteet.
• Hyväksytyt perustasoversiot ja alustakohtaiset asetukset.
• Laitteiden tilaviennit, joista näkyvät tunnisteet, rekisteröinti, viimeisin yhteys ja voimassa oleva konfiguraatio.
• Poikkeusten hyväksynnät vanhenemispäivineen ja korvaavine toimenpiteineen.
• Käyttöönoton epäonnistumiset, korjaustiketit ja sulkemisen varmennus.
• Palautus-, pääsyn estämis-, laitteen katoamis- ja työsuhteen päättymistestien merkinnät.
• Määräaikaiset katselmointipäätökset ja osoitetut jatkotoimenpiteet.

Dokumentoi vientien suodattimet, keruuajankohta ja tilakenttien tulkinta. Suojaa viennit asianmukaisesti, koska ne voivat sisältää henkilötunnisteita tai arkaluonteisia infrastruktuuritietoja. Kuvakaappaukset voivat selittää konfiguraatiota, mutta haettavat viennit ovat yleensä hyödyllisempiä laitejoukon analysointiin.

Tee otanta riskien ja vikatilojen yli, ei pelkästään toimivista laitteista. Ota mukaan eri alustat, äskettäiset rekisteröinnit, pääkäyttäjät, vanhentuneet päätelaitteet ja hyväksytyt poikkeukset. Ajantasainen raportti ei voi rekonstruoida aiempaa katselmointijaksoa, ellei historiallisia tietoja ole säilytetty.

Määräaikaisten kattavuuskatselmointien tulisi sisältää uudet käyttöön otetut laitteet ja muuttuvat pääsymallit. Hyödyllisiä operatiivisia mittareita ovat rekisteröintikattavuus, arvioidun perustason vaatimustenmukaisuus, vanhentunut raportointi, vanhentuneet poikkeukset ja korjausten ikä. Määritä kunkin mittarin nimittäjä ja raja-arvo. Jatkuva kontrollien valvonta tarjoaa lisää taustaa signaalien erottamiseen tarkastetuista johtopäätöksistä.

Esimerkki: sekalaisen laitekannan katselmointi

Seuraavat luvut ja raja-arvot ovat havainnollistavia oletuksia, eivät toimialan vertailuarvoja.

Yritys tunnistaa 120 yrityksen kannettavaa ja 30 henkilökohtaista puhelinta, joilla on lupa käyttää työsähköpostia. Kannettavien perustaso edellyttää rekisteröintiä, salausta, tuettua käyttöjärjestelmää, näytön lukitusta ja onnistunutta arviointia seitsemän päivän sisällä. Henkilökohtaisilta puhelimilta edellytetään hallittua työprofiilia ja tuettua ohjelmistoa; koko laitteen hallinta on hyväksytyn yksityisyyden rajan ulkopuolella.

MDM-konsolissa on 116 kannettavaa. Niistä 108 täyttää perustason, neljä raportoi myöhässä olevia päivityksiä, kahdella on vanhentunut arviointi ja kaksi näyttää salausvirheitä. Loput neljä kannettavaa puuttuvat hallinnasta.

Pelkän konsolin tuloksen raportointi antaa 108/116 eli noin 93 %:n perustason vaatimustenmukaisuuden. Selvitettyyn kannettavien joukkoon suhteutettuna 108/120 eli 90 % on osoitettu täyttävän perustason. Rekisteröintikattavuus on noin 97 %. Nämä ovat eri mittareita, eikä mikään niistä todista henkilökohtaisten puhelinten kontrolleja.

Identiteettitiedot osoittavat, että kaksi hallitsematonta kannettavaa käytti arkaluonteista sovellusta. Tiimi rajoittaa pääsyä, selvittää omistajuuden ja rekisteröi laitteet. Kaksi muuta vahvistetaan käytöstä poistetuiksi; näyttö pääsyn mitätöinnistä ja hävittämisestä tukee niiden poistamista aktiivisesta laitejoukosta.

Puhelimien osalta kolmella käyttäjällä on sähköpostipääsy ilman vaadittua työprofiilia. Heidän pääsyään rajoitetaan, kunnes rekisteröinti tai hyväksytty vaihtoehto on valmis. Testipuhelin vahvistaa, että valikoiva poisto poistaa työprofiilin pyyhkimättä henkilökohtaista sisältöä.

Katselmointimerkintä säilyttää alkuperäisen laitejoukon, täsmäytyksessä tehdyt muutokset, epäonnistumiset, pääsyrajoitukset ja varmennetut korjaukset. Se ei korvaa alkuperäistä epäonnistunutta arviointia myöhemmällä siistillä kuvakaappauksella.

Helpota seuraavaa katselmointia

Yleiset virheet ovat operatiivisia: lasketaan vain rekisteröidyt päätelaitteet, luotetaan politiikan osoittamiseen, hyväksytään vanhentunut telemetria, jätetään poikkeukset auki ja pidetään etäkomentoja suoritettuina toimenpiteinä. Kuhunkin voidaan puuttua määritellyllä laitejoukolla, tilojen nimenomaisella käsittelyllä ja päivätyllä varmennuksella.

Secani voi järjestää tämän työn asiaankuuluvien järjestelmien, vaatimusten, vastuuhenkilöiden ja näytön ympärille. Lataa perustasoasiakirjat, päivätyt MDM-viennit ja testimerkinnät; kytke ne kontrolleihin tai päätöksiin, joita ne tukevat; ja muuta puuttuva näyttö tai ratkaisemattomat epäonnistumiset osoitetuiksi tehtäviksi. Säilytä ihmisen tekemä tarkastus, hyväksyntä ja lähdekonteksti olennaisille johtopäätöksille. MDM pysyy operatiivisena päätelaitteiden hallintatyökaluna; vaatimustenmukaisuuden työtila säilyttää toteutuksen kontekstin ja katselmointipäätökset.

Käytännön seuraava askel on valita yksi arkaluonteinen sovellus ja täsmäyttää jokainen siihen pääsevä päätelaite hallintatietoja vasten. Testaa yksi toimiva päätelaite, yksi hallitsematon päätelaite ja yksi vanhentunut päätelaite. Kirjaa pääsyn lopputulokset ja konfiguraationäyttö ja osoita sitten jokainen selittämätön poikkeama vastuuhenkilölle. Tämä pieni harjoitus testaa kattavuuden, täytäntöönpanon ja näytön yhdessä.