Systemoversikt

Digital Mailroom er et .NET-basert, containerisert system som kjører som Azure Container Apps i tenantens eget Azure-abonnement. Det autentiserer på vegne av virksomheten, henter inn digital post fra Altinn 3, i dag den eneste kildekanalen, og leverer brev og vedlegg til en droppsone i samme miljø. All behandling skjer der dataene hører hjemme, hos tenanten selv.

Komponenter

Systemet består av noen få komponenter. I tenantens eget Azure-abonnement:

• Innloggings-app: kjører innloggingsflyten og holder tilgangen ved like.
• Worker: kjører pipelinen som henter inn post og leverer den til droppsonen.
• Key Vault: lagrer signeringsnøkkel og tokens.
• Storage: droppsonen for leverte filer, og leveringsloggen.

Hos driftspartneren:

• Sentralt overvåkingsmiljø (Azure Monitor): mottar logger, metrikker og sporing fra alle utrullinger, slik at logging aldri belaster deres Azure-kostnader. Telemetrien er avgrenset til tekniske driftsdata, se Personvern og datahåndtering.

Komponentene deler Key Vault og Storage, men kjører hver under sin egen managed identity med kun de rettighetene de trenger. Autentiserings- og leveringsflyten er beskrevet i detalj i Slik fungerer det.

De to planene

Den sentrale designbegrensningen er at forretningsdata aldri forlater tenanten: post, vedlegg, tokens, leveringsloggen og droppsonen blir hos dere.

Telemetrien samles i driftspartnerens sentrale overvåkingsmiljø, som også driver varslingen for hele tjenesten. Fra telemetrien avledes i tillegg aggregerte telleverdier til et sentralt rapporteringsregister: antall leverte vedlegg per dag, mottakerorganisasjon og avsender. Avsenderen er tjenesteeierens kode fra Altinn, aldri en person, og verken innhold eller personopplysninger kan hentes denne veien. Se Vanlige spørsmål om hvilken innsikt dere får ut av dette.

Teknologioversikt

Utrullingsmodell

Systemet rulles ut per tenant, i tenantens eget Azure-abonnement og fra samme container-image. Driftspartneren administrerer utrullingen via Azure Lighthouse, så tenanten trenger ikke egne Azure-operatører. Ingen kode eller data deles mellom tenanters utrullinger.

Tilgangen følger to plan: stående tilgang stopper ved kontrollplanet, mens dataplanet krever tidsavgrenset rettighetsheving med godkjenning og logg. Deploy-identiteten genererer signeringsnøkkelen i utrullingsjobben, skriver den inn i tenantens Key Vault og registrerer kun den offentlige delen hos Digdir. Key Vault holder den eneste varige kopien av privatnøkkelen; utenfor tenanten finnes den bare så lenge den ene utrullingsjobben kjører. Fleet-overvåkingen leser telemetrien i driftspartnerens eget sentrale overvåkingsmiljø med leserettigheter (Monitoring Reader) der; Lighthouse-delegeringen brukes til å drifte selve tjenesten.

Sikkerhetsprinsipper

• Ingen egress av forretningsdata: post, vedlegg og tokens forlater aldri tenanten. Telemetrien som sendes til det sentrale overvåkingsmiljøet er avgrenset til tekniske driftsdata, uten innhold og uten filnavn.
• Minimal tilgang: hver app har sin egen managed identity med kun de rollene den trenger, slik at en kompromittert komponent ikke når mer enn sitt eget.
• Nettverksisolasjon (tilvalg): med tilvalget privateNetworking aktivert ligger dataplanet bak et dedikert virtuelt nettverk, og Storage og Key Vault nås kun via private endpoints. Uten tilvalget, som er standard også i produksjon, brukes RBAC-sikrede offentlige endepunkter.
• Menneskebakket sesjon: sensitiv post krever BankID nivå 4. Ingen M2M-snarvei finnes for dette sikkerhetsnivået.
• Idempotent levering: leveringsloggen hindrer dobbeltlevering selv ved restart eller nettverksfeil.

Neste steg

• Slik fungerer det: pipelinen og autentiseringsflyten i detalj.
• Droppsone: hva som leveres og format.
• Personvern og datahåndtering: hvilke opplysninger som behandles, og hvor.