Tietoturvallinen ohjelma (2-A)

Tietojenkäsittelyn turvallisuus -seminaari? käsitteli syksyllä 2003 tietoturvallista ohjelmointia pääosin Graffin ja van Wykin kirjan [ GrVW03? ] perusteella. LUE seminaarin raportista luvut 3-8. Näistä luvut 4, 6 ja 8 ovat käytännön esimerkkejä, luvut 1, 2 ja 9 tulevat luettaviksi B-osassa? .

Kirja perustuu tekijöiden kokemuksiin ohjelmistotyön eri vaiheista. He erottelevat turvallisuuden kannalta seuraavat tasot tai vaiheet arkkitehtuuri -- suunnittelu (design) -- toteutus (implementointi) -- testaus,

ja puolustavat lisäksi näkemystä, että sovellusohjelman turvallisuus on erittäin tiukasti kytköksissä ohjelman käyttöympäristöön: "turvallisuus on jokaisen asia". He jaottelevat ympäristöä kerroksiksi: sovellusohjelman alapuolella on käyttöjärjestelmä ja sen alla verkkoyhteydet. Näiden alla tai oikeastaan kaiken ympärillä on pitkälti ihmisen toimista koostuva kääre, jota kutsutaan käyttöturvallisuudeksi. Se koostuu kaikenlaisista ylläpidon toimista ohjelmien asentamisesta varmuuskopiointiin.

On ilmeistä, että ohjelman turvalliseksi tekemiseen uhrattu aika voi mennä hukkaan turvattomassa ympäristössä, mutta voiko ohjelmoija mitenkään vaikuttaa jälkimmäiseen? Se voi olla mahdollista esim. saman yrityksen puitteissa, mutta tuskin "irrallisten" ohjelmistotuotteiden, varsinkaan "hyllyohjelmien" tapauksessa. Miten ohjelmoija voi varautua arvaamattomiin tunkeutumistapoihin, jollaisia hyökkääjä saattaa etsiä sovellusohjelman alapuolelta tai ympäriltä ja siten erityisesti ohittaa sovellukseen rakennetun autentikoinnin? Seminaarissa vastaus oli, että tämä aihe on tärkeä, mutta ei kuulu ohjelmoijan vastuulle (ks. tietoverkon turvaaminen? ).

Turva-arkkitehtuurilla tarkoitetaan sellaisia korkean tason suunnitteluperiaatteita ja -päätöksiä, joissa otetaan huomioon yhden järjestelmä- tai ohjelmistoarkkitehtuurin lisäksi ympäröivät elementit. Sellainen soveltuu käytettäväksi verkko-, järjestelmä- ja ohjelmistosuunnittelun eri tasoilla. Turva-arkkitehtuuri ei silti sisällä turvapolitiikasta ja -käytännöistä eikä edes turvastandardeista päättämistä, vaan tämä tehdään erillään ylemmällä tasolla.

Turva-arkkitehtuuri eroaa sitä seuraavasta suunnittelun vaiheesta, joka kohdistuu suoraan tekeillä olevaan ohjelmaan tai ohjelmistoon. Turva-arkkitehtuuria päätettäessä otetaan kantaa varsin yleispäteviin periaatteisiin, joita on harvoin syytä kyseenalaistaa tai valita toisin: Kirjassa ja raportissa (luku 3 ja 4) on 30 kohdan luettelo, josta tähän on otettu malliksi muutama:

  • riittävä turvallisuus riittää, mutta se kannattaa ottaa huomioon alusta asti;
  • kerrospuolustus -- kokonaisuudelle;
  • vakiintuneet tekniikat , silti hyllyohjelmistojen välttäminen, ja kuitenkaan kaikkea ei tarvitse eikä pidä tehdä itse;
  • "lahoa kauniisti (degrade gracefully) ja kaadu turvallisesti (fail safely)";
  • vähimpien oikeuksien periaate + turvalliset oletusarvot ja -toiminnat;
  • yksinkertainen on kaunista;
  • ei liikaa kiusaa käyttäjille.

Tämä periaateluettelo voidaan nähdä sovelluksena ja hienonnuksena Saltzerin ja Schroederin vanhoista periaatteista . Ne ilmenevät myös BSI -hankkeen 12 ohjelmointiperiaattessa, jotka ovat: Principle of

complete mediation   defense in depth
economy of mechanism   failing securely
least common mechanism   least privilege
never assuming that your secrets are safe   pomoting privacy
psychological acceptability   reluctance to trust
securing the weakest link   separation of privilege

Tietoturvalliseen suunnitteluun kirja liittää kuusi vaihetta (seminaarirap. §5):

  1. Arvioi kohdeympäristön riskit ja uhat: esimerkiksi kysymysluetteloiden avulla (myös em. arkkitehtuuriluettelon alussa kehotettiin tekemään kysymyksiä -- periaate on aika yleinen, filosofiassa asti).
  2. Tee suunnitelma riskien toteutumisen varalle. Tämä koskee enemmän tietojärjestelmien kuin hyllyohjelmistojen tekemistä.
  3. Luo mielikuva ohjelman toiminnasta.
  4. Päätä korkean tason toiminnallisuus. Esimerkiksi palvelin voi olla tilaton tai tilallinen.
  5. Valitse tekniikat, joilla vaatimukset toteutetaan. Tässä on pidettävä kustannus-hyöty -näkökulma mukana -- eli tarvitaan riskianalyysin tuloksia.
  6. Ratkaise tulevan käytön turvallisuutta koskevia asioita -- sellaisia kuin tietokantojen varmistus, varmistusten suojaus ja turva- ja muiden päivitysten toteutus.

Minkään edellä sanotun ei pitäisi olla kovin uutta esitietokurssien valossa eli jos tuntee ohjelmointia ja tietoturvan yleisiä prosesseja. Luetteloiden käyttökelpoisuutta edistää, kun pystyy mieltämään, miten ne muodostuvat yleisemmistä periaatteista.

Toteutuksesta ja testauksesta on ollut puhetta jo esitietona olevassa tekstissä? ja seminaariraportissa on lisää (toteutuksesta luku 7, testauksesta luku 9 ja jossain määrin luku 2). Toteutuksesta on esillä myös melko tiukka sääntökokoelma? .

-- JukkaKoskinen?

SivuTiedotLaajennettu edit

Vaativuus Perus
Valmius Valmisteilla
Tyyppi Ydin
Luokitus Uhkat
Mitä Luottamuksellisuus
Miltä Ihmisetön uhka
Missä Organisaatio
Kuka Tite-ammattilainen
Milloin Ennakolta
Miksi Hyvä tapa
Print version |  PDF  | History: r2 < r1 | 
Topic revision: r2 - 26 Sep 2010 - 11:10:37 - MarkoHelenius
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback