henrik knopper bloghoved

Må jeg det?

Hver gang der tales om brugerstyring og adgangskontrol synes omkvædet at være at det er svært og det bliver meeeget dyrt.

Specielt det nye dyr i åbenbaringen med rollebaseret id-styring lader til at give store problemer, men betragtes alligevel som et nødvendigt onde.

Men hvorfor er det så svært? Der er da ikke noget nyt i ønsket om at ville have styr på hvem der må hvad. De 4 grundspørgsmål har ikke ændret sig i mange år, nemlig

1) Hvem er du? (aka Autentificering)
2) Må du det? (Autorisation)
3) Hvem gav dig lov til det? (Administration)
4) Har nogen overtrådt - eller forsøgt at overtræde - deres beføjelser? (Revision)

Af de 4 spørgsmål har de 2 første været besvaret i mange år af forskellige former for login-kontrol og gruppe-begreber.

Spørgsmål 3) har også været let at besvare, for det har altid været root/administrator der gav lov. Denne "One ring to rule them all" er imidlertid ikke i tråd med mere moderne sikkerhedsprincipper om adskilte roller.

Spørgsmål 4) har også været let at besvare, men kun for root. Hvis "the one ring" ønskede at slette sine spor ville ingen kunne opdage det.

Hvis jeg har forstået tingene rigtigt er den officielle løsning på de problemer der ligger i ovenstående ikke at tage hver enkelt problem for sig og løse det indefra, dvs fra kernen af de enkelte operativsystemer, men derimod at plastre et sikkerhedskoncept udenpå "det hele" som godt nok løser de kendte problemer (tror jeg da) og som også giver en masse ekstra muligheder, men som samtidig tilfører en stor kompleksitet ved bl.a. at indføre et rolle-begreb ind mellem brugerne og grupperne samt ved at ville løse alle sikkerhedsmæssige udfordringer med et enkelt koncept.

At koblingen mellem brugere og roller i rollebaseret id-styring ydermere er dynamisk gør ikke kompleksiteten mindre.

Komplekse løsninger betyder som regel at man skal stole på implementeringen og have tillid til sine procedurer. "Stole på" og "tillid" var ikke lige de ord jeg ville vælge som salgsparametre til en sikkerhedsløsning.

TIlbage under Falklandskrigen blev den engelske destroyer Sheffield sænket af et fransk-produceret Exocet-misil affyret fra et argentinsk fly, selvom kryseren var udstyret med alt i automatiske anti-misil systemer (AMS). Der cirkulerede på et tidspunkt et rygte om at det var en fejl i regel-sættet på AMS der muliggjorde en kommunikation mellem skibets hvoedcomputer (HC) og AMS i stil med

HC->AMS: Der kommer noget imod os. Check lige!
AMS -> Misil: Hvem er du?
Misil -> AMS: Et Exocet misil.
AMS -> HC: Der kommer et Exocet-misil. Hvor kommer det fra?
HC -> AMS: Fra Frankrig.
AMS -> HC: Er Frankrig en fjende?
HC -> AMS: Nej
...

Det kan godt være at det i lokale installationer ikke vil være krigsskibe men kun penge, patienter og straffeattester, men er det risikoen værd at beskytte sig med med meget komplekse systemer?

Når det er så svært og løsningen er så kompleks, er det så fordi det er de forkerte spørgsmål der bliver stillet?

Det vil uden tvivl blive brugt imod mig senere, men det her er et af de steder hvor jeg i fuldt alvor mener at man burde overveje at tilpasse sine procedurer fremfor at kode endnu et Spaghetti Incident - bare fordi nogen har sagt at det er smart.

Keep It Simple, S....

Kommentarer (1)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Mikkel Meyer Andersen

Godt - og ikke mindst aktuelt - debatoplæg!

Dit indlæg er meget bredt, så jeg tillader mig udelukkende at kommentere noget af det; nemlig behovet for brugerstyring og adgangskontrol - herfra samlet kaldet "brugeradministration" for læsevenlighedens skyld).

Den første erkendelse er rigtig nok; man skal have mange systemer og mange brugere, for at det kan betale sig. Så vidt jeg husker (kan muligvis finde kilden), siger Gartner, at en medarbejder typisk har 17 brugerkonti i forskellige systemer - så gennemsnitsligt er antallet af systemer ofte incitament nok for at indføre automatisk brugeradministration (hvor mange af disse, der rent faktisk kan foretages automatisk brugeradministration på, er en anden diskussion). Sidste parameter er antallet af medarbejdere, hvilket er helt essentielt - hvis ikke det mest essentielle og direkte dikterende om, hvorvidt det kan betale sig.

Udover de rent økonomiske anliggender, er der også andre væsentlige argumenter så som lov- og revisionskrav samt DS-484 osv. Jeg ville dog nødigt påstå at kunne opfylde DS-484's krav til eksempelvis sporbarhed, hvis jeg ikke havde en centraliseret brugeradministration.

Som du skriver, har man i mange år foretaget brugerstyring fra decentralt hold rent teknisk; i større organisationer sker det dog ofte organisatorisk fra centralt hold. Dette har betydet, at der er en organisatorisk enhed, der har foretaget brugerstyring decentralt (system for system).

Brugerkonti administreres altså system for system fra et centralt hold. Dette kræver mange resourcer - og som nævnt er eksempelvis sporbarhed praktisk talt umuligt.

Krav som tidsbegrænset adgang er også en væsentlig funktionalitet, som er svær at praktisere uden automatik. Og tidsbegrænset adgang er eksempelvis et lovkrav for visse institutioner.

Så alt i alt er jeg overbevist om, at det i rigtig mange tilfælde godt kan betale sig med centraliseret brugeradministration.

Næste hurdle er så, hvordan man indfører det i virkeligheden. Du har ret i, at det i dag er et lag ovenpå alle systemerne - og at systemerne som sådan ikke ved, at et "flinkt" system har overtaget brugeradministrationen fra dem. Ofte fungerer IdM-systemet som en automatiseret administrator (hvilket også skærper kravene til direkte brugeradministration på hvert system).

I den ideelle verden kunne det sagtens designes bedre - og som teknisk arkitekt, kan jeg sagtens forstå, du tænker sådan. Desværre er det ikke muligt i virkeligheden indenfor en overskuelig fremtid at gøre dette. Det ville jo - som du siger - betyde en helt anderledes indbyrdes arkitektur af systemerne. Jeg er dog enig med dig i, at man fremover skal være opmærksom på dette, og ikke bare acceptere, at IdM ligger ovenpå som "et ekstra lag på lagkagen".

(Jeg beklager det lange indlæg - og ligeledes for eventuelle stavefejl.)

/mikl-dk

  • 0
  • 0
Log ind eller Opret konto for at kommentere