Onboarding

Altinn Downloader overvåker virksomhetens digitale innboks i Altinn og leverer brev og vedlegg automatisk til en droppsone i deres eget Azure-miljø. Tjenesten driftes av leverandøren via Azure Lighthouse, uten at data forlater miljøet deres. Dette dokumentet beskriver hele onboarding-løpet, fra signert avtale til verifisert leveranse.

Onboarding kort oppsummert:

1. Opprette en tom ressursgruppe, registrere ressurstilbyderne og godkjenne Azure Lighthouse-delegeringen
2. Tildele Altinn-roller til medarbeiderne som skal logge inn
3. Gjennomføre den første innloggingen med BankID på sikkerhetsnivå 4

Forutsetninger

Dette må være på plass hos dere:

1. Azure-abonnement: et aktivt abonnement, med Norway East som anbefalt region for datalagring i Norge. Infrastrukturen tjenesten kjører på opprettes i dette abonnementet og eies av dere, og Azure-forbruket faktureres av Microsoft direkte til dere. Forbruket inngår ikke i leverandørens tjenestepris. Logging og overvåking belaster ikke abonnementet: telemetrien sendes til leverandørens sentrale overvåkingsmiljø og dekkes av leverandøren.
2. Én tom ressursgruppe som delegeres via Azure Lighthouse: dere oppretter en tom ressursgruppe i abonnementet og delegerer den med den ferdige delegeringsmalen fra leverandøren. Delegeringen omfatter kun denne ressursgruppen, aldri hele abonnementet. Virksomheter som ønsker full isolasjon (typisk med landing zones) oppretter et eget, dedikert abonnement og legger ressursgruppen der. Godkjenningen av delegeringen krever en konto med eierrolle på abonnementet. Policyer som arves inn i abonnementet må tillate tjenestens ressurstyper i valgt region. I et nytt eller dedikert abonnement må dere også registrere ressurstilbyderne tjenesten bygger på, se steg 2 under.
3. Utpekte medarbeidere for innlogging: en liten gruppe som kan bruke BankID på sikkerhetsnivå 4 og har nødvendige Altinn-roller, typisk daglig leder, for alle organisasjonsnumre tjenesten skal behandle. Rollene tildeles i Altinn før den første innloggingen.
4. Mottak av filene: et system eller en rutine som henter filene fra droppsonen innen den avtalte oppbevaringsperioden. Videre behandling skjer i deres egne systemer.
5. Databehandleravtale: signert før persondata behandles.

Løpet steg for steg

1. Avtaler signeres

Tjenesteavtale og databehandleravtale signeres. Dere utpeker samtidig medarbeiderne som skal håndtere innloggingen (se forutsetning 3).

Utføres av: dere og leverandøren i fellesskap.

2. Delegert ressursgruppe etableres

Dere oppretter en tom ressursgruppe og godkjenner Azure Lighthouse-delegeringen av den med malen dere får fra leverandøren. Delegeringen gir leverandøren tilgang til å rulle ut, oppgradere og drifte applikasjonen i denne ene ressursgruppen, men kan teknisk ikke omfatte tilgang til innholdet (post, vedlegg, hemmeligheter). Ingen annen tilgang eller rolletildeling trengs fra deres side.

I samme runde registrerer dere ressurstilbyderne tjenesten bygger på, én gang per abonnement. Registreringen krever rettigheter på abonnementsnivå, som delegeringen ikke omfatter, så leverandøren kan ikke gjøre dette for dere; uten registreringen stopper utrullingen midtveis. Et nytt eller dedikert abonnement har ingen tilbydere registrert fra før, mens et abonnement som allerede kjører arbeidslast normalt har de fleste.

Registreringen gjøres i portalen (abonnementet, Innstillinger, Ressurstilbydere) eller med én kommando per tilbyder:

az provider register --namespace Microsoft.App
az provider register --namespace Microsoft.KeyVault
az provider register --namespace Microsoft.Storage
az provider register --namespace Microsoft.ManagedIdentity

Utføres av: dere, med mal og veiledning fra leverandøren.

3. Utrulling

Leverandøren ruller ut infrastruktur og applikasjon i den delegerte ressursgruppen: Key Vault, lagring med droppsone og leveringslogg, innloggings-app og worker. Signeringsnøkkelen for innloggingen genereres i leverandørens utrullingsjobb og skrives inn i deres Key Vault, som fra da av holder den eneste varige kopien. Utenfor miljøet deres finnes nøkkelen bare så lenge den ene utrullingsjobben kjører; den lagres aldri hos leverandøren. Fra dette punktet holdes utrullingen automatisk oppdatert, uten videre involvering fra dere.

Utføres av: leverandøren.

4. Tilkobling til ID-porten og Altinn

Leverandøren kobler utrullingen til sin godkjente ID-porten-integrasjon. Tilgangen til Altinns API-er er allerede på plass på integrasjonen, så ingenting registreres eller bestilles per kunde. Dere tildeler nødvendige Altinn-roller til de utpekte medarbeiderne, siden tjenesten henter post med tilgangen til den som logger inn.

Utføres av: leverandøren, med rolletildeling fra dere.

5. Første innlogging

En av de utpekte medarbeiderne åpner innloggings-appen og logger inn med BankID på sikkerhetsnivå 4. Innloggingen gir tjenesten tilgangen den trenger, og tilgangen fornyes automatisk frem til neste periodiske innlogging, omtrent hver tredje måned, etter varsel.

Utføres av: dere.

6. Verifisering

Leverandøren bekrefter at tjenesten kjører og at post lander i droppsonen: hvert brev leveres som fil med en tilhørende metadatafil, og slettes automatisk fra droppsonen etter den avtalte oppbevaringsperioden. Dere bekrefter at deres egne systemer henter filene innen perioden.

Utføres av: dere og leverandøren i fellesskap.

7. Overlevering til drift

Overvåking og varsling er aktiv fra første dag. Leverandøren gjennomfører samtidig en øvelse på re-autentiseringen sammen med de utpekte medarbeiderne, slik at flyten er kjent før det første reelle varselet kommer.

Utføres av: leverandøren, med deltakelse fra dere.

Etter onboarding

Fra dette punktet er tjenesten i normal drift.

Leverandøren:

• Overvåker tjenesten og varsler når noe krever handling
• Oppgraderer applikasjonen løpende, uten involvering fra dere
• Håndterer feil og avvik

Dere:

• Henter filene fra droppsonen og behandler posten i egne systemer
• Gjennomfører den periodiske innloggingen når dere blir varslet
• Eier infrastrukturen og dekker Azure-forbruket i eget abonnement