NAV referansegruppemøte om tilgangsstyring i NAV, 24. april 2025

NAV-ref Home

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

Møtet blir avholdt som videokonferanse vha. Zoom, fra kl. 12:00 til 15:00.

Morten ønsker velkommen på vegne av Sikt.

• Authorization based on users organizational affiliation #1046
• Add option to restrict PortAdmin users to only setting port descriptions #3298
• 'vlan_auth' mode i PortAdmin (dokumentasjon)

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.

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 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.

Ø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.

Ø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.

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 til X.
• 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.

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.