Sådan bygger vi et system, der forstår relationer
Bag vores cyber range ligger mange overvejelser om brugervenlighed. Derfor stillede vi spørgsmålet: “Hvem må egentlig hvad herinde?” Det blev starten på vores projekt med at bygge en autorisationsmodel, der både undgik role explosion og at den blev for svær at finde rundt i.
Vi har tidligere siddet i mange systemer, som bruger "Role Based" adgangskontrol (RBAC), men desværre ikke noget, der passer i vores system.
Vores labudviklere må redigere i sagaer. En dag kommer der en ekstern labudvikler, der skal hjælpe med at lave et enkelt af labbet. Skal vi nu lave en ny rolle, "ekstern labudvikler", der er bundet op på, at den rolle kun må redigere i sagaer markeret med "åben for eksterne"?
RBAC oplever hurtigt det vi kalder for "Role Explosion", hvor hver use case pludselig får brug for en ny rolle. Det besluttede vi os for, ikke var holdbart i længden.
Derfor var det nærliggende at tænke over, hvordan andre håndterer problemet.
Vi så at den måde vores labudviklere skulle kunne udvikle og have adgange til Sagaer, mindede om den måde, man deler ting på i Google Drive. For hvert dokument er det muligt at tildele rettigheder til at kunne redigere, eller at se dokumentet, og så er der en ejer af projektet. Derudover er det muligt at arve adgang. Hvis man ejer en mappe i Google drev ejer man også automatisk alle filerne inden i.
Google udgav i 2019 et whitepaper, der hedder "Zanzibar: Google’s Consistent, Global Authorization System" (https://storage.googleapis.com/gweb-research2023-media/pubtools/5068.pdf). 14 sider, der beskriver en helt ny arkitektur for adgangsstyring. Relationel Adgangsstyring, forkortet til "ReBAC". Dette paper er klart værd at læse - de beskriver både, hvordan de opbygger disse relationer til at kunne håndtere avancerede relationer, men også, hvordan de håndterer authz requests på tværs af kloden med forbehold for synkroniseringsproblemer og invalide data.
Deres problem og løsning er i en større skala end det, vi arbejder med. Zanzibar håndterer (da paperet blev udgivet) mere end 10 millioner anmodninger i sekundet. De har en latenstid på 10ms i det 95. percentil. (det vil sige, at 95% af alle anmodninger bliver svaret inden for 10ms, altså 0,01s). Systemet indeholder over to billioner dataposter, der beskriver relationer mellem brugere og objekter (tupler). Det svarer til omkring 100TB data. Man kan altså roligt sige, at denne autorisationsmodel er testet i virkeligheden.
Autorisationsmodellen fungerer således, at man først beskriver alle sine typer og hvilke relationer, de kan have til hinanden. Dernæst indsætter man de relationer, der gør sig gældende for systemet (kaldet tupler - (B, R, O) bruger B har relation R til objekt O) og til sidst kan man så spørge autorisationsmotoren om hvorvidt en relation findes.
Lad os tage et eksempel:
Vi har følgende typer: Saga, Bruger, Træning
Vi har følgende relationer:
Saga:
Træning (hvilke træninger denne saga indgår i)
Ejer (den bruger der har oprettet den)
Kan-Tilgå: Ejer ELLER Instruktør fra Træning.
Træning:
Instruktør (hvilke brugere der har "instruktøradgang" til træningen)
En bruger har ingen relationer
Vi har følgende tupler ("aktive" relationer):
Bruger:Victor er Instruktør til Træning:1
Bruger:Sarah er Instruktør til Træning:1
Bruger:Sarah er Instruktør til Træning:2
Bruger:Emil er Ejer til Saga:X
Bruger:Christian er Ejer til Saga:Y
Træning:1 er Træning til Saga:X
Træning:2 er Træning til Saga:Y
Vi kan nu spørge systemet om relationer:
Q: Har Bruger:Victor Kan-Tilgå til Saga:X?
A: Ja! Bruger:Victor -> Kan-Tilgå -> Instruktør -> Træning:1 -> Træning -> Saga:X
Q: Har Bruger:Victor Kan-tilgå til Saga:Y?
A: Nej.
Q: Har Bruger:Emil Kan-Tilgå til Saga:X?
A: Ja! Bruger:Emil -> Kan-Tilgå -> Ejer -> Saga:X
Det er også muligt at spørge systemet om relationer på anden vis:
F.eks.
Hvilke objekter af type T har bruger B relation R til?
Hvilke brugere har relation R til objekt O?
På denne måde er systemet enormt modulært og tillader at man kan beskrive komplekse relationer med komposite og nedarvede forhold, med simple tupler.
Med ReBAC har vi fået et fleksibelt og skalerbart adgangssystem, der kan vokse sammen med vores behov uden at drukne i roller eller undtagelser. Det giver os mulighed for at modellere virkelige relationer mellem brugere, objekter og kontekster på en intuitiv måde. Kort sagt: et adgangssystem, der forstår vores verden, ikke omvendt.
