Tilgang og etterprøvbarhet

Et spørsmål vi ofte får i sikkerhetsvurderinger: kan leverandøren gi seg selv tilgang til å se dokumentene og personopplysningene i løsningen? Svaret er nei. Viktigere enn svaret er at dere ikke trenger å ta vårt ord for det: grensen håndheves av Microsofts plattform, enhver utvidelse krever deres egen godkjenning, og alt vi gjør logges i deres miljø, i logger dere eier. Denne siden forklarer hvordan, og er skrevet for dere som skal beslutte, og for compliance og revisor.

Posten ligger hos dere, og grensen ligger i plattformen

Brev, vedlegg og personopplysninger lagres kun i deres eget Azure-miljø og forlater det aldri. Vår drift skjer gjennom Azure Lighthouse, Microsofts egen mekanisme for delegert drift, og plattformen tillater ikke at roller som gir innsyn i filer eller hemmeligheter delegeres til en leverandør. Slike roller avvises av Azure allerede når delegeringen opprettes.

Innsyn i posten er dermed teknisk stengt gjennom driftstilgangen vår. Grensen ligger i Microsofts plattform og holder uavhengig av våre rutiner, våre ansatte og våre verktøy, og Microsofts egen dokumentasjon bekrefter den.

Tilgangen er låst til det dere har godkjent

Delegeringen opprettes ved at dere leser og godkjenner en mal der hver rettighet står oppført: hvem som får tilgang, til hva, og på hvilken ressursgruppe. Etter godkjenningen kan vi ikke legge til noe på egen hånd. Mer tilgang finnes bare én vei: vi må sende dere en ny mal, og en konto med eierrolle hos dere må godkjenne den.

Driftsrettighetene dere godkjenner omfatter heller ikke retten til å dele ut nye roller. Det eneste unntaket er stramt avgrenset: leveransepipelinen kan gi applikasjonens egne tekniske identiteter roller fra en fast liste som står ordrett i malen dere godkjente, slik at oppgraderinger kan skje automatisk. Ingen andre roller, ingen andre mottakere; forsøk utenfor listen avvises av Azure.

Applikasjonen behandler posten, og dere ser hva den gjør

Selve applikasjonen må selvsagt håndtere posten, det er jobben dens. Den kjører i deres miljø, henter posten fra Altinn og legger den i droppsonen deres. Det som sendes ut av miljøet deres til drift og rapportering, er avgrenset til teknisk driftsinformasjon uten innhold og uten filnavn, og avgrensningen er låst med automatiske tester. Driftsflaten vi feilsøker gjennom viser leveringsstatus, aldri innhold. Se Personvern og datahåndtering for hva som behandles hvor.

Alt vi gjør, logges hos dere

Hver driftshandling vi utfører skjer i deres abonnement og registreres automatisk i aktivitetsloggen der: hvilken person hos oss, hvilken handling, på hvilken ressurs, når. Loggen er en del av deres miljø, kan ikke endres eller slettes av oss, og kan arkiveres videre hos dere om revisjonen krever lengre historikk. Også et forsøk på å endre tilganger ville blitt logget der, i tillegg til å bli avvist.

Delegeringen selv er synlig i deres Azure-portal under Tjenesteleverandører så lenge den består: hvem hos oss som har tilgang, med hvilke roller. Der kan dere også fjerne den, når som helst og uten å involvere oss. Da mister vi all tilgang umiddelbart, mens applikasjonen og dataene deres blir stående urørt.

Revisjon og tilsyn

Fordi hele løsningen kjører i deres eget miljø, styrer dere selv hvem som får se den. Revisor eller en tilsynsmyndighet kan gis lesetilgang av dere direkte: til delegeringen, til aktivitetsloggen, til konfigurasjonen og til lagringen. Et slikt innsyn krever ingen medvirkning fra oss, og hver påstand på denne siden kan dermed etterprøves uavhengig av leverandøren.

Ansvarsdelingen er den vanlige etter personvernforordningen: dere er behandlingsansvarlig, vi er databehandler, og forholdet reguleres av en databehandleravtale. Se Vanlige spørsmål.

Les videre

• Azure Lighthouse: delegeringen i detalj, og hvorfor den er tryggere enn alternativene.
• Personvern og datahåndtering: hvilke opplysninger som behandles, hvor de finnes, og hva som aldri forlater miljøet deres.
• Leveransemodell: forutsetningene og ansvarsdelingen.