Skip to main content

🔐 Tilgangsstyring

MĂ„lbilde for tilgangsstyring pĂ„ SKIP​

Vi Þnsker Ä tilby plattformfunksjonalitet som gjÞr det enkelt for teamene pÄ SKIP Ä levere sikre tjenester, basert pÄ prinsipper om least privilege og zero trust, samt bruk av nasjonale felleskomponenter og moderne autentiserings- og autorisasjonsmekanismer. Dette innebÊrer blant annet:

  • Klientregistrering mot relevante identitetstilbydere, som for eksempel Entra ID og nasjonale felleskomponenter, uten bruk av virksomhetssertifikat eller applikasjonsnĂŠre hemmeligheter
  • Innloggingsflyter, sesjonshĂ„ndtering og validering av OAuth-tokens
  • Grovkornet tilgangsstyring basert pĂ„ claims-validering
  • Finkornet tilgangsstyring basert pĂ„ Open Policy Agent
  • Finkornede nettverksregler og sikker kommunikasjon med andre SKIP-applikasjoner basert pĂ„ SPIFFE
  • Token exchange for bevaring av sluttbrukerkontekst i tjeneste-til-tjeneste-kommunikasjon

En fordel med Ä tilby slik funksjonaliteten pÄ plattformnivÄ er at de samme mekanismene kan brukes, pÄ samme mÄte, uavhengig av applikasjonen den skal beskytte. Dette gir Kartverket mÄlbarhet og konsistens i hvordan tilgangsstyring hÄndteres, uavhengig av applikasjon, team eller divisjon. Innebygd tilgangsstyringsfunksjonalitet i plattformen hjelper oss Ä opprettholde et hÞyt minimumsnivÄ av sikkerhet i alle applikasjoner.

Funksjonalitet vi tilbyr​

  • Dokumentasjon og anbefalinger av relevante identitetstilbydere
  • Klientregistrering mot relevante identitetstilbydere
  • Ztoperator: en Kubernetes-ressurs for innlogging, sesjonshĂ„ndtering og claims-validering
  • SPIFFE: finkornet nettverkstilgangsstyring og sikker kommunikasjon innad i et Kubernetes-cluster basert pĂ„ SPIFFE-identiteter

Funksjonalitet vi planlegger Ă„ tilby i nĂŠr fremtid​

  • Token exchange: bevaring av sluttbrukerkontekst i tjeneste-til-tjeneste-kommunikasjon
  • Open Policy Agent: finkornet tilgangsstyring

Annen funksjonalitet vi vurderer Ă„ tilby pĂ„ sikt​

  • Tilby grensesnitt for interne maskin-til-maskin-tokens, istedenfor Microsoft Entra ID

đŸ”„ Plattform- vs. applikasjonssikkerhet​

Plattformfunksjonalitet kan, men bÞr ikke nÞdvendigvis, erstatte all tilsvarende funksjonalitet i de underliggende applikasjonene. Noen sikkerhetsmekanismer, som f.eks utfÞrelse av OAuth-innloggingsflyt eller kryptering av nettverkstrafikk, er de fleste team tilfreds med Ä la plattformen hÄndtere i sin helhet. Validering av tokens og mer detaljert tilgangsstyring er derimot noe som med fordel kan gjÞres bÄde av plattformen og av applikassjonskoden selv. Vi anbefaler hvert enkelt team, gjerne i samarbeid med Team Tilgangsstyring, Ä vurdere hvilke plattform- og applikasjonsmekanismer som passer best for deres behov.

PÄ generelt grunnlag anbefaler vi Ä ha flere lag med sikkerhet, og dermed implementere egnede sikkerhetsmekanismer og validering bÄde i plattformen og i applikasjonskoden.

Token-validering og grovkornet tilgangsstyring i Ztoperator vs. applikasjonskode​

Med bruk av test-authpolicy-action er det mulig Ä teste i CI/CD at en Ztoperator-AuthPolicy er konfigurert til Ä utfÞre deny/redirect/allow slik som forventet. Det eksisterer derimot ikke noe testverktÞy som tester selve applikasjonskoden sitt samspill med Ztoperator. Basert pÄ dette anbefaler vi at teamene selv tar stilling til hvorvidt de er komfortable med Ä kun stole pÄ Ztoperator for token-validering, eller om de Þnsker Ä implementere token-validering i applikasjonskoden i tillegg.

SPIFFE vs. bruk av tokens for tjeneste-til-tjeneste-kommunikasjon innad i Kubernetes-cluster​

Plattformen garanterer for at ondsinnede aktÞrer ikke kan anskaffe seg eller forfalske SPIFFE-identiteter. Det er derfor mulig Ä tilgangsstyre kommunikasjon mellom interne tjenester pÄ SKIP ved kun bruk av SPIFFE-identiteter. Derimot er det en realitet at vi ikke tilbyr noe god mÄte Ä teste eller verifisere dette pÄ en applikasjonsnÊr mÄte, f.eks som del av CI/CD. Med dette tatt i betrakning anbefale vi Ä bruke SPIFFE i kombinasjon med én eller flere av fÞlgende mekanismer:

  • Validering av X-Forwarded-Client-Cert-header i applikasjonen, som inneholder SPIFFE-identiteten til klienten
  • Bruk av maskinidentiteter med tokens, f.eks Microsoft Entra ID