Personvern og datahåndtering

Denne siden er skrevet for dere som skal vurdere tjenesten i en sikkerhets- eller GDPR-gjennomgang: hvilke opplysninger som behandles, hvor hver opplysning er synlig, og hva som aldri forlater deres eget miljø. Den utfyller Systemoversikt og Droppsone, og alle påstandene her er hentet fra den faktiske implementasjonen.

Hvilke opplysninger behandles

Posten tjenesten henter er korrespondanse fra det offentlige, og innholdet kan inneholde personopplysninger, for eksempel i inkasso- eller forvaltningssaker. Selve innholdet behandles derfor mest restriktivt av alt tjenesten rører ved.

I tillegg behandler tjenesten personopplysninger om én av deres egne medarbeidere: den som logger inn mot ID-porten. Innloggingen skjer med personlig BankID, og tokenene den gir, inkludert id-tokenet som bærer medarbeiderens fødselsnummer, lagres i Key Vault i deres eget miljø for autentiseringsformål. Denne lagringen er nødvendig for tjenesten: uten tokenene kan ikke innloggingen holdes i live mellom kjøringene, og hver posthenting ville krevd en ny BankID-innlogging.

Merk at filnavnet settes av avsenderen og i seg selv kan røpe saksinformasjon. Filstier behandles derfor som forretningsdata: de finnes bare i droppsonen, metadatafilen og leveringsloggen i deres eget miljø, og skrives aldri til telemetri.

Datastrømmen, steg for steg

1. Oppdag: workeren spør Dialogporten om ny post for deres organisasjon. Kun metadata hentes: avsenderkode, tekniske ID-er og filnavn.
2. Filtrer: post som ikke matcher avsender-, filtype- eller datofilteret forkastes før noe innhold hentes. Avviste elementer verken lagres eller registreres, de blir liggende urørt i Altinn.
3. Hent: vedlegget åpnes som en datastrøm fra Altinn Correspondence.
4. Lever: strømmen skrives direkte til droppsonen i deres egen lagringskonto, sammen med metadatafilen.
5. Registrer: leveringsloggen får en rad med status, tidspunkter og filsti. Innholdet registreres aldri.

Ingen mellomlagring

Ved levering til droppsonen, som er standardoppsettet, strømmes innholdet direkte fra Altinn til deres egen lagringskonto. Det finnes ingen kø, database eller annet mellomlager på veien, og ingenting passerer driftspartnerens infrastruktur: innholdet finnes kun i transitt (TLS-kryptert) og i droppsonen.

To leveringsvarianter innebærer en kortvarig, lokal buffer, fortsatt inne i deres eget miljø:

• Levering til filshare: Azure Files krever at filstørrelsen er kjent før opplasting, så workeren bufrer filen kortvarig på sin egen flyktige disk og sletter bufferen umiddelbart etter opplastingen.
• Utpakking av zip-vedlegg (valgfritt, avslått som standard): arkivet bufres tilsvarende kortvarig for å kunne leses.

I begge tilfeller skjer bufringen på workerens egen disk i deres miljø, uten varig lagring, og aldri hos driftspartneren.

Telemetri og personopplysninger

Telemetri, det vil si logger, metrikker og sporing, sendes til driftspartnerens sentrale overvåkingsmiljø. Det gir samlet overvåking og varsling for hele tjenesten, og det betyr at loggvolumet aldri belaster deres Azure-kostnader.

Fordi telemetrien krysser grensen ut av deres miljø, er den bevisst avgrenset til tekniske driftsdata. Tre regler gjelder uten unntak, og er låst med automatiske tester:

• Hemmeligheter og tokens skrives aldri til telemetri. Ved feilsøking logges kun et teknisk fingeravtrykk av tokenet.
• Filnavn og filstier skrives aldri til telemetri. Loggene identifiserer et vedlegg kun med tekniske ID-er; selve filnavnet finnes bare i droppsonen, metadatafilen og leveringsloggen i deres eget miljø.
• Metrikk-etiketter inneholder kun avgrensede forretningsverdier: organisasjonsnummer, avsenderkode og feilkategori. Aldri filnavn, titler eller personopplysninger.

Telemetrien består dermed av tekniske ID-er, organisasjonsnummer, avsenderkoder, feilkategorier, tidsforbruk og tekniske feilmeldinger fra Altinn og Azure. Innholdet i posten kan aldri nå telemetrien, for det leses aldri inn i loggingen i det hele tatt. I tillegg henter driftspartneren aggregerte telleverdier til rapportering: antall leverte vedlegg per dag, mottakerorganisasjon og avsenderkode. Se Vanlige spørsmål om hvilken rapportering dere får ut av dette.

Lagring og sletting

Ved avvikling blir alle forretningsdata stående i deres eget miljø. Driftspartneren fjerner applikasjonen og sin egen delegering, men sletter aldri innholdet uten at dere har besluttet det. Telemetrien hos driftspartneren utløper av seg selv etter oppbevaringstiden. Se Leveransemodell.

Nettverk og tilgang

Som standard, uavhengig av miljø, er lagringskontoen og Key Vault tilgjengelige på sine offentlige endepunkter, sikret med TLS og rollebasert tilgangskontroll i Entra ID: kun identiteter som er tildelt en rolle når frem. Nettverksisolasjon er et tilvalg (privateNetworking) som avtales per utrulling. Med tilvalget aktivert ligger dataplanet bak et dedikert virtuelt nettverk, lagringskontoen har offentlig tilgang avslått og nås kun via private endpoints, og Key Vault har brannmur som avviser offentlig trafikk. En produksjonsutrulling har ikke tilvalget automatisk; se Sikkerhetsprinsipper.

Innloggings-appen er i begge oppsett utrullingens eneste offentlig eksponerte applikasjonsendepunkt; det kreves for ID-porten-innloggingen, og selve innloggingen krever BankID på sikkerhetsnivå 4.

Det som krysser grensen mellom deres miljø og driftspartneren, er:

• Inn: container-images fra driftspartnerens registry ved utrulling og oppgradering.
• Ut: telemetri (logger, metrikker og sporing) til driftspartnerens sentrale overvåkingsmiljø, avgrenset til tekniske driftsdata som beskrevet over, og de aggregerte telleverdiene til rapportering.
• Drift via Azure Lighthouse: delegeringen driftspartneren administrerer tjenesten gjennom omfatter kun kontrollplanet; tilgang til post, vedlegg og hemmeligheter kan teknisk ikke delegeres på tvers av organisasjoner. Se Leveransemodell.

Behandlingsansvar

Dere er behandlingsansvarlig for posten, og driftspartneren er databehandler. Forholdet reguleres av en databehandleravtale som signeres før persondata behandles. Se Vanlige spørsmål og Leveransemodell.