Dette kan være krevende når ikke alle har brukerkonto, Microsoft 365-lisens eller tilgang til virksomhetens interne systemer. Mange arbeider ute i felt, er innleid eller bruker først og fremst mobiltelefon.
Jeg har derfor arbeidet med et konsept for en identitetsminimerende varslingskanal i Microsoft Azure. Målet er å gjøre det mulig å sende inn et varsel uten innlogging, kontaktopplysninger eller tilgang til virksomhetens Microsoft-miljø.
Status for konseptet: En avgrenset teknisk utprøving er gjennomført i et separat Azure-testmiljø. Den demonstrerer innsending uten konto, kontrollert mottak, avgrensede tilganger og etablering med Terraform. Løsningen er ikke et ferdig standardprodukt. Før produksjonsbruk må den tilpasses virksomhetens krav, risikovurderes, sikkerhetstestes og knyttes til dokumenterte rutiner for behandling av varsler.
Et konkret behov
Utgangspunktet var en virksomhet som ønsket en tilgjengelig varslingskanal knyttet til arbeidsmiljøutvalgets arbeid. Ikke alle potensielle brukere hadde Microsoft 365-lisens, Entra-konto eller firmamaskin. En løsning som krevde innlogging i SharePoint, Teams eller et annet internt system, ville derfor ikke være tilgjengelig for alle.
Varslingskanalen måtte kunne åpnes direkte fra en mobiltelefon, for eksempel via en nettadresse eller QR-kode. Samtidig skulle den offentlig tilgjengelige delen eksponere minst mulig av virksomhetens interne infrastruktur.
Anonymitet er ikke en innstilling
Det er fristende å beskrive en løsning som anonym dersom skjemaet ikke spør etter navn eller e-postadresse. I praksis er problemstillingen mer sammensatt.
Et varsel kan inneholde fritekst, hendelser, tidspunkt og andre opplysninger som indirekte gjør det mulig å forstå hvem varsleren er. Nettverks-, plattform- og infrastrukturdata kan også gi muligheter for sammenstilling eller identifisering.
Jeg bruker derfor begrepet identitetsminimerende varslingskanal. Det betyr at løsningen er utformet for ikke å be om, opprette eller lagre en identitet når dette ikke er nødvendig. Det er mer presist enn å love at anonymitet kan garanteres i enhver situasjon.
Minst mulig informasjon
Et sentralt prinsipp er at løsningen bare skal ta imot opplysninger som er nødvendige for formålet. Den første tekniske utprøvingen omfatter derfor et begrenset, mobilvennlig skjema uten:
- innlogging eller krav om Microsoft 365- og Entra-tilgang
- navn, e-postadresse eller telefonnummer
- vedlegg eller automatisk opprettelse av en brukeridentitet
- direkte kobling til interne samarbeidsflater
Innholdet valideres på serversiden, og det settes tydelige grenser for hvilke data og hvor store datamengder løsningen kan motta. Når et varsel registreres, får det en tilfeldig og ugjennomsiktig saksreferanse som ikke inneholder løpenummer, tidspunkt eller informasjon om virksomheten eller varsleren.
Skille mellom offentlig mottak og intern behandling
Den offentlige varslingskanalen bør ikke være det samme systemet som virksomhetens interne saksarkiv.
Forenklet informasjonsflyt: Mobil eller QR-kode → offentlig varslingsskjema → kontrollert mottak → internt saksområde.
Den offentlige tjenesten skal kunne motta et nytt varsel, men ikke liste eller lese tidligere varsler, endre eller slette historikk, hente interne vurderinger eller få tilgang til virksomhetens øvrige systemer.
Dette reduserer konsekvensene dersom den offentlig tilgjengelige delen skulle bli utsatt for feil, misbruk eller kompromittering. Varsler kan deretter flyttes gjennom en kontrollert tillitsgrense til et internt område der autoriserte personer behandler saken.
Sikkerhet som en del av arkitekturen
Konseptet benytter Azure-tjenester og administrerte identiteter. Applikasjonen kan dermed få en avgrenset teknisk tilgang uten at passord eller tilgangsnøkler bygges inn i kildekoden.
Noen av prinsippene i referansearkitekturen er:
- minst mulige tilganger og separate tillitssoner
- kontrollert og begrenset datamottak
- serversidevalidering som avviser ukjent innhold
- ingen offentlig funksjon for å lese eller liste varsler
- ingen ukryptert reserveflyt
- syntetiske testdata og repeterbar etablering med Terraform
Terraform gjør det mulig å beskrive infrastrukturen som kode. Det gir et bedre grunnlag for dokumentasjon, gjennomgang og kontroll enn om alle komponenter opprettes manuelt. En ny installasjon kan bygges på samme dokumenterte grunnlag, mens innstillinger og sikkerhetsnivå tilpasses virksomhetens behov.
Kan varsleren følge saken?
En identitetsminimerende kanal skaper et praktisk dilemma: Hvordan kan virksomheten stille oppfølgingsspørsmål uten å kjenne varslerens identitet eller kontaktinformasjon?
En mulig videreutvikling er en separat dialogfunksjon der varsleren får en hemmelig saksnøkkel. Denne kan brukes til å kontrollere om det er publisert et svar, uten konto eller registrert kontaktinformasjon. Dette er utredet som en mulig videre fase, men inngår ikke i den første tekniske utprøvingen.
En slik dialog må være strengt adskilt fra interne saksnotater. Når virksomheten ønsker å svare, bør det opprettes en ny og minimert melding som eksplisitt godkjennes for publisering. Interne vurderinger, identiteter, originalrapporten og tekniske metadata skal ikke automatisk bli synlige.
Kontroll innenfor virksomhetens egen sfære
I dette konseptet var et viktig premiss at løsningen skulle kunne etableres i virksomhetens egen Microsoft-tenant og Azure-subscription. Varslene skulle ikke uten videre behandles i infrastrukturen til en ekstern varslingsleverandør.
Dette gir virksomheten kontroll over arkitektur, lagring, tekniske identiteter, tilgangsstyring, logging og sletting. Det reduserer antallet eksterne aktører som må betros sensitiv informasjon, men flytter samtidig et tydelig ansvar til virksomheten selv.
Egen infrastruktur er ikke automatisk sikrere. Virksomheten må ha kompetanse, kapasitet og dokumenterte rutiner for drift, overvåking, oppdatering og hendelseshåndtering. Administrative roller og logger må også vurderes fordi de kan gi tilgang eller bidra til indirekte identifisering.
En ekstern tjeneste kan gi større organisatorisk avstand til arbeidsgiveren og tilgang til et spesialisert sikkerhetsmiljø. Til gjengjeld må virksomheten kunne kontrollere hvordan leverandøren og eventuelle underleverandører behandler informasjonen.
Det sentrale spørsmålet er ikke bare egen eller ekstern løsning: Hvor skal tilliten plasseres, hvem skal kunne få tilgang, og hvem har evne og ansvar til å beskytte informasjonen over tid?
Teknologien løser ikke hele varslingsprosessen
En teknisk varslingskanal er bare én del av virksomhetens samlede varslingsordning. Den må inngå i dokumenterte rutiner for:
- mottak, behandling, habilitet og tilgangsstyring
- informasjon til varsleren og oppfølging av saken
- lagring, sletting og håndtering av personopplysninger
- informasjonssikkerhet, beredskap og relevant dokumentasjonsplikt
Teknologien kan redusere unødvendig innsamling av identitetsopplysninger og etablere tydelige sikkerhetsgrenser. Den kan ikke alene garantere anonymitet eller sikre at virksomhetens organisatoriske behandling er korrekt.
Fra teknisk utprøving til referansearkitektur
Prosjektet begynte med et konkret behov, men problemstillingen er relevant for flere typer virksomheter. Den tekniske utprøvingen danner grunnlag for en dokumentert referansearkitektur. Når konseptet er ferdig evaluert, kan prinsippene brukes som utgangspunkt for kundetilpassede implementasjoner.
Det viktigste er å behandle anonymitet, personvern og informasjonssikkerhet som grunnleggende arkitekturkrav – ikke som funksjoner som legges til etter at løsningen er bygget.
Har dere en digital tjeneste med tilsvarende krav? →