Produkt

Leveransemodell

Hvordan tjenesten leveres som managed service via Azure Lighthouse, hvilke forutsetninger som må være på plass, og hvem som har ansvar for hva.

Digital Mailroom leveres som en administrert tjeneste i deres eget Azure-miljø. Dere eier miljøet og dataene, vi drifter tjenesten. Denne siden oppsummerer leveransemodellen, hva dere må ha på plass før oppstart, og hvordan ansvaret er fordelt mellom leverandør og kunde.

Slik leveres tjenesten

Hver kunde får en dedikert utrulling i sitt eget Azure-abonnement. Ingen infrastruktur deles med andre kunder, og all post, alle vedlegg, nøkler og tokens lagres utelukkende i deres eget miljø. Ingenting sendes ut til leverandøren eller tredjepart.

Driften skjer via Azure Lighthouse, Microsofts mekanisme for delegert administrasjon på tvers av organisasjoner:

  • Dere delegerer én ressursgruppe til leverandørens driftsorganisasjon, aldri hele abonnementet. Virksomheter som ønsker full isolasjon legger ressursgruppen i et eget, dedikert abonnement. Delegeringen gir leverandøren tilgang til å rulle ut, oppgradere og drifte applikasjonen. Logger og metrikker leses ikke fra deres miljø: telemetrien sendes til leverandørens sentrale overvåkingsmiljø, avgrenset til tekniske driftsdata, se Personvern og datahåndtering.
  • Delegeringen omfatter kun kontrollplanet (administrasjon av ressursene). Tilgang til selve innholdet, altså post, vedlegg og hemmeligheter, er ikke en del av delegeringen. Azure Lighthouse kan teknisk ikke delegere slike dataplan-rettigheter på tvers av organisasjoner, så skillet er håndhevet av plattformen, ikke bare av rutiner.
  • Leverandøren har ingen brukerkontoer eller gjestebrukere i deres miljø. All tilgang går via delegeringen, som dere til enhver tid kan se i Azure-portalen og selv trekke tilbake.

Hva Lighthouse er, nøyaktig hvilke rettigheter delegeringen gir, og hvordan dere inspiserer og fjerner den selv, er beskrevet i Azure Lighthouse, med lenker til Microsofts egen dokumentasjon for uavhengig etterprøving.

Utrulling og oppgradering skjer automatisk fra leverandørens leveransepipeline: alle kunder kjører samme versjon av applikasjonen, og nye versjoner rulles ut uten at dere trenger å foreta dere noe. Overvåking skjer via telemetri (logger, metrikker og varsler), og leverandøren feilsøker med utgangspunkt i telemetrien, ikke ved å åpne innholdet i posten.

Personvern og databehandleravtale

I personvernsammenheng er dere behandlingsansvarlig og leverandøren databehandler. Forholdet reguleres av en databehandleravtale som signeres før persondata behandles. Avtalen følger leverandørens standardmal og beskriver behandlingen, sikkerhetstiltakene, underdatabehandlere og kontaktpunkter i egne bilag.

  • Underdatabehandlere: leverandørens egne systemer oppbevarer ingen av deres personopplysninger, og avtalen lister eventuelle underdatabehandlere eksplisitt. Dere varsles skriftlig minst 30 dager før en ny tas i bruk, med rett til å komme med innsigelse. Microsoft Azure-tjenestene i deres eget abonnement leveres under deres egen avtale med Microsoft.
  • Avvik: brudd på personopplysningssikkerheten varsles dere uten ugrunnet opphold, og senest innen 48 timer etter at leverandøren fikk kjennskap til det, med informasjonen dere trenger for egen melding til Datatilsynet.
  • DPIA: skal dere gjennomføre en vurdering av personvernkonsekvenser, stiller leverandøren dokumentasjon og underlag til rådighet.

Se Personvern og datahåndtering for hvilke opplysninger som behandles og hvor, og Vanlige spørsmål om sikkerhet og GDPR.

Forutsetninger

Dette må være på plass hos dere for at tjenesten skal kunne leveres:

  1. Azure-abonnement: et aktivt abonnement, med Norway East som anbefalt region for datalagring i Norge.
  2. Én tom ressursgruppe som delegeres via Azure Lighthouse: dere oppretter en tom ressursgruppe og delegerer den med den ferdige delegeringsmalen fra leverandøren. Delegeringen omfatter kun ressursgruppen, aldri hele abonnementet. For virksomheter med landing zones er et dedikert abonnement med én delegert ressursgruppe det naturlige valget: det gir full separasjon fra øvrig infrastruktur og renere kostnadsoversikt. Godkjenningen av delegeringen krever en konto med eierrolle på abonnementet. Merk at policyer som arves inn i abonnementet (for eksempel tillatte regioner eller påkrevde tagger) også gjelder for utrullingen, og må tillate tjenestens ressurstyper i valgt region. I et nytt eller dedikert abonnement registrerer dere også ressurstilbyderne tjenesten bygger på; Onboarding har listen og kommandoene.
  3. Altinn-roller for medarbeiderne som skal logge inn: tjenesten henter post med tilgangen til den som logger inn, gjennom leverandørens godkjente ID-porten-integrasjon. Ingen registrering eller bestilling hos Altinn eller Digdir kreves fra deres side; dere tildeler kun nødvendige Altinn-roller, typisk daglig leder, for alle organisasjonsnumre tjenesten skal behandle.
  4. Utpekte medarbeidere for innlogging: en liten gruppe medarbeidere, med rollene fra punkt 3, som kan gjennomføre den periodiske re-autentiseringen med BankID på sikkerhetsnivå 4 (omtrent hver tredje måned, etter varsel).
  5. Mottak av filene: et system eller en rutine hos dere som henter filene fra droppsonen innen den avtalte oppbevaringsperioden. Videre behandling skjer i deres egne systemer, se Hva tjenesten ikke gjør.
  6. Databehandleravtale: signert før persondata behandles.

Utover delegeringen kreves ingen tilgang eller rolletildeling i deres miljø. Signeringsnøkkelen for innloggingen genereres i leverandørens utrullingsjobb og skrives inn i deres Key Vault, som holder den eneste varige kopien; utenfor miljøet deres finnes nøkkelen bare så lenge den ene utrullingsjobben kjører, og den lagres aldri hos leverandøren.

Merk at Azure-ressursene kjører i deres eget abonnement, så forbrukskostnadene for disse faktureres av Microsoft direkte til dere. Logging og overvåking er unntaket: telemetrien sendes til leverandørens sentrale overvåkingsmiljø, så loggvolumet belaster aldri deres Azure-kostnader.

Ansvarsmatrise

U = utfører, B = bistår.

Etablering

AktivitetLeverandørKunde
Opprette ressursgruppen som delegeres (eventuelt i et eget dedikert abonnement)BU
Godkjenne Azure Lighthouse-delegering (mal fra leverandøren)BU
Rulle ut infrastruktur og applikasjonU
Koble utrullingen til leverandørens ID-porten-integrasjonU
Tildele Altinn-roller til medarbeiderne som skal logge innBU
Gjennomføre første innlogging med BankID nivå 4BU
Verifisere leveransen ende til endeUB

Etableringsløpet er beskrevet steg for steg i Onboarding.

Drift

AktivitetLeverandørKunde
Overvåking, varsling og feilhåndteringU
Oppgradere til nye versjonerU
Gjennomføre periodisk re-autentisering med BankID etter varselU
Hente filer fra droppsonen innen oppbevaringsperiodenU
Videre behandling av posten i egne systemerU
Styre tilgang til droppsonen i eget miljøU
Dekke Azure-forbrukskostnader i eget abonnementU

Avvikling

AktivitetLeverandørKunde
Avinstallere applikasjonen og fjerne integrasjonenU
Fjerne Lighthouse-delegeringenUB
Beslutte videre håndtering av data i eget miljøU

Ved avvikling blir dataene stående i deres eget miljø. Leverandøren fjerner applikasjonen og sin egen delegering, men sletter aldri innholdet uten at dere har besluttet det.

Copyright © 2026