Periaatteet

Erilaisia turvallisuuteen liittyviä periaatteita ja hyviä käytäntöjä on useita. Ne läpäisevät useita tämänkin materiaalin alueita ja yhdessä ne auttavat muodostamaan kokonaisvaltaisen lähestymistavan turvallisten järjestelmien suunnitteluun, kehittämiseen ja käyttöönottoon.

Saltzer ja Schroeder -periaatteet

Vaikka tietojenkäsittely näyttää nykyään varsin toisenlaiselta kuin vuonna 1975, monet yleiset periaatteet ovat edelleen voimassa. Seuraavassa on Saltzerin ja Schroederin julkaisemia suunnitteluperiaatteita tuolta vuodelta. Sujuvuuden vuoksi tässä käytetään termiä turvatoimi tarkemman termin turvavalvontatoimenpide (security control) sijasta.

Mekanismin taloudellisuus (economy of mechanism): Turvatoimen tulisi olla niin yksinkertainen kuin mahdollista. Yksinkertaisuus auttaa ymmärtämään toimiiko mekanismi niin kuin on ajateltu. Lisäksi toteutus on yksinkertainen, jolloin luotettavuus ja toimiminen on helpompaa todentaa.

Turvalliset oletusarvot (fail-safe defaults): Turvamekanismien pitäisi sopia positiivisessa mielessä yhteen turvapolitiikan kanssa, eli hylätä kaikki muut kuin sallitut tavat toimia. Ei pitäisi rakentaa mekanismeja, jotka yrittävät määritellä ja estää haitallista toimintaa, sillä se on altis virheille. Haitallinen toiminta kehittää aina uusia muotoja. Useat nykyaikaiset mekanismit rikkovat tätä periaatetta, esimerkiksi virustorjunta ja tunkeutumisen havainnointi silloin kun ne perustuvat haitallisen toiminnan tunnusmerkkeihin.

Täydellinen tarkastus (complete mediation): Kaikki järjestelmän olioihin kohdistuvat toiminnot tulee tarkastaa sen varmistamiseksi, että ne ovat turvapolitiikan mukaisia. Tämä tarkoittaa esimerkiksi sen tarkastamista, että toimijalla on oikeudet suorittaa aikomansa toiminto ja että hänet on tunnistettu ja todennettu asianmukaisesti.

Avoin rakenne (open design): Turvatoimen turvallisuuden ei tulisi perustua siihen, että sen toimintaperiaate pysyy salaisena. Usein turvallisuus edellyttää, että turvatoimia voidaan tutkia, niiden virheet korjata ja oikeellisuus todeta, ilman että samalla mitätöidään turvatoimien turvallisuus. Vastakkainen näkemys, piilotteluun perustuva turvallisuus (security by obscurity), on haavoittuvampi, koska se rajoittaa turvatoimien tarkastamista, eikä poista sisäpiiristä tulevia uhkia.

Oikeuksien erottaminen (separation of privilege): Turvamekanismit, jotka edellyttävät usean toimijan valtuutusta ennen jotain operaatiota (esim. pankkialalla), ovat luotettavampia kuin sellaiset, joissa yhden tahon antama valtuutus riittää. Luonnollisesti usean osallistujan vaatiminen saattaa haitata saatavuutta.

Vähimpien oikeuksien periaate (least privilege): Toimijoiden suorittamat operaatiot tulisi hoitaa mahdollisimman vähin oikeuksin, esim. jos täytyy vain lukea jokin tieto, ei pitäisi antaa oikeuksia myös tiedon kirjoittamiseen ja poistamiseen. Vähimpien oikeuksien periaate varmistaa, että esim. virheelliset ohjelmat tekevät vahinkoa mahdollisimman vähän.

Vähimpien yhteisten mekanismien periaate (least common mechanism): On suositeltavaa minimoida resurssien ja mekanismien jakaminen eri osapuolten välillä. Periaate on tarpeen esimerkiksi monen käyttäjän järjestelmissä, joissa jaettu muisti, levytila tai prosessori voivat mahdollistaa luottamuksellisen tiedon vuotamisen käyttäjältä toiselle.

Psykologinen hyväksyttävyys: Turvatoimien tulisi olla luonnostaan käytettäviä, jotta käyttäjät automaattisesti toimisivat niiden mukaan. Kun käyttäjän mielikuvamalli turvallisuustavoitteista vastaa turvallisuuteen käytettävää mekanismia tai turvatoimea, virheiden todennäköisyys vähenee.

NIST-periaatteet ja yleiskaavio

National Institute of Standards and Technology (NIST) määrittelee turvaperiaatteita järjestelmien suunnitteluun. Ne on järjestetty laajoihin ryhmiin, jotka ovat Turvallisuusarkkitehtuuri ja -suunnittelu, joka sisältää organisaatiot, rakenteet ja käyttöliittymät; Turvallisuuskyvykkyydet ja käyttäytyminen (security capability and intrinsic behaviours) eli se mitä turvallisuus oikeastaan on; ja Elinkaariturvallisuus, joka liittyy prosesseihin ja hallintaan.

Osa NIST-periaatteista pohjaa suoraan Saltzer ja Schroeder -periaatteisiin. Uudemmat periaatteet liittyvät nykyisten järjestelmien monimutkaisuuteen ja painottavat esim. moduulirakennetta, kerroksellisuutta, osastoittain järjestettyjä riippuvuuksia ja turvallisuuden kehittämistä muun systeemin päivitysten mukana. Periaatteissa huomioidaan myös, että turvallisessakaan järjestelmässä kaikki osat eivät ole yhtä turvallisia. Tällöin turvattomammat osat hyötyvät hierarkkisesta luottamusrakenteesta, jossa joidenkin osien turvallisuushäiriöt eivät kaada koko järjestelmän turvallisuutta. Inverse modification threshold -periaatteen mukaan turvallisuudelle kriittisimpien osien tulisi olla kaikkein suojatuimpia valtuuttamattomia muutoksia ja peukalointia vastaan.

NIST-periaatteet huomioivat myös, että modernit järjestelmät ovat kytkettyjä toisiinsa. Verkoissa tulisi käyttää luotettuja kommunikointikanavia. Niiden pitäisi toteuttaa secure distributed composition -periaate, joka tarkoittaa, että kun yhdistetään kaksi saman politiikan toteuttavaa järjestelmää, niiden tulisi yhdistettynäkin vähintään toteuttaa sama politiikka. Self-reliant trustworthiness -periaate puolestaan toteaa, että turvallisen järjestelmän tulisi säilyttää turvallisuutensa, vaikka yhteys muihin järjestelmän osiin katkeaisi.

NIST-periaatteet määrittävät, minkälaiset mekanismit ovat hyväksyttäviä oikeissa, käytössä olevissa järjestelmissä. Erityisesti turvatoimien tulisi olla kustannustehokkaita, suorituskykyisiä, käytettäviä ja käyttäjien hyväksyttävissä. Näillä ominaisuuksilla haetaan sitä, että turvallisuus tukee järjestelmien varsinaista toimintaa eikä ole yksinään tavoitteena.

Periaatteiden lisäksi NIST hahmottelee kolme turvallisuusarkkitehtuurin strategiaa. Viitemonitori on abstrakti turvatoimi, joka toteuttaa systeemin turvaominaisuudet. Kerroksellinen turvallisuus kuvaa arkkitehtuuria, joka rakentuu useista päällekkäisistä turvatoimista (terminä myös: syvyyspuolustus, defence in depth). Eristys on strategia, jossa eri komponentit ovat fyysisesti tai loogisesti erotettu häiriöiden tai tietovuotojen minimoimiseksi.

Sekä NIST että Saltzer ja Schroeder korostavat, että arkkitehtuurien ja turvatoimien periaatteet ovat vain ohjeellisia, ja niitä sovellettaessa tarvitaan myös osaamista ongelmista, joihin niitä sovelletaan. Poikkeaminen periaatteista ei automaattisesti johda ongelmiin, mutta tällaiset poikkeamat on tunnistettava sen varmistamiseksi, että mahdollisia ongelmia voidaan lieventää asianmukaisesti.

Edellä on käsitelty kahta turvaperiaatteiden kokoelmaa. NIST:n kokoelma on laadittu useiden muiden periaateluetteloiden pohjalta, ja se ottaa huomioon ilmiöitä, joita Saltzer ja Schroeder eivät olleet vielä nähneet 1970-luvulla. Seuraavassa periaatteita on jäsennetty vielä eri tavalla käsitekartan muotoon. Lähteinä on käytetty paitsi NIST-kokoelmaa, myös dokumenttia Cybersecurity Curricula 2017 ja kahta kirjaa: Rick E. Smith: Elementary information security (2012) ja Paul van Oorschot: Computer security and the internet (2020). Näistä kaikista on päätelty 10 korkeimman tason periaatetta, jotka on merkitty kartassa oranssilla värillä. Muita periaatteita on 30. Kokonaisuus on jaettu seitsemään luokkaan, joiden tarkoituksena on tehdä asioista helpompia ymmärtää ja muistaa (merkitty vaalean vihreällä). Suurimmassakin luokassa on vain 7 periaatetta.

Käsitekartta suunnitteluperiaatteista

Huomautus käsitekartan saavutettavuudesta.

Useita korkeimman tason periaatteita on koottu luokkaan Sovella mielessäsi. Nämä ajattelumallit täytyy oppia ja omaksua osaksi luontaista käyttäytymistä, mutta on silti hyvä pystyä tunnistamaan ne nimillä. Yksi niistä koostuu kolmesta näkökulmasta, jotka edellyttävät keskinäistä tasapainoa: riskit, kustannukset ja politiikka. Tämän yhdistäminen hyökkäävään ajatteluun johtaa periaatteeseen, että suojausten pitää olla vahvempia kuin hyökkääjä. Tämä on ilmeistä, mutta se on muistettava erityisesti valittaessa kryptografiaa.

Organisoi työsi sisältää kaksi korkean tason periaatetta, jotka käsittelevät suunniteltavan järjestelmän elinkaarta. Tietyssä mielessä niille voitaisiin käyttää nimiä “start” ja “restart”. Myös riski-kustannus-politiikka -periaate on nähtävissä hallinnollisesta näkökulmasta ja siksi siihen on lisätty katkoviiva.

Luokkana Sovella mielessäsi on selvästi korkeimmalla tasolla ja sitä lähellä on organisoinnin luokka yhdessä Minimoinnin kanssa. Jälkimmäisessä periaatteet nimeävät asioita, joita suunnittelussa pitäisi minimoida. Minimointi pitää kuitenkin ymmärtää sidottuna rajoitteisiin, joita kaikki muut periaatteet asettavat. Tähän luokkaan kuuluu yksi korkeimman tason periaate: Minimoi hyökkäyspinta. Kaikki muut minimoinnit voidaan nähdä tämän toteutumisena. Jopa käyttäjälle koituvien yllätysten minimointi vähentää tilanteita, joissa hyökkäykset ovat mahdollisia. Minimoi yhteisten välineiden määrä vastaa Saltzerilta ja Schroederiltä lähtöisin olevaa periaatetta “least common mechanism”. Sen motiivina on, että tällainen minimointi vähentää myös mahdollisuuksia tahattomaan viestintään tai häiriöihin prosessien tai käyttäjien välillä. Sanaa väline käytetään tässä, koska se on yleisempi kuin mekanismi ja voi helpommin tuoda mieleen koodin lisäksi myös ohjelmien muuttujat ja parametrit sekä tiedostot.

Neljäs luokka koskee järjestelmän arkkitehtuuria: Käytä rakenteita. Siitä löytyy kaksi korkean tason periaatetta. Ne voitaisiin karkeasti merkitä syvyydeksi ja leveydeksi. Kahdessa periaatteessa mainitaan kerrokset, mutta ne ovat erillisiä rakenteellisia näkökohtia. Sama koskee moduuleja ja eristystä.

Ainoa jäljellä oleva korkean tason periaate kuuluu luokkaan Salli vähemmän. Tämä luokka edustaa toiminnan rajoituksia ja siinä on kyse enimmäkseen hyvin erilaisista asioista kuin minimointiluokassa. Vähemmän salliminen koskee pääasiassa suunnitteilla olevan järjestelmän resurssien käyttöä, ja ne johtuvat korkean tason periaatteesta Tarkista ennen luottamista. Tästä periaatteesta on useita versioita, jotka täsmentävät alun perin Saltzerilta ja Schroederilta peräisin olevaa periaatetta “complete mediation”. Myös muilla tämän luokan periaatteilla on useita ilmaisuja. Kahdessa esiintyy termi oikeudet ja näissä käytetään englanniksi myös termiä privileges. Vaikka nimi on samankaltainen, merkitys eroaa. Kitsaan tai vastahakoisen allokoinnin periaate on hyödyllinen palvelunestotilanteiden välttämisessä. Sitä voisi pitää myös minimointitavoitteena, jolloin se pitäisi muotoilla esimerkiksi “Minimoi resurssien allokointi-into”.

Kartassa on kaksi luokkaa ilman oransseja laatikoita: Tee enemmän ja Sisällytä erityisominaisuuksia. Molemmat luokat suosittelevat lisäämään joitain ominaisuuksia, jotka palvelevat turvallisuutta ja ovat melko kaukana järjestelmän tavallisesta toiminnasta. Kumpikin luokka perustuu vain yhteen lähteeseen: Sisällytä erityisominaisuuksia tulee Cybersecurity Curricula 2017:stä, Tee enemmän van Oorschotilta. Erityisominaisuudet - paitsi tunnistaminen - voivat monimutkaistaa toimintaa melko paljon, mutta kaikki ovat motivoituja ja siksi hyvä muistaa. Kaksi “enemmän tehtävää” asiaa ovat täysin ylimääräisiä tavallisten toimintojen ulkopuolella mutta välttämättömiä tulevaisuuden kannalta (“siivoaminen” ja “lokitus”). Jäljelle jäävä ristiintarkastus on ylimääräistä puuhaa sisäpuolella eli osana normaalia toimintaa. Siinä yhdistyvät van Oorschotin kaksi melko yksityiskohtaista periaatetta “Riippumaton vahvistus” ja “Pyyntö-vastaus -rakenteen eheys”. Ensimmäinen niistä täydentää Tarkista ennen luottamista -periaatetta ulottamalla sen vähemmän luotettuihin tilanteisiin, joissa on syytä epäilyihin, ja jälkimmäinen muistuttaa, että yksi tällainen tapaus on, kun sovellus saa vastauksen pyyntöönsä. Ristiintarkastus on tehtävä sen varmistamiseksi, että vastaus vastaa pyyntöä. Nämä asiat ovat tuttuja niille, jotka jo suunnittelevat protokollia, mutta huomautus muille voi olla hyödyllinen.

Lopuksi on syytä muistuttaa, että tässä on käsitelty turvallisten järjestelmien luomista eikä niiden turvallista käyttämistä. Asiat ovat tässä myös abstraktimpia kuin turvamekanismit tai hyvät turvallisuustavat, sellaiset kuin:

  • Päivitykset
  • Varmuuskopiot
  • Virustorjunta
  • Palomuurit
  • Monitekijäautentikointi
  • Hyvät salasanat
  • “Selaushygienia”
  • Tietoisuuskoulutus
  • Turvallinen alustus
  • Salaus

tai edes politiikan luominen ja sen noudattaminen. Monet näistä ovat kuitenkin melko suoria seurauksia suunnitteluperiaatteista. Ja tietysti järjestelmän suunnittelijan ja toteuttajan tuotantoympäristön ja työtapojen tulee olla turvallisia—juuri tässä mainittujen käytäntöjen avulla.

Valitse yksi tai useampi vaihtoehto.

Mitä hyötyä on suunnitteluperiaatteista?
Monet suunnitteluperiaatteet pyrkivät yksinkertaistamaan järjestelmää eri tavoin. Miksi tämä on tärkeää turvallisuuden kannalta?

Piilevät suunnitteluehdot (syventävä)

Yhä useammat kyberfyysiset järjestelmät on kytketty muihin järjestelmiin ja Internetiin. Tällaiset laajamittaiset yhteydet ovat luonnostaan monimutkaisia ja joidenkin kyberfyysisten järjestelmien turvakriittisyys nostaa tärkeäksi vielä muitakin periaatteita. Yksi periaate muistuttaa piilevistä suunnitteluehdoista, jotka kyberturvallisuudessa johtuvat aiemmista päätöksistä, joita järjestelmää rakennettaessa ja muokattaessa on tehty. Ne jäävät usein piiloon tai huomioimatta ja tulevat esiin vain, kun jotkin tapahtumat tai asetukset sopivat yhteen, mahdollisesti ikävällä tavalla, esimerkiksi paljastaen tietoturva-aukon, kun järjestelmiä liitetään toisiinsa. Aiemmin piilossa ollut ongelma saattaa nykyään ilmetä tietoturvan lisäksi kyberturvallisuuden fyysisellä puolella, esimerkiksi safety-ongelmana. Turvallisuuden integrointi suunnitteluvaiheessa ei aina ole mahdollista. Kun vanhoja järjestelmiä yhdistetään uusiin verkkoympäristöihin, täytyy siis kiinnittää huomiota piileviin suunnitteluehtoihin yrittää lieventää niiden vaikutuksia.

Varotoimiperiaate (syventävä)

Osallistava datatalous johtaa monenlaisiin tuotteisiin ja palveluihin, joihin liittyy myös yhä enemmän huolta yksityisyydestä ja mahdollisesta tietojen väärinkäytöstä. Tällöin tulee ajankohtaiseksi varotoimiperiaate, joka tarkoittaa mahdollisten haitallisten vaikutusten arvioimista ennen kuin teknologia tulee laajamittaiseen käyttöön. Suunnittelijoiden tulee jatkuvasti arvioida valintojensa turvallisuus- ja yksityisyysvaikutuksia ja ulottaa analyysi järjestelmien koko elinkaareen. Tämä koskee kaikenlaisia laajasti verkottuneita järjestelmiä ja infrastruktuureja, joiden varassa yhteiskunta yhä enemmän toimii. Tekoälyn kehityksestä ja sen sääntelystä 2020-luvulla kiihtynyt (ja mm. EU:n AI Actiin johtanut) keskustelu on tästä hyvä esimerkki. Järjestelmillä on taipumus pitkän elinkaaren aikana hitaasti muuntua siten, että niistä tulee käyttötavoiltaan tai -tarkoitukseltaan erilaisia kuin alkuperäisestä (termi tälle on Function creep). Tällaisen vaikutuksia koko yhteiskuntaan tulisi myös arvioida. Esimerkiksi liikenteen sujuvuutta ja turvallisuutta parantava kameravalvonta voisi vähitellen muuttua ihmisten liikkeiden valvonnaksi.

Palautusta lähetetään...