Veiledning for oppsett av systembrukere

Praktiske anbefalinger for oppsett av systembrukere, tilgangspakker og tilgangskontroll i ulike scenarioer

Denne siden gir konkrete anbefalinger for hvordan du setter opp systembrukere for ulike typer virksomheter. Veiledningen dekker hvor mange systembrukere du trenger, hvordan du fordeler tilgangspakker, og hvordan du håndterer tilgangskontroll.

Bruk tabellen under for å finne scenarioet som passer situasjonen din, og følg de detaljerte anbefalingene lenger ned.

Se også wizard som dekker noe av dette.

Hurtigoversikt

A. Virksomheten rapporterer egne data

Typisk eksempel: En bedrift bruker et sluttbrukersystem til å rapportere mva., aksjonærregister eller andre data på vegne av seg selv.

Anbefalt oppsett

• 1 systembruker knyttet til sluttbrukersystemet.
• Systembrukeren får alle tilgangspakkene virksomheten trenger for rapportering.
• Systemleverandøren sender en forespørsel om å opprette systembrukeren. Virksomheten godkjenner.

Slik fungerer det

Virksomheten
  └── Systembruker (standard)
        └── Tilgangspakker: f.eks. "urn:altinn:accesspackage:skatt-naering", "urn:altinn:accesspackage:merverdiavgift"

Viktig å huske

• Systemleverandøren har ansvar for å registrere de riktige tilgangspakkene i systemregisteret.
• Virksomheten trenger bare å godkjenne forespørselen — tilgangspakkene tildeles automatisk.
• Hvis virksomheten trenger flere tjenester senere, oppdaterer systemleverandøren systemregisteret og sender en ny forespørsel.

B. Tjenesteyter med én type klientforhold

Typisk eksempel: En registrert regnskapsfører rapporterer Skattekort til arbeidsgiver – innsending fra system (RF-1211). for flere klienter. Alle klientene har samme type relasjonsforhold (f.eks. registrert regnskapsfører i Enhetsregisteret).

Anbefalt oppsett

• 1 systembruker for klientforhold knyttet til sluttbrukersystemet.
• Systembrukeren får tilgangspakkene som passer klientforholdet (f.eks. regnskapsforer-med-signeringsrettighet).
• En klientadministrator hos tjenesteyteren knytter hver klient til systembrukeren.

Slik fungerer det

Tjenesteyter (f.eks. regnskapsbyrå)
  └── Systembruker for klientforhold
        ├── Tilgangspakke: regnskapsforer-med-signeringsrettighet
        ├── Klient A
        ├── Klient B
        └── Klient C

Viktig å huske

• Når en klient knyttes til systembrukeren, blir tilgangspakkene automatisk delegert til systembrukeren for den klienten.
• Nye klienter legges til av klientadministratoren — det trengs ingen nye systembrukere.
• Systemleverandøren må ha tilgangskontroll i sluttbrukersystemet slik at bare autoriserte ansatte kan handle på vegne av hver klient.

C. Tjenesteyter med flere typer klientforhold

Typisk eksempel: Et revisjons- og regnskapsbyrå (f.eks. «Rett Revisjon») som har noen klienter som registrert regnskapsfører, noen som revisor og noen med organisasjonsdelegerte tilgangspakker. De skal rapportere “Innrapportering A-melding” for alle sine kundetyper

Anbefalt oppsett

• 1 systembruker per type klientforhold, hver med tilgangspakkene som passer den relasjonstypen.
• Klientadministratoren fordeler klientene til riktig systembruker basert på relasjonstypen.

Slik fungerer det

Tjenesteyter (f.eks. Rett Revisjon)
  ├── Systembruker 1 (klientforhold)
  │     ├── Tilgangspakke: regnskapsforer-med-signeringsrettighet
  │     ├── Klient A (registrert regnskapsfører)
  │     └── Klient B (registrert regnskapsfører)
  │
  ├── Systembruker 2 (klientforhold)
  │     ├── Tilgangspakke: ansvarlig-revisor
  │     ├── Klient C (registrert revisor)
  │     └── Klient D (registrert revisor)
  │
  └── Systembruker 3 (klientforhold)
        ├── Tilgangspakke: a-ordning
        ├── Klient E (delegert i Altinn)
        └── Klient F (delegert i Altinn)

Hvorfor separate systembrukere?

Hver tilgangspakke representerer et ulikt rettslig grunnlag for å handle på vegne av klienten. En registrert regnskapsfører har andre rettigheter enn en revisor eller en virksomhet med delegert tilgang. Ved å skille dem sikrer du at:

• Hver systembruker bare har rettighetene som svarer til det faktiske forholdet.
• Sluttbrukersystemet kan velge riktig systembruker (og token) ved rapportering for en bestemt klient. Dette gjøres ved hjelp av external ref.
• Det finnes et tydelig revisjonsspor for hvilket grunnlag som ble brukt.

Viktig å huske

• Systemleverandøren må vite hvilken type relasjonsforhold tjenesteyteren har med hver klient. Denne informasjonen må deles av tjenesteyteren.
• Ved rapportering må sluttbrukersystemet velge riktig systembrukertoken basert på klientens relasjonstype.
• Nye klienter legges til den eksisterende systembrukeren som passer relasjonstypen — det trengs ingen nye systembrukere med mindre en ny relasjonstype kommer til.

D. Tjenesteyter med teambasert tilgang

Typisk eksempel: En forretningsfører eller et stort regnskapsbyrå som vil begrense tilgangen til bestemte team eller avdelinger.

Anbefalt oppsett

• 1 systembruker per team eller funksjon, hver med tilgangspakkene som er relevante for teamets ansvarsområde.
• Systemleverandøren har brukerstyring slik at bare ansatte i det aktuelle teamet kan bruke hver systembruker.

Slik fungerer det

Tjenesteyter
  ├── Systembruker 1 (klientforhold) — Forretningsførerteamet
  │     ├── Tilgangspakke: forretningsforer-eiendom
  │     ├── Borettslag A
  │     └── Borettslag B
  │
  └── Systembruker 2 (klientforhold) — Regnskapsteamet
        ├── Tilgangspakke: regnskapsforer-med-signeringsrettighet
        ├── Klient C
        └── Klient D

Viktig å huske

• Systemleverandøren må ha tilgangskontroll i sluttbrukersystemet. Altinn vet ikke hvem den enkelte brukeren bak systembrukeren er.
• Definer hvilke ansatte som tilhører hvert team, og hvilken systembruker de kan bruke.
• Dette oppsettet fungerer også i kombinasjon med scenario C (flere relasjonstyper) og teambasert tilgang.

E. Lokalt installert eller egenutviklet system

Typisk eksempel: En virksomhet har utviklet sitt eget rapporteringssystem, eller har kjøpt programvare (f.eks. SAP) som er installert på egne servere.

Anbefalt oppsett

• Virksomheten (kunden som har kjøpt SAP) registrerer seg som både systemleverandør og systemkunde i systemregisteret.
• 1 systembruker knyttet til det lokalt installerte systemet.
• Virksomheten oppretter sin egen Maskinporten-klient og installerer nøkkelen på serveren.

Slik fungerer det

Virksomheten (= systemleverandør + systemkunde)
  └── Systembruker (standard)
        └── Tilgangspakker: etter behov

Viktig å huske

• Det er kunden av programvaren (altså virksomheten som har kjøpt f.eks. SAP) som må få tilgang til Maskinporten — ikke programvareleverandøren.
• Virksomheten må ha en avtale med DigDir for tilgang til systemregisteret.
• Virksomheten må opprette sin egen Maskinporten-klient. Sertifikatet/nøkkelen må aldri deles med programvareleverandøren.
• Hvis programvareleverandøren deler nøkkelen sin med virksomheten, kan det føre til misbruk og tilgang til data på tvers av alle leverandørens kunder.

F. Regnskapskunder med ulike tjenestebehov

Typisk eksempel: Et regnskapsbyrå utfører regnskapstjenester for alle kundene sine, men noen kunder ønsker i tillegg at byrået håndterer sykmelding og andre NAV-relaterte oppgaver. Disse kundene har delegert ekstra tilgangspakker til regnskapsbyrået.

Utgangspunkt

• Alle kunder har regnskapsbyrået registrert som regnskapsfører i Enhetsregisteret.
• Noen kunder har i tillegg delegert tilgangspakken for sykmelding (f.eks. sykmelding) til regnskapsbyrået via Altinn.
• Regnskapsbyrået trenger å skille mellom kunder som bare har regnskapstjenester og kunder som også har sykmeldingstjenester.

Det finnes to måter å løse dette på. Velg den som passer best for virksomheten din.

Alternativ 1: Skille kunder etter tjenesteavtale

Her oppretter du separate systembrukere der hver systembruker har alle tilgangspakkene som trengs for den kundegruppen.

Oppsett:

• Systembruker 1 — for rene regnskapskunder. Denne har bare tilgangspakken regnskapsforer-med-signeringsrettighet.
• Systembruker 2 — for kunder som også ønsker sykmeldingstjenester. Denne har tilgangspakkene regnskapsforer-med-signeringsrettighet og sykmelding.
• Klientadministratoren fordeler kundene til riktig systembruker basert på tjenesteavtalen.

Regnskapsbyrå
  ├── Systembruker 1 (klientforhold) — Kun regnskap
  │     ├── Tilgangspakke: regnskapsforer-med-signeringsrettighet
  │     ├── Kunde A (kun regnskap)
  │     ├── Kunde B (kun regnskap)
  │     └── Kunde C (kun regnskap)
  │
  └── Systembruker 2 (klientforhold) — Regnskap + sykmelding
        ├── Tilgangspakke: regnskapsforer-med-signeringsrettighet
        ├── Tilgangspakke: sykmelding (delegert av kunden)
        ├── Kunde D (regnskap + sykmelding)
        └── Kunde E (regnskap + sykmelding)

Fordeler:

• Enklere å tilordne kunder til riktig systembruker — hver systembruker dekker én tydelig kundegruppe.
• Oversiktlig for klientadministratoren: kundene er sortert etter hva de har avtale om.

Ulemper:

• Når en kunde utvider tjenesteavtalen, må kunden flyttes fra én systembruker til en annen.
• Hvis det kommer en ny tilleggstjeneste som ikke passer inn i en eksisterende kombinasjon, må du opprette en ny systembruker med den nye kombinasjonen av tilgangspakker. Antall systembrukere vokser med antall kombinasjoner, ikke bare antall tjenestetyper.

Når en kunde utvider tjenesteavtalen:

1. Kunde B delegerer tilgangspakken sykmelding til regnskapsbyrået i Altinn.
2. Klientadministratoren fjerner Kunde B fra Systembruker 1 og legger kunden til Systembruker 2.
3. Sluttbrukersystemet oppdateres slik at Kunde B knyttes til riktig systembruker.

Alternativ 2: Én felles systembruker for regnskap + egne systembrukere per tilleggstjeneste

Her har alle kunder én felles systembruker for regnskapsarbeidet, mens tilleggstjenester håndteres av egne, spesialiserte systembrukere. Kunder som trenger tilleggstjenester knyttes til både den felles regnskapssystembrukeren og den aktuelle tilleggssystembrukeren.

Oppsett:

• Systembruker 1 — felles for alle regnskapskunder. Denne har tilgangspakken regnskapsforer-med-signeringsrettighet. Alle kunder knyttes hit.
• Systembruker 2 — kun for sykmelding. Denne har tilgangspakken sykmelding. Bare kunder som har delegert sykmeldingspakken knyttes hit.
• Hvis det kommer nye tilleggstjenester (f.eks. inntektsmelding), oppretter du en ny systembruker for den tjenesten uten å endre oppsettet for de andre.

Regnskapsbyrå
  ├── Systembruker 1 (klientforhold) — Regnskap (alle kunder)
  │     ├── Tilgangspakke: regnskapsforer-med-signeringsrettighet
  │     ├── Kunde A
  │     ├── Kunde B
  │     ├── Kunde C
  │     ├── Kunde D
  │     └── Kunde E
  │
  ├── Systembruker 2 (klientforhold) — Sykmelding
  │     ├── Tilgangspakke: sykmelding (delegert av kunden)
  │     ├── Kunde D
  │     └── Kunde E
  │
  └── Systembruker 3 (klientforhold) — Inntektsmelding (eksempel)
        ├── Tilgangspakke: inntektsmelding (delegert av kunden)
        └── Kunde E

Fordeler:

• Regnskapskunder trenger aldri flyttes — de ligger alltid på Systembruker 1.
• Når det kommer en ny tilleggstjeneste, oppretter du bare en ny systembruker for den tjenesten og knytter de aktuelle kundene til den. Du trenger ikke slette eller endre eksisterende systembrukere.
• Skalerer godt — antall systembrukere vokser med antall tjenestetyper, ikke med antall kombinasjoner av tjenester.
• Sluttbrukersystemet velger systembruker basert på hvilken tjeneste som utføres, ikke hvilken kundegruppe kunden tilhører.

Ulemper:

• Kunder med tilleggstjenester er knyttet til flere systembrukere. Sluttbrukersystemet må holde oversikt over hvilken systembruker som brukes for hvilken tjeneste.
• Klientadministratoren må vedlikeholde klientkoblinger på flere systembrukere.

Når en kunde utvider tjenesteavtalen:

1. Kunde B delegerer tilgangspakken sykmelding til regnskapsbyrået i Altinn.
2. Klientadministratoren legger Kunde B til Systembruker 2 (sykmelding). Kunde B forblir på Systembruker 1 (regnskap) som før.
3. Ingen endringer trengs for de andre kundene.

Hvilket alternativ bør du velge?

Viktig å huske (begge alternativer)

• De ekstra tilgangspakkene (f.eks. sykmelding) må delegeres av kunden selv — de følger ikke automatisk av regnskapsførerforholdet i Enhetsregisteret.
• Systemleverandøren må registrere systemet med alle relevante tilgangspakker i systemregisteret.
• Sluttbrukersystemet må holde oversikt over hvilken systembruker som brukes for hvilken kunde og tjeneste, slik at riktig token velges ved rapportering.

Hvor mange systembrukere trenger jeg?

Bruk dette beslutningstreet for å finne riktig antall:

1. Rapporterer virksomheten bare for seg selv? Ja → 1 systembruker (scenario A eller E).

2. Har tjenesteyteren bare én type klientforhold? Ja → 1 systembruker for klientforhold (scenario B).

3. Har tjenesteyteren flere typer klientforhold? Ja → 1 systembruker per relasjonstype (scenario C).

4. Har noen kunder delegert ekstra tilgangspakker utover det som følger av klientforholdet? Ja → 1 systembruker per kombinasjon av tilgangspakker (scenario F).

5. Trenger tjenesteyteren å begrense tilgangen etter team eller avdeling? Ja → Vurder 1 systembruker per team i tillegg til per relasjonstype (scenario D).

Når du IKKE bør opprette flere systembrukere

• Ikke opprett en egen systembruker per klient. Bruk klientkobling på én enkelt systembruker i stedet.
• Ikke opprett separate systembrukere for ulike tjenester hvis de deler samme tilgangspakke og relasjonstype. Én systembruker kan ha flere tilgangspakker.

Tilgangskontroll i sluttbrukersystemet

Når du bruker en systembruker, vet ikke den offentlige tjenesten hvem personen bak API-kallet er. Systemleverandøren har derfor ansvar for at bare autoriserte brukere får tilgang.

Minimumskrav

• Autentiser alle brukere som logger inn i sluttbrukersystemet.
• Autoriser brukere slik at de bare har tilgang til klienter og funksjoner som er relevante for rollen deres.
• Logg hvilken bruker som utførte hvilken handling, og for hvilken klient.

Anbefalt tilnærming for større virksomheter

• Definer roller eller team i sluttbrukersystemet (f.eks. «forretningsførsel», «regnskap», «revisjon»).
• Knytt hver rolle til én eller flere systembrukere.
• Sørg for at en ansatt med rollen «forretningsførsel» ikke kan bruke systembrukeren for «revisjon», selv om sluttbrukersystemet teknisk sett har tilgang til begge.

Sjekkliste før produksjon

• Systemleverandøren har registrert systemet med de riktige tilgangspakkene i systemregisteret.
• Systemleverandøren har sendt forespørsler for riktig antall systembrukere.
• Tjenesteyteren/virksomheten har godkjent alle forespørsler om systembrukere.
• Klientene er knyttet til de riktige systembrukerne (for scenarioer med klientforhold).
• Tilgangskontroll er på plass i sluttbrukersystemet (for scenarioer med flere ansatte eller team).
• Sluttbrukersystemet kan velge riktig systembrukertoken ved rapportering for ulike klienttyper.
• Oppsettet er testet med et representativt utvalg klienter før produksjon.