Kapitel 9 Sikkerhedssystemer

Det kan forekomme vanskeligt for den sikkerhedsansvarlige at overskue alle de problemstillinger, der hører til emnet. Der skal gennemføres risikoanalyse, opstilles sikkerhedspolitik og vælges sikkerhedsprodukter.

Dette kapitel stiller et værktøj til rådighed, en generel sikkerhedsmodel. Modellen kan være med til at sikre, at alle sikkerhedstiltag arbejder sammen, står i rimeligt forhold til hinanden og dækker de nødvendige områder.

Sikkerhedsniveauet skal være højt, men ikke for højt. For megen sikkerhed koster penge og kan pålægge brugere og administratorer urimelige byrder. Det er derfor vigtigt, at de enkelte elementer i løsningen passer sammen.

Ekstra system til sikkerhed

Et sikkerhedssystem er en udbygning af et eksisterende edb-system med henblik på at opnå et højere sikkerhedsniveau. Sikkerhedssystemer er ikke et emne, der traditionelt har været vidt og bredt omtalt. Dels på grund af emnets tekniske slagside og dermed sværhedsgrad. Dels fordi man har bygget noget af sikkerheden på manglende indsigt hos brugerne. Hvis bare de vidste!

Hvis et sikkert miljø skal bibeholdes, nytter det ikke at afsløre alle tekniske detaljer. Hvis man bruger en analogi med en lås, er det bedst, at det er nøglen, der holdes hemmelig frem for låsens virkemåde. Bygger sikkerheden på hemmeligholdelse af virkemåder, forfalder man lettere til at sjuske med nøglen. Og i længden er virkemåder umulige at hemmeligholde.

Formentlig kan det endog øge sikkerheden, hvis de generelle virkemåder er almindelig kendt. Hermed sikres en hurtigere afsløring af uduelige metoder, og yderligere mindskes risikoen for uheldige fejltagelser. Hvis man kender princippet for en lås, vil man ikke finde på at smøre den med konsistensfedt.

Før, under og efter

Sikkerhedssystemer består af to elementer: En teknisk del og en menne­skelig. Den sidste omfatter hele brugen af det sikrede system. Her er både sikkerhedsadministratorens og brugerens forskrifter, værktøjer og praktiske adfærd inde i billedet.

For lettere at kunne overskue, hvorledes de enkelte komponenter i sikkerhedssystemet fungerer, er det praktisk at inddele efter en tidsakse. Som i anden risikoanalyse opdeles de sikkerhedsmæssige tiltag i før, under og efter:

	•	Præventive	Før: Oprettelsen og definitionen af de elementer, der indgår i sikkerhedsløsninger: Brugere, ressourcer, autorisationer m.v.
	•	Protektive	Under: Kontrollen af, at tingene foregår i overensstemmelse med de givne autorisationer
	•	Korrektive	Efter: Den historiske optegnelse over, hvad der er foregået: Logningen og de konsekvenser, man drager af den

Præventiv sikkerhed

Præventiv edb-sikkerhed drejer sig først og fremmest om tilpasningen af sikkerhedssystemet, så det kan bruges. Der skal oprettes brugere og gives autorisationer. Hermed forstås, at der skal gives tilladelse til, at der udføres en række aktiviteter i forhold til nogle objekter. Eksempler på objekter er filer, programmer, printere, transaktioner og så videre.

Brugere og deres rettigheder skal defineres i et autorisationssystem. Sik­kerhedssystemet vil som regel være menustyret, så det for eksempel er muligt at uddele autorisationer ved afkrydsning i en skemastruktur.

Styringen af, hvem der må hvad, foregår gennem den del af sikkerhedssy­stemet, der kaldes en sikkerhedsdatabase, hvori følgende findes defineret:

	•	Ressourcer	Diskområde, printer, kommunikationsadgang, programmer, transaktioner osv.
	•	Identer	Typisk personer, men kan også være for eksempel et fremmed edb-anlæg
	•	Adgangsrettigheder	Om der må læses, skrives, slettes osv.

Denne sikkerhedsbase er hovednøglen til hele sikkerhedsadministrationen. Det er den, der skal spørges til råds, når en bruger vil have adgang til anlægget, til programmer, til datafiler etc.

Sikkerhedssystemet indeholder typisk et menusystem eller et andet egnet værktøj til oprettelse og/eller tilskrivning af nye oplysninger i sikkerhedsdatabasen. Administrativt løses opgaven ved, at den sikkerhedsansvarlige fastlægger en procedure.

Af praktiske grunde vil det være en stor fordel med et sikkerhedssystem, hvormed det er muligt at uddelegere administrator-funktioner, således at det ikke altid påhviler den (øverste) sikkerhedsansvarlige at tilføje eller ændre autorisationer.

Sletning af forældede oplysninger

Det er ikke nok at tilføje og ændre i sikkerhedsdatabasen. Når en medarbejder rejser eller skifter arbejdsområde, må de tidligere autorisationer fjernes. Sletning af gamle oplysninger udgør et sikkerhedsmæssigt problem. Man kan udfærdige en administrativ forskrift, men der er ikke nogen konstant drivkraft til at huske at få slettet oplysninger i sikkerhedsdatabasen. De generer jo ikke nogen før den dag, da en eller anden finder på at (mis)bruge en autorisation, man havde glemt eksistensen af.

Det er en god ide at kræve af edb-teknikken, at den skal hjælpe med til at løse dette problem. Som minimum bør det forlanges, at sikkerhedssystemet kan udskrive gode rapporter om, hvem der må hvad. Endvidere findes der systemer, der kan give en advarsel til sikkerhedsadministratoren, når en bestemt autorisation ikke har været brugt i lang tid.

Det kan anbefales, at man undgår at knytte brugernavnet sammen med nogen former for afdelingsmæssig eller geografisk tilhørsforhold. Hvis man laver brugernavne som SKAT123, vil man skulle ændre brugernavnet, når denne bruger bliver flyttet fra skatteforvaltningen til teknisk forvaltning. Lad derfor brugernavnet være knyttet alene til personen.

Sikkerhedssystemer med tilhørende sikkerhedsdatabase er en del af de fleste minidatamat-styresystemer. Men det er normalt ikke det ottende vidunder, man præsenteres for. Sikkerhedsdatabasen er begrænset, og det er svært at styre den. UNIX systemer er således ikke kendt for effektiv sikkerhed, og pc’er med DOS mangler helt et sikkerhedssystem. Derfor vil det næsten altid være nødvendigt at tilføje et ekstra sikkerhedssystem til UNIX og DOS for at kunne opfylde grundlæggende krav, herunder kravene til registersikkerhed.

Mange sikkerhedsdatabaser

Netop med baggrund i de generelle sikkerhedsmæssige svagheder i de mest udbredte flerbrugersystemer kan man sjældent nøjes med én og kun én sikkerhedsdatabase. Mest udpræget opstår problemet i forbindelse med Registertilsynets krav om differentieret adgangskontrol. Hermed menes for eksempel, at alle brugerne nok må læse data, mens kun to af dem tillige må tilføje nye og ændre eksisterende data. Og kun én er autoriseret til at slette.

Det er sjældent, at styresystemer eller ekstra sikkerhedssystemer kan foretage denne opdeling tilstrækkelig finkornet. Opdelingen må ske inde i selve brugerprogrammet, der derfor skal have sin egen sikkerhedsdatabase.

Dette giver en mangfoldighed af sikkerhedsdatabaser og måske en mængde brugernavne for hver bruger. Og som konsekvens heraf skal der være lige så mange forskellige kendeord. Det er en stor opgave at holde alle disse oplysninger korrekt opdateret.

Hvis sikkerhedsdatabasen skal indeholde alle mulige oplysninger om, hvem der må hvad med hvilket, bliver den i teorien uendelig stor. Som eksempel kan tages medarbejderen på inkassokontoret. Hun må se inkassooplysninger, men det er ikke heldigt, hvis hun kigger efter bestemte personer af personlige grunde. Det er svært - eller umuligt - at spærre for den slags via adgangskontrol. Der er behov for en slags ekstrafunktion til at afgøre tvivlstilfælde og dække sig ind over for det uforudsete. Logning indføres derfor blandt andet som et alternativ til uendelig store sikkerhedsdatabaser. Endvidere anser blandt andre Registertilsynet logning for at være en god præventiv foranstaltning.

Protektiv sikkerhed

Den protektive sikkerhed kan betegnes som de mekanismer, der løbende kontrollerer, at alt foregår i overensstemmelse med de givne autorisationer.

Som nævnt indeholder alle edb-systemer et styresystem. En del udstyres også med et specielt sikkerhedssystem. Sikringen af, at der kun sker det, der er tilladt, foregår i et samspil mellem et styresystem og et sikkerhedssystem.

Sikkerhedssystemets funktion

Nå man indbygger ekstra sikkerhedsfunktioner i et edb-anlæg, betyder det, at man ændrer det oprindelige styresystems opførsel. Desuden tilføjer sikkerhedssystemet en ekstra sikkerhedsdatabase eller udbygger den eksisterende. Denne base kan så rådspørges af de aktive parter, styresystem og brugerprogrammer. Hvis den ønskede aktivitet kan godkendes, giver sikkerhedssystemet et positivt svar tilbage.
Hvis aktiviteten ikke er acceptabel ud fra sikkerhedsdatabasens oplysninger, gives der et negativt svar. Det er så op til styresystemet eller brugerprogrammet at reagere på dette nej, for eksempel ved at nægte at udføre aktiviteten. Det er således ikke sikkerhedsdatabasen og ej heller sikkerhedssystemet som sådan, der forhindrer handlingen.

To filosofier

Sikkerhedssystemer konstrueres efter to forskellige grundsynspunkter. Man kan som udgangspunkt afskære brugerne fra alt og langsomt, drå­bevis, tillade mere og mere indtil et givet niveau. Man kan også gå den anden vej: I starten tillade alt og løbende foretage en indsnævring af råderummet.

Den første - restriktive - filosofi er meget udbredt i flerbrugeranlæggenes verden. Og med god grund. Her er der simpelt hen ikke råd til, at alle fra starten må alt. Jo større anlæg, jo mere restriktiv sikkerhed. Det ses tydeligt afspejlet i de store centralmiljøer - servicebureauernes - hvor der sættes meget snævre rammer for aktiviteten. Tilløb til at træde uden for disse rammer resulterer i meddelelsen: Logning af sikkerhedsbrud.

Omvendt med de personlige datamater - pc’er. Her er det i almindelighed særdeles uønsket at opleve disse som en forlænget udgave af et centralt system med dets få valgmuligheder og frihedsgrader.

Disse to filosofier er tæt knyttet til to hovedmåder at etablere sikkerhedssystemer på, nemlig programbeskyttelse og databeskyttelse.

Programbeskyttelse

I flerbrugermiljøer kontrolleres adgangen til data traditionelt ved at kontrollere adgangen til de programmer, hvormed man bearbejder data. Det kan også kaldes for kontrol med de benyttede værktøjer.

Som omtalt vil denne form for beskyttelse ofte opleves som restriktiv. Den kan gennemføres ved, at brugeren kun kan starte programmer gennem udpegning fra en menu. En anden måde er at tildele brugeren et begrænset antal transaktionskoder.

Nogle har forsøgt at gennemføre denne beskyttelsesfilosofi på pc’er. Der er imidlertid en række tekniske problemer ved pc’en og dens styresystem, der gør, at metoden ikke kan kaldes skudsikker. De fleste pc-sikkerhedssystemer, der prøver at holde brugeren inde i en menu, kan alligevel omgås. Og så er resten af beskyttelsen illusorisk. I øvrigt vil de færreste gamle pc-brugere bryde sig om at blive låst inde i en bestemt menu, hvis de har vænnet sig til at bruge en anden menu eller måske kommandoer.

Databeskyttelse

I stedet for at kontrollere værktøjerne til manipulation af data kan man gå mere direkte til værks. Man kan beskytte data mod manipulation. Dette lader sig gøre med krypteringsteknikker, hvorved data kun gøres læsbare for den eller de, der er autoriseret hertil. Denne metode er bedre egnet til systemer, der har et fleksibelt anvendelsesmønster. Det medfører frit værktøjsvalg, man skal blot være autoriseret til at bruge data.

Et godt krypteringssystem vil sikre mod, at uautoriserede ser eller bruger de beskyttede data. Derimod vil det i almindelighed være muligt at ødelægge (slette eller overskrive med volapyk) disse data, selvom de er beskyttet ved hjælp af kryptering. I et pc-miljø betyder dette forhold imidlertid ikke den store tillægsrisiko. Pc’en befinder sig alligevel inden for et hammerslags afstand. Kan man ikke leve med den risiko, må man opbevare sine data et mere beskyttet sted, typisk på en server, der er fysisk beskyttet. Denne mulighed realiseres let i et lokalnetmiljø.

Korrektiv sikkerhed, revision

Revision af for eksempel regnskaber sker for at sikre, at der ikke er foregået noget unormalt. Eller, hvis der er, at der så sker en korrektion af misforholdet. Revision har derudover en forebyggende virkning: Man fristes næppe så let til at jonglere med tallene, nå man ved, at nogen kigger dem efter – måske allerede i morgen!

I forbindelse med edb-systemer kan der ske en logning for at skabe grundlag for den efterfølgende revision. Logning kan udføres på mange forskellige måder – via papir eller edb.

Såvel et styresystem som et sikkerhedssystem kan gennemføre logning. Det er meget almindeligt, at flerbrugerstyresystemer kan udføre en vis form for grundlæggende aktivitetslog: Hvem får adgang til systemet, hvornår og hvor længe benytter de det?

Som tidligere nævnt vil det ikke i praksis være muligt at forudse alle situationer. Der skal altid være plads til uforudsete hændelser. Endvidere er der visse hændelser, man er specielt interesseret i at vide noget om.

Det er først og fremmest forsøg på overtrædelser. Alle indtrængere i edb-systemer er på ukendt grund første gang, de forsøger noget uautoriseret. En hacker vil således være nødt til at afprøve mange brugernavne og kendeord, før det rigtige findes, og det vil se uregelmæssigt ud i en log.

Ud over styresystem og sikkerhedssystem kan også ethvert (bruger)program i princippet logge sin egen aktivitet. Det er altså samme situation som med sikkerhedsdatabaserne - en masse centre for information. Hvilke af disse har den mest relevante information, og hvordan kombineres den til en meningsfyldt helhed?

Logkvalitet og logbeskyttelse

Hvis en log skal have nogen mening, må der ikke kunne rejses tvivl om dens ægthed og kvalitet. Det gælder især for dens præventive funktion. Det må således ikke være muligt at slette eller manipulere loggen for dermed at slette sporene efter en kriminel aktivitet. Loggen bør være blandt de allerbedst beskyttede systemressourcer.

Et særligt forhold ved logning er dens tilknytning til tid. Et eksempel: Har hr. Olsen kørt transaktioner, mens han var på Gran Canaria? Der må ikke kunne rejses tvivl om, at klokken gik rigtigt på logningstidspunktet. Ellers kan loggen ikke bruges som bevis for, at nogen har misbrugt hr. Olsens brugernavn.

Uanset system må sikkerhedsadministratoren være meget opmærksom, hvis der optræder mærkelige fejl eller ulæselige partier i en log. Der er i så fald mulighed for, at nogen har forsøgt at slette sporene efter en ulovlig indtrængen eller anden mistænkelig aktivitet.

Fælles log

Det blev nævnt i afsnittet om mange sikkerhedsdatabaser, at de enkelte programmer er nødt til at lave nogle sikkerhedscheck. Som følge heraf får de også behov for at logge noget af det, der sker.

Det er afgørende for loggens anvendelighed, at de enkelte dele af den samles, således at lograpporten kommer til at beskrive en helhed. Hvis hvert program laver sin egen log, får den sikkerhedsansvarlige et betydeligt arbejde med at indsamle logfiler fra alle disse programmer. Det bliver i praksis umuligt at lave én fornuftig revisionsrapport ud fra mange forskellige logfiler. Hvis derimod alle programmer opdrages til at sende log­hændelser til det generelle sikkerhedssystem, da kan man få én og kun én log. Dette forenkler og effektiviserer det nødvendige revisionsarbejde.

Et generelt sikkerhedssystem er specielt indrettet til sikre logdata mod sletning og ændring. Da det som nævnt kan være vanskeligt at lave effektiv logbeskyttelse, er dette endnu en grund til, at alle programmer bør aflevere logdata til et sådant system, og ikke til et antal — mindre sikre — systemer. Alternativt må logdata som minimum kunne afleveres i et format, der let kan indarbejdes i for eksempel et regnearksprogram. Denne løsning giver imidlertid ikke i sig selv nogen sikkerhed for troværdigheden af de indsamlede logdata.

Efterbehandling af logdata

Ifølge Registerloven skal loggen kontrolleres, gemmes og efter 6 måneder destrueres. Hvert edb-anlæg med følsomme registre danner mange logdata. Hvis revisionen skal have nogen chance for at revidere, skal logdata fra hver eneste edb-anlæg køres igennem en rapportgenerator, der kan lave nogle relevante sikkerhedsrapporter. Kilometerlange kronologiske udskrifter er tilnærmelsesvis ubrugelige.

I forbindelse med decentraliseringen stilles der i stigende grad edb-udstyr til rådighed for institutioner m.v. Der er i den forbindelse tre muligheder omkring loghåndteringen.

	•	Revisionsansvaret lægges ud på den enkelte institution
	•	Revisorerne skal ud på cyklen
	•	Central indsamling af logdata

De to første alternativer er uhensigtsmæssige. Den første model medfører, at man skal revidere sig selv, den anden er forbundet med praktiske vanskeligheder og stort tidsforbrug.
Den eneste fornuftige løsning er at vælge et sikkerhedssystem, der muliggør central indsamling af logdata. Indsamlingen bør foretages med rimeligt korte intervaller, blandt andet for at aflaste det enkelte anlægs harddisk. Det må i den forbindelse huskes, at disse logdata skal være særdeles godt beskyttet under transporten, uanset om denne sker over en telekommunikationslinje eller via disketteforsendelse. I praksis må logdata være krypterede.

For at kunne lave sikkerhedsrapporter, der dækker hele virksomheden eller kommunen, skal logdatafilerne endvidere ligge i et fælles format. Det er ydermere en fordel, hvis det er muligt at opbevare logdata og lave rapporterne på en valgfri maskintype, for eksempel såvel på en pc som på afdelings- eller kommuneanlægget.

Logdata til fælleslog

Hvis man skal følge anbefalingen om én og kun én log, fælles for sikkerhedssystemet og alle programmer i det givne anlæg, da må der findes en fælles, sikker og velbeskrevet måde at overføre logdata på.

[udeladt: omtale af udgået Kommunedata arkitektur/produkt]

Sikkerhedsmodellen

Grundelementerne i sikkerhedssystemerne kan samles i en model. Denne model synliggør de enkelte elementer og deres indbyrdes forhold.
Stort set alle edb-sikkerhedssystemer har nogle principielle fællestræk: Der ligger nogenlunde samme logik bag dem alle. Edb-sikkerhed er fundamentalt baseret på kendskab til disse tre størrelser:

	•	Subjekt	Hvem der starter en aktivitet
	•	Objekt	Hvad aktiviteten er rettet mod
	•	Aktivitet	Hvad skal der gøres med objektet

 

Den lim, der binder disse tre sammen er:

•

Autorisationen

For eksempel hvilken aktivitet et bestemt subjekt må udføre på et bestemt objekt

Uddelingen af disse autorisationer skal efterleve de følgende 6 krav:

	•	Integritet	At systemet kun gør, hvad der forventes og intet andet
	•	Tilgængelighed	At systemet er tilgængeligt, når det ønskes
	•	Fortrolighed	At systemet og dets data kun er tilgængeligt for de brugere, som er blevet autoriserede til at bruge det
	•	Reviderbarhed	At det er muligt at observere og verificere de aktiviteter, der finder sted i systemet. Og at der efterlades et spor af, hvad der er sket: Der laves en log
	•	Kontrollerbarhed	At det er muligt at kontrollere og styre, hvem der har adgang til hvilke ressourcer i systemet
	•	Anvendelighed	At opfyldelsen af de ovennævnte krav ikke virker hæmmende på legale aktiviteter i systemet i form af uacceptable svartider, for stort ressourcefor­brug eller uhensigtsmæssig anvendelse i øvrigt

Tre stadier

Når tidsfaktoren som før nævnt bringes ind i billedet, inddeles de sikkerhedsmæssige tiltag i tre stadier: før, under og efter:

	•	Præventiv	Oprettelsen og definitionen af subjekter, objekter, aktiviteter og autorisationer
	•	Protektiv	Kontrollen af, at tingene foregår i overensstemmelse med de givne autorisationer
	•	Korrektiv	Den historiske optegnelse af, hvad der er foregået: logningen og de konsekvenser, man drager af den.

Tre niveauer

Der kan opstilles tre metoder til sikring mod datatab. Sikringen kan ske på tre niveauer:

	•	Proceduremæssig	At fastlægge nogle fremgangsmåder eller standarder for, hvordan forskellige handlinger skal gennemføres. For at forhindre brand kan man indføre rygeforbud. For at sikre mod for let indtrængen i systemerne, kan man bestemme, at kendeord skal have en vis længde.
	•	Edb-teknisk	At benytte nogle af de muligheder, som edb-systemerne besidder for at beskytte disse. Adgangskontrol er et eksempel herpå.
	•	Fysisk	At imødegå trusler gennem etablering af fysiske spærringer. De kan for eksempel være af bygningsmæssig art: Mure, aflåste døre, brandslukningsanlæg og så videre.

For at lette overblikket er begreberne samlet i en model, modellen er en slags sikkerhedsmur.

Trusler mod edb-sikkerheden

Der kan være en række kilder til truslerne mod edb-sikkerheden. De søger at gennemtrænge sikkerhedsmuren. Disse kilder kan være:

	•	Edb-Systemet	De fejl, der stammer fra (edb-)systemet selv. Der kan være tale om nedbrud i maskine eller programmer, eller for eksempel fejl ved dataoverførsel
	•	Mennesker	Handlinger - de være sig tilsigtede eller utilsigtede - for eksempel uautoriseret adgang til data
	•	Ulykker	Lynnedslag, oversvømmelse osv., altså det, der normalt rubriceres som force majeure.

Virkningerne af truslerne svarer til, hvad der ville ske, såfremt muren gennembrydes. De kan deles op i tre forskellige former for tab:

	•	Pålidelighed	At man ikke længere kan regne med, at ens data - eller en del af disse - stemmer overens med de faktiske forhold
	•	Tilgængelighed	At man ikke længere har adgang til de data, man har brug for
	•	Fortrolighed	At data bliver tilgængelige for nogen, for hvem de ikke var tiltænkt, eller som måske endog kan misbruge dem.

Der er således tre niveauer af beskyttelse, der kan sættes ind over for trusler, som kan optræde i tre forskellige stadier. Altså i alt ni muligheder. Det er disse ni muligheder, der er illustreret i figuren.

Det kan anbefales at benytte modellen i forbindelse med fastlæggelsen af en sikkerhedspolitik for virksomheden, kommunen eller organisationen. Ved at tænke højt omkring betydningen af de 9 felter, vil man i de fleste tilfælde få afklaret en række risici og kunne foretage en samlet dimensionering af en sikkerhedsmur, der er i overensstemmelse med de aktuelle behov og muligheder.

Ovenstående tekst og billede må citeres i uddrag med kildeangivelse: Anders Djursaa & Torsten Møller Madsen © 1991, 2018 Henvises til hele teksten, må der linkes til: http://inteko.dk/Contents/sikkert_kap9.html

Til Kapitel 8 - Kryptering