next up previous contents
Next: 4 Fri programvare Up: Skolelinux-prosjektet Previous: 2 Forventningene til Skolelinux   Contents

Subsections


3 Personvern og datasikkerhet

1 Innledning

Hensikten med dette kapittel om Personvern og Datasikkerhet er å vise at det på nåværende tidspunkt ikke er vesentlig sikkerhetsmessig fare forbundet med å utprøve Skolelinux. Det er i noen grad mulig, men slett ikke nødvendig, å tiltro systemet med sensitive data. Her skal vises at prosjektet er klar over de fallgruber som finnes på veien til sikre, allment utbredte datasystemer; at arkitekturen til Skolelinux på beste vis imøtegår de umiddelbare behov, og derutover legger til rette for at det ikke skal finnes noen tekniske begrensninger for den enkelte kommune i forhold til å integrere Skolelinux i et stabs- og kommunenett, den dag det finnes tilstrekkelig kompetanse i kommunene til å behandle sensitive data i slike nettverk.

Det sies at sikkerhet er 20 % teknologi og 80 % administrasjon. Innenfor IT-bransjen fokuseres det naturlig nok nesten utelukkende på de 20 % teknologi. Problemet med de 20 % er tilnærmet borte i Skolelinux, dvs. i den grad det lar seg praktisk gjøre. Vi sitter da igjen med 80 % administrasjon for å gjøre Skolelinux til et sikkert system.

La det være helt klart, at arbeidet med å sikre systemer er betraktelig mer tidkrevende enn å tilrettelegge funksjoner. Gitt slike gjennomtenkte systemer som Skolelinux, er det en smal sak legge til nye lekre tilleggstjenester, mens arbeidet med å sikre at systemet fungerer hensiktsmessig er en kontinuerlig prosess. Et personlig overslag sier at det tar fem - 5 - ganger så lang tid og sikre seg at en tjeneste fungerer hensiktsmessig[*], enn det tar å få tjenesten til å fungere.

Den viktigste umiddelbare oppgaven er å få oversikt over gjeldende lov på dette området.

Elementer som inngår i arbeidet med å gjøre Skolelinux til system, som fungerer tilfredsstillende og hensiktsmessig er:

Såfremt man har et grunnleggende sikkert oppbygget system, er det mulig å tilby sikre tjenester basert på det underliggende system. Slike tjenester kan være:

2 Ansvar

Datasikkerhet er tilfredsstillende skjematisk viten og planlegging av EDB-anlegg i forhold til forhåndsbestemte målsetninger. Personvernet er tradisjonelt sammenknyttet med datasikkerhet, og disse to sees gjerne i sammenheng.

Det er lett å se at personvern og datasikkerhet kan ses på hver for seg, eller samlet som to sider av samme sak. På den ene siden handler datasikkerhet om personvern der brukere skal kunne beskyttes mot uautorisert innsyn og overvåkning. På den andre siden handler datasikkerhet om påliteligheten til tjenester og programmer i en bruks-situasjon. Her kan nevnes identifisering og autentisering, autorisasjon og tilgangskontroll, og utbredelse av fullmakter mellom systemer og brukere. Videre handler det om sikker kommunikasjon, kryptering, rutiner for sikkerhet, og administrasjon.

Det er ikke sannsynlig at datasikkerhet i slike systemer vil være så enkelt, at det praktiske ansvaret kan overlates til sluttbrukerne på mange år. Det trenger derimot ikke være lang tid til at IKT-ansvarlige kan tiltros dette arbeidet. I den grad den enkelte kommune besitter nødvendig kompetanse ligger de nødvendige verktøy ferdig tilrettelagt i Skolelinux per dags dato.

Personopplysningsloven http://www.lovdata.no/all/nl-20000414-031.html pålegger i paragraf 2-3 ansvaret for å sikre data slik:

Den som har den daglige ledelsen av virksomheten som den behandlingsmessige driver, har ansvar for at bestemmelsene i dette kapittelet følges.
Det kan ikke forventes at skolene, representert ved rektor, har tilstrekkelig kunnskap til å kunne vurdere EDB-anleggene og utarbeide adekvate rutiner. Det vil derfor være hensiktsmessig at forslag til oppsett og bruk av de enkelte Skolelinux-systemer, samt konkrete forslag til retningslinjer og utføring av kontroller utarbeides av prosjektet.

DatatilsynetDatatilsynet http://www.datatilsynet.no/ gir retningslinjer for utarbeidelse av dette materiale, men har ikke formell kompetanse til å utføre faktiske kontroller. Sistnevnte arbeide er pålagt Justervesenet http://www.justervesenet.no/na/inf_sikkerhet/Startsidenog utføres i henhold til den internasjonale standard BS7799 http://www.justervesenet.no/na/inf_sikkerhet/EA-G.htm. Det er et omstendelig arbeide og lar seg ikke umiddelbart anvende på Skolelinux. Den enkelte skole kan søke om sertifisering av sine egne anlegg.

3 Relevant dokumentasjon

Det er Personopplysningsloven som hovedsakelig styrer kravene til sikring av data. Loven er opprinnelig utarbeidet for sikring av persondata, men det viser seg at loven fungerer for sikring av generell elektronisk lagret informasjon. Datatilsynet har skrevet retningslinjer og kommentarer til loven. Disse dokumenter gjelder som referansemateriale for drift av EDB-anlegg i Norge. Justervesenet er pålagt det betraktelig mye vanskeligere arbeidet med å gjennomgå konkrete anlegg og eventuelt sertifisere dem. Slik sett kan vi meget grovt si at Justervesenet skal sikre de 20 % teknologi, mens Datatilsynets retningslinjer gjelder for de resterende 80 % med administrasjon. Justervesenets arbeide er ikke kommet tilstrekkelig langt til at det har praktisk betydning for prosjektet per i dag.

Det må bekreftes fra offisielt hold, at disse antagelser er korrekte. Hvis det finnes flere offisielle krav, må de bringes til vår oppmerksomhet.

Listen over relevant dokumentasjon er:

Det må bekreftes, at denne listen er uttømmende. Dette fordrer antageligvis advokatbistand. Dette arbeidet antas å ta 10 timer, men kan selvfølgelig også ordnes på en time med en bekreftelse fra f.eks. Datatilsynet. Skal det inn møtevirksomhet og advokatbistand kan dette fort ta både en og to uker.

4 Datatilsynets krav til personvern

Skolelinux passer godt til behandling av personopplysninger innenfor skolevesenet, men det forutsetter at anleggene installeres og brukes i henhold til datatilsynets retningslinjer.

Utgangspunkt for vurdering av hvordan personopplysninger skal behandles må foretas av ledelsen i den enkelte bedrift, dvs. skole. Skolelinux, slik det foreligger er et system til bruk i elev-nettet. Elevnettet tenkes fysisk atskilt fra skolestaben sitt nettverk. I utgangspunktet krever ikke Skolelinux at det lagres annen sensitiv informasjon om den enkelte elev enn deres passord.

I den grad man ønsker å ta i bruk Skolelinux også for staben gjelder det at løsningene her hovedsaklig består av driftsrutiner og av opplæring av staben. Systemet er teknologisk sikkert, såfremt det vedlikeholdes korrekt, og passer derfor godt til bruk også i stabsnettet, men det må nødvendigvis være tale om en installasjon nummer 2.

1 Driftsmessige personopplysninger

For å drive et Skolelinuxsystem behøves ikke annen sensitiv personopplysning om den enkelte bruker enn deres navn og passord. Der er følgelig ikke nødvendig med ytterligere bearbeidelse av systemet for å sikre driftsmessige personopplysninger.

2 Administrative personopplysninger

Det kan ikke umiddelbart lagres administrative opplysninger, som er sensitive, direkte på en Skolelinux-tjener. Administrative opplysninger, som telefonnummer og adresse, vil nok kunne figurere, men under kontrollerte omstendigheter. Grunnen til at det ikke kan lagres slike opplysninger er ikke av en direkte teknisk eller systematisk karakter, men beror på et påbud fra Datatilsynet om at sensitive personopplysninger skal lagres bak enda en brannmur - idet man forestiller seg brannmurene plassert lineært i forhold til hverandre. Slike opplysninger kan altså ikke lagres innenfor et segment av den sfære en Skolelinux-tjener i elev-nettet umiddelbart har tilgang til.

Skolelinux egner seg godt for lagring av administrative opplysninger innenfor en sone. En Skolelinux-tjener kan segmenteres, dvs. deles opp i flere virtuelle maskiner. Slik kan et Skolelinux-system i en kommune f.eks. segmenteres i en avdeling for Skatteetaten, en for trygdekontoret og en for skoleadministrasjonen. Kun betrodde personer vil være i stand til å flytte data mellom disse segmenter. Det kan tom. lages avsondrede virtuelle nettverk, som ikke har kontakt med omverdenen. Dette tilhører fase fire av prosjektet, og det vises her kun til muligheten av dette, for å gjøre oppmerksom på at utviklerne er klar over problematikken omkring lagring av slike opplysninger, samt at arkitekturen leder henimot en slik bruk av anlegget.

Det skal nevnes at det er tenkelig og ønskelig at man enkelt og sikkert skal kunne opprette midlertidige tunneler inn i de indre soner i f.eks. stabsnettet og hente eller bringe sensitiv informasjon. Det vil foregå under kontrollerte former. Nærmere rutiner for dette vil bli utarbeidet med Datatilsynet som rådgiver. Dette arbeidet vil innebære både tekniske løsninger og driftsrutiner.

1 Timeanslag

3 Faglige personopplysninger (oppgaver, prøver, karakterer)

Faglige personopplysninger vil i utgangspunktet kunne lagres i en segmentert del av systemet, dvs. en virtuell tjener (som f.eks. User-Mode-Linux) eller lignende. Segmentet vil kunne åpnes og stenges efter behov. Sålenge slike segmenter ikke er i bruk, kan de ligge i systemet i form av krypterte filsystemer[*]. Hensikten med denne lagringen bør være mellomlagring, dvs. at en prøve avholdes og læreren skriver på noen kommentarer for så å overføre data til et stabsnett.

Datatilsynet sier at dersom det lagres sensitive personopplysninger, så skal dette foregå i en «indre zone», det impliserer nødvendigvis en annen brannvegg eller ruter - dvs. en fysisk adskilt maskin.

Skolelinux utviser allikevel en styrke innenfor lagring av sensitive data. Ved hjelp av teknologien med virtuelle tjenere, kan f.eks. flere klasser samtidig avholde eksamener uten å ha tilgang til samme system.

5 Applikasjonssikkerhet - 20 % teknologi

Det antas å finnes sikkerhetshull i all programvare. Fri programvare er svært mye brukt på Internett, og det oppdages stadige sikkerhetshull. Applikasjonssikkerhet er nesten utelukkende den form for sikkerhet som til stadighet er fremme i media, og da gjerne under sensasjonstitler som «Nytt sikkerhetshull oppdaget av 16-årig hacker».

Danske forbrukermyndigheter skriver følgende:

«Med tilstrekkelig antall øyne er alle feil banale»

Det er Forbrugerinformationens vurdering, at programmer med åpen kildekode som hovedregel er minst lige sikre og stabile som programmer basert på lukket kildekode.
Koderevisjon er en forutsetning for at hull kan oppdages. For å oppdage sikkerhetshull må kildekoden til programmene revideres. Dette sikres gjennom å bruke fri programvare. Jfr. avsnittet Datasikkerhet4.3 i kapitlet om Fri programvare.

Den beste måten for brukeren å sikre applikasjoner på, er ved å sikre hurtig bøting av hull som oppdages. Slik kan den enkelte skole sikre seg mot innbrudd før kunnskapen om et gitt sikkerhetshull rekker å spre seg i undergrunnsmiljøene. Den underliggende arkitektur i Skolelinux er skipet rundt et system for enkel og rask pakkedistribuering. En pakke inneholder alle nødvendige filer og regelsett for korrekt implementasjon av en applikasjon. Disse pakkene vedlikeholdes 100 % i tråd med reglene for fri programvare. Slik sikrer Skolelinux på den mest effektive måten at sikkerhetshull oppdages, og at pakken som bøter hullet kan være på plass og aktivert i hvert enkelt Skolelinux-system innenfor et døgn efter reparasjonen er utført sentralt.

Det skal normalt ikke gå mer enn 48 timer fra et hull finnes, til pakken for bøting er ferdig. Slik er den totale responstid fra et hull oppdages, til den enkelte skole er sikret, normalt 72 timer. Det er hurtigere enn avisene klarer å plukke opp historien.

Dette må regnes som svært kort responstid. Normalt ved kommersiell programvare sendes det gjerne ut en årlig oppdatering. Skolelinux kan settes opp slik, at denne oppdateringen skjer automatisk og kontinuerlig - såfremt det er ønskelig. Den lokale IKT-ansvarlige mottar da bare en rapport, som forteller om reparasjonen. Det er imidlertid mere normalt at systemet sender en e-post eller SMS og forteller at en reparasjon er forestående, og den IKT-ansvarlige selv overvåker utførelsen, for å påse at systemet fungerer korrekt mens arbeidet pågår.

Skolelinux er basert på en Linux-distribusjon - Debian http://www.debian.org/ - som er viden kjent for sin stabilitet; skjematiske og omstendelige tilnærming til endringer av distribusjonen; kort responstid i den grad det oppdages feil i distribusjonen. Disse endringer kan enkelt - eventuelt automatisk - propageres inn i fungerende systemer på en kontrollert måte - dersom behandlingsansvarlige ønsker det.

Det kan ikke være noen tvil om at teknologien, som brukes i Skolelinux på den aller beste måte ivaretar applikasjonssikkerheten, og at nettopp dette kanskje er den mest fremragende kvaliteten ved systemet.

Applikasjonssikkerhet krever intet forutgående arbeide eller noen særskilt planlegging fra verken prosjektets eller den IKT-ansvarliges side.

1 Timeanslag

6 Nettverkssikkerhet

I praksis består sikring av nettverk kontroll over informasjonsflyten, dvs. sensur; samt sikring av de deler av systemet som eksponeres for nettverkstrafikk.

Skolelinux er tenkt å være en maskin, som står direkte eksponert til fiendtlige nettverk, dvs. Internett. Skolelinux skal leveres som en fungerene brannmur, som kan beskytte alle maskiner inne i det lokale nettverk bak tjeneren. Anlegges tenkes slik å ha en sikkerhetsforbedrende effekt i nettverket, hvor det skal brukes.

1 Administrasjon

Sikring av eksponerte deler av systemet faller i hovedsak inn under Applikasjonssikkerhet, men dreier seg også i noen grad om vettuge innstillinger av tjenestene. Det er fullt mulig å gi superbruker full adgang til maskinen fra en hvilken som helst annen maskin uten passord, men det er selvfølgelig også det dummeste du kan gjøre. Vi er derfor nødt til å sikre oss at systemet kommer med sikre innstillinger i utgangspunktet.

I den grad den enkelte skole ikke har særskilte behov vil denne brannmur ikke trenge til endringer. Regelsettet for begrensning av trafikkflyten er av høy sikkerhet.

Det er nødvendig med jevne sveip over systemet fra omverdenen - simulerte angrep - for å sikre seg at systemet fungerer hensiktsmessig. Dette arbeidet inngår i IKT-ansvarliges hverdag.

Ansvaret og æren til Skolelinux ligger i å levere systemet med sikre innstillinger, i motsetning til å levere systemet med svært funksjonelle innstillinger. Det er lett å gi noen lønnsforhøyelse, men nesten umulig å sette ned lønnen. Det er greit for systemansvarlig å endre innstillinger, som gir brukerne nye tjenester og muligheter, når hun kjenner seg fortrolig med tjenestene hun åpner for. Brukerne blir glade. Strammer man derimot inn og fratar brukerne muligheter, skaper man misnøye og grobunn for utprøving av måter å omgå restriksjonene på.

Det nevnes at det er en praktisk lov, som sier at selv dumme brukere vil finne nye, hittil ukjente muligheter for bruk av systemer. Det er umulig å sikre tjenester ved å holde dem hemmelig. Derfor må systemet være enklest mulig i utgangspunktet. Unødvendige tjenester deaktiveres.

2 Sensur

Annonsører på Internett bruker metoder for å spre sine annonser som fører til plagsomt mye umerket reklame i e-postkassen. Personopplysninger innhentet uten samtykke fra elever eller foreldre blir benyttet som handelsvare i strid med norsk lov, og kommende EU-direktiver. Elever og lærere vil forvente å kunne skille mellom hva de ønsker skal være privat, og hva som kan gjøres synlig av personopplysninger, elektroniske dokumenter, og e-post.

Arbeidet med å overkomme slike problemer fører til at det er nødvendig med sensur. Det er ingen vei utenom. Hvilke lovmessige konsekvenser dette har vites ikke. Det er allikevel ikke annen praksis enn hva, som er normalt i næringslivet, dvs. implementering av systemer med lister over kjente pornosteder; sperring av uønsket e-post; mulighet for noen grad av overvåking over hva elevene holder på med og lignende.

3 Kryptering

En annen form for kontroll over trafikken er selvfølgelig kryptering av data-overføringer. Det er rikelig med gode verktøy, som er enkle å bruke til dette formålet. Enhver skole kan enkelt opprette tunneler med andre bedrifter, offentlige kontorer eller skoler efter avtale, MEN det finnes også en måte til å autentisere maskiner for hverandre på forhånd.

På samme måte, som vi har personlig, legitimasjon, kan man utstede ID-sertifikater til maskiner, såkalte X.509 sertifikater. Dette er på ingen måte noe lite prosjekt, men vi slipper å behandle det inngående her. Statskonsult har nedsatt et utvalg under ledelse av Seniorrådgiver Katarina de Brisis i Statskonsult, det sk. PKI-utvalget http://www.statskonsult.no/prosjekt/pki/[*],-utvalget som utreder hvordan dette arbeidet skal foregå.

La det være sagt, at Skolelinux er bygget for å integrere sømløst, som man sier, med denne infrastruktur. Arbeidet med å utstede sertifikater er stort, men lar seg relativt lett implementere i Skolelinux.

1 Virksomhet:

7 Konklusjon

Det vil ta minimum 270 timer å utarbeide den grunnleggende sikkerheten i Skolelinux. Det er imidlertid slik, at systemet rent teknisk vil leveres som et sikkert system. Brorparten av arbeidet med å sikre anleggene består i utarbeidelse av dokumenter for «Risk Assesement», driftsrutiner og lignende; foruten opplæring av IKT-ansvarlige. Skoler som har velutdannete IKT-ansvarlige med noen sikkerhetsmessig bakgrunn, vil finne at systemet kjører trygt fra installasjonen av.

Tar vi hensyn til «P-faktoren», betyr det at det vil ta 9 måneder å ha på plass alt materiale og alle rutiner til bruk for skolene.

Utviklerne av Skolelinux kjenner til relevant dokumentasjon og lovgivning, slik at systemet er klart til å la seg integrere i morgendagens EDB-infrastruktur - ikke på en slik måte at Skolelinux vil komme til å støtte denne infrastrukturen i fremtiden, men slik at systemet er klart til å tas i bruk i dag.


next up previous contents
Next: 4 Fri programvare Up: Skolelinux-prosjektet Previous: 2 Forventningene til Skolelinux   Contents
Knut Yrvin 2002-05-09