−Table of Contents
NAV referansegruppemøte om tilgangsstyring i NAV, 24. april 2025
Dette er et ekstraordinært referansegruppemøte kun for å diskutere hvordan mer fingranulert tilgangsstyring i NAV skal fungere.
Tilstede:
- Øyvind Nesland, UiA
- Ingeborg Hellemo, UiT
- Nils-Arild Grav, NTNU
- Sigurd Refvik, UiO
- Morten Werner Forsbring, UiO
- Vidar Faltinsen, Sikt
- Johanna England, Sikt
- Simon Oliver Tveit, Sikt
- Ilona Podliashanyk, Sikt
- Morten Brekkevold, Sikt
Forfall:
- Knut-Helge Vindheim, Sikt
- Hanne Moa, Sikt
Agenda
Møtet blir avholdt som videokonferanse vha. Zoom, fra kl. 12:00 til 15:00.
0. Velkommen/Innledning
Morten ønsker velkommen på vegne av Sikt.
1. Tilgangsstyring i NAV
Relevante issues og annet saksunderlag
Referat
Møtet åpnet med beskjeden om at HiVolda dessverre ikke har ressurser til å stille med en representant i gruppen fremover, slik at vi sannsynligvis bør se om vi finner noen andre interesserte fra UH-sektoren til å ta HiVoldas plass.
Ellers begynte møtet med en runde rundt bordet for å først høre fra UiT, UiO, UiA og NTNU hva de egentlig har for slags behov for mer fingranulert tilgangskontroll i NAV, før vi gikk videre til å se på de spørsmålene som allerede er løftet frem i f.eks. Authorization based on users organizational affiliation #1046 på GitHub.
Runde rundt bordet
UiT
Har mest behov for å begrense hva forskjellige brukere kan “se” i NAV.
- Ønsker mulighet for å gi noen brukere rettigheter til å legge til og redigere “eget” utstyr i SeedDB, uten at de skal ha tilgang til “andres” utstyr.
- Konkret use-case: UiT ønsker å slippe inn teknikere som bare jobber med A/V-utstyr inn i SeedDB, men at de bare får lov til å se og redigere detaljer på utstyr som er registrert i en av brukerens tilknyttede organisasjoner. De skal kunne registrere nytt utstyr også, men bare tilhørende en av sine egne tilknyttede organisasjoner.
- Det er imidlertid vanskelig å gi slike brukere tilgang til å se på eller redigere “management profiles”, da disse ikke har noen eierskap eller organisatorisk tilknytning. Her foreslår at UiT at disse brukeren ikke trenger tilgang til å lage egne profiles eller se på andres, de trenger bare tilgang til å velge en hvilken som helst tilgjengelig profil til det utstyret de allerede har tilgang til å redigere.
- Utover SeedDB, ønsker UIT da at disse mer begrensede brukerne skal få lov til å se detaljer om “sine” bokser i ipdevinfo, men ingen detaljer om andre bokser.
- Det går fint at naboskap til andre bokser nevnes i detaljene til en boks man har tilgang til, men man skal ikke kunne klikke seg inn for å lese detaljer om disse boksene.
- Vedgår at machine-tracker-søk vil være vanskelig å begrense på noen fornuftig måte, ut over det som går an allerede i dag: Enten har brukeren tilgang til å bruke machine tracker, eller så har de det ikke.
- På dette punktet kom det innspill fra Nils-Arild fra NTNU inn at de har sett at det er vanskelig å finne argumenter for å frata begrensede brukere muligheten til å søke i alle maskinsporingsdata, fordi det begrenser nytten av maskinsporingsverktøyet som feilsøkingsverktøy for disse brukernes nett.
- UiO foreslår i stedet at alle maskinssporingssøk burde audit-logges i NAV, slik at alle brukere er klar over at deres maskinsporingsaktiviteter kan ettergås.
UiO
UiO beskriver sine eventuelle behov som ganske like med UiTs (som presiserer at antageligvis 95% av brukerne de har i NAV bare har lesetilgang).
UiO sperrer ned aksess til NAV ganske kraftig, bak lukkede nett/VPN, fordi det er et verktøy som kan gjøre endringer i nettkonfigurasjon, men at det derfor er litt vanskelig/upraktisk å gi folk rene lesetilganger i NAV, f.eks. fra mobilt utstyr som ikke kan kobles til disse lukkede nettene når tekniker er ute i felt. Dette er egentlig ikke et problem NAV kan løse med tilgangskontroller.
Det oppstår en liten digresjon om modularisering av innlogging i NAV for å bedre understøtte innlogging med f.eks. MFA og SSO, og Werner nevner at om vi planlegger å støtte OIDC-innlogging at vi bør også se på om NAV kan bruke LOA-informasjon (Levels of Assurance) fra OIDC til å styre hvilke tilganger som blir gitt i NAV.
UiA
Øyvind har akkurat erstattet Rune Kittelsen i gruppen, og har ikke satt veldig dypt inn i disse problemstillingen enda. Øyvind beskriver at de har mye samme scenario som UiT beskriver, og kunne kanskje også tenke seg å gi A/V-teknikere muligheten til å selv registrere eget utstyr i NAV.
Underveis i møtet har vlan_auth
-modus i PortAdmin blitt diskutert, og UiA var nok ikke klar over at dette var en mulighet, og er interessert i å finne ut mer.
Vi fastslår at det er på sin plass å styrke NAVs dokumentasjon her, da denne muligheten er underkommunisert av eksisterende dokumentasjon.
I sammen slengen nevnes at det visstnok skal være mulig i PortAdmin å sette VLAN på porter som ellers ikke er tillatt på trunk, og da får man en situasjon uten konnektivitet. Dette er kanskje mest en feil i selve switcheconfigen (et VLAN er konfigurert inn, men ikke tillatt på trunk), men PortAdmin burde (med NAVs data) være i stand til å se at et VLAN ikke har noen vei ut av en boks, og at det derfor ikke gir noen mening å tillate å velge et slikt VLAN.
AKSJON: Det bør verifiseres at dette er tilfelle i PortAdmin, og i så fall registreres som et issue som bør fikses.
NTNU
Ønsker faktisk færrest mulig begrensninger på hva som vises i NAV - alle får se det meste. Mest opptatt av at Add option to restrict PortAdmin users to only setting port descriptions #3298 kan implementeres, for begrensning av hvilke endringer en bruker har lov til å gjøre.
Diskusjon rundt spørsmål i #1046
Utviklerteamet har lagt igjen en del spørsmål i Authorization based on users organizational affiliation #1046. Vi gikk gjennom de som ikke allerede var besvart under runden rundt bordet.
- Det ser ut til å være bred enighet om at all tilgang basert på organisasjonstilhørighet skal forstås som at om man er medlem av organisasjon
X
, så er man også implisitt medlem av alle underorganisasjoner tilX
. - API og API-tokens holdes utenfor denne kravspesifikasjonen. Når man først deler ut et API-token til noen, så er de gitt et høyt nivå av tilgang og man praktiserer “frihet under ansvar”.
- Ingen er foreløpig interessert i å gjøre begrensninger i Machine Tracker-søk (man kan allerede helt fjerne adgangen til Machine Tracker).
- Det er ingen tvingende behov for å gjøre noe med Reports. Brukere kan ikke lage egne rapporter, og admin kan styre hvem som har tilgang til hvilke rapporter med eksisterende
web_access
-privilegier.- Det dukket derimot opp en idé om at NAV kunne få et grensesnitt for å enklere tildele rettigheter til enkeltrapporter, ved utlisting av rapportnavn, fremfor at admin må rote med kompliserte regulære uttrykk og
web_access
-privilegier.AKSJON: Dev-teamet registrerer et issue i NAV-trackere på denne idéen.
- Ingen ser foreløpig behov for mer fingranulert tilgang til subnet matrix eller IPAM.
- Subnet matrix viser uansett ikke mye hemmelig.
- Tilgang til IPAM vil uansett være begrenset til en indre kjerne i nettdriftsorganisasjonen.
- Ingen ser behov for å gjøre endringer i Alert Profiles.
- Det var ukjent for alle at man kan styre tilganger til hvilke alarmer brukere har tilgang til å få varsling om. Dessuten regnes mye av Alert Profiles som “svart magi”, og folk har ikke lyst til å røre det. Bruk Argus i stedet!
- UiT mener å ha observerte at rettigheten
alert_by_sms
påvirker andre varslingskanaler enn bare SMS. Dersom dette stemmer, er det å anse som en bug. Rettigheten fins fra gammelt av: Den gangen dagens SMS-varslingsmotor ble skrevet, kostet det minst en krone, i noen tilfeller mer, for hver sendte SMS, så man ønsket å kunne begrense hvem som hadde lov til å abonnere på SMS-varsler.AKSJON: Dev-teamet undersøker hvor rettigheten
alert_by_sms
faktisk er i bruk i NAV-koden. Dersom noe tyder på at denne brukes til noe annet enn SMS-varsling, så må det opprettes et issue. Ellers må UiT rapportere problemet selv neste gang de opplever det.
Avslutningsvis
Det er tydelig fra diskusjonen og underlagsmaterialet at det allerede er vanskelig å skaffe seg en god oversikt over hvilke muligheter man allerede har i NAV til å begrense brukernes tilganger. Morten foreslår at det bør opprettes en samleside for tilgangsstyring i NAVs dokumentasjon, som gir en oversikt over all dokumentasjon som fins på området fra før, men også at manglende dokumentasjon legges til og dårlig dokumentasjon forbedres.
AKSJON: Dev-teamet lager et issue i NAV-trackeren om å lage en slik samleside i dokumentasjonen.
AKSJON: Dev-teamet dokumenterer de ønskene og scope-begrensningen som er fremkommet i dagens møte i issue #1046.