Sikkerhetsdokumentasjon

Dette dokumentet gir en omfattende oversikt over sikkerhetsrammeverket for Identums produkter og tjenester, inkludert eADM og eFEIDE. Vår sikkerhet er bygget på bransjens beste praksis, robuste driftsprosedyrer og en forpliktelse til å beskytte kundedata.

Utviklings- og designfilosofi

Vår utviklingsprosess er styrt av en «sikkerhet først»-tankegang, som innlemmer grunnleggende prinsipper for moderne cybersikkerhet.

"Personvern ved design"

Identum utvikler sine løsninger med Privacy by design som grunnleggende filosofi. De 7 prinsippene er:

Proaktiv, ikke reaktiv; forebyggende, ikke avhjelpende
Personvern som standardinnstilling
Personvern innebygd i designet
Full funksjonalitet – positiv sum, ikke nullsum
End-to-End-sikkerhet – fullstendig livssyklusbeskyttelse
Synlighet og åpenhet – hold det åpent
Respekt for brukernes personvern – Hold det brukerorientert

For sluttkunden betyr dette at løsningene våre er sikre som standard; personvern er innebygd i løsningen og trenger ikke å konfigureres.

Null tillit

Zero trust-prinsippet i sammenheng med identitets- og tilgangsstyring (IAM) er en sikkerhetsmodell og strategi som bygger på konseptet om at ingen brukere eller enheter, verken innenfor eller utenfor organisasjonens nettverk, noensinne skal gis de facto tillit. I stedet for å anta at alt bak brannmuren er trygt, krever zero trust at all tilgang kontinuerlig verifiseres og autoriseres.

Her er noen viktige aspekter ved nulltillitsprinsippet i forbindelse med eADM:

Identitetsverifisering: Enhver forespørsel om tilgang til systemet krever streng verifisering av brukerens eller enhetens identitet. Dette implementeres ofte ved hjelp av sterke autentiseringsmetoder, for eksempel multifaktorautentisering (MFA).
Minimering av tilgang: Brukere får kun tilgang til de ressursene de trenger for å utføre sine oppgaver (prinsippet om minst mulig privilegier). Tillatelser er ofte detaljerte og dynamiske, og justeres ut fra brukerens behov og atferd. Dette gjelder både brukernes tilgang til eADM og tillatelsene systemet er konfigurert til å gi andre brukere. Vanligvis vil behovsbasert tilgangsstyring (ABAC eller JIT) være bedre på sensitive systemer enn f.eks. rollebasert kontokontroll (RBAC).
Kontinuerlig overvåking: All aktivitet overvåkes og analyseres for å oppdage mistenkelig eller uvanlig atferd. Dette kan omfatte uvanlige tilgangsmønstre eller forsøk på å få tilgang til sensitive data.
Databeskyttelse: Selv om identitets- og tilgangsstyring er avgjørende, legger zero trust også stor vekt på å beskytte data. Dette inkluderer kryptering av data både under overføring og i hvile, samt sikring av datalagret tilgang basert på behov.

Implementeringen av nulltillit i eADM er sentralt for å beskytte organisasjoner mot sikkerhetstrusler ved å utfordre tradisjonelle sikkerhetsmodellers forutsetninger.

Dataminimering

Dataminimering handler om å redusere mengden personopplysninger og sensitive opplysninger som samles inn, behandles og lagres, til det som er strengt nødvendig for å utføre legitime funksjoner. Dette prinsippet er en sentral del av personvernforordningen (GDPR) og andre personvernlover, og det bidrar til å redusere risikoen for brudd på personvernet og sikkerheten.

Begrenset innsamling: Kun data som er nødvendige for spesifikke funksjoner eller tjenester bør samles inn. For eksempel importerer eADM ikke lønnsdata som standard, kun hvis det er nødvendig for den enkelte kunden.
Kortere oppbevaringsperioder: Data skal kun lagres så lenge det foreligger en operasjonell eller juridisk forpliktelse . eADM har retningslinjer for datalagring som automatisk sletter eller anonymiserer data etter behov. Som standard bruker eADM 365 dager for lagring av deaktiverte brukere, noe som kan justeres for den enkelte kunde.
Aggregerte data i stedet for individuelle data: Når det er mulig, bør data anonymiseres eller aggregeres slik at behandlingen ikke er basert på individuell identifisering.
Tilgangskontroll og minst mulig privilegier: Implementering av streng tilgangskontroll sikrer at kun autorisert personell har tilgang til personopplysninger, og at brukerne kun får de rettighetene de trenger.
Formål og åpenhet: Tydelige retningslinjer for hvorfor og hvordan data brukes, begrenset til de minst inngripende måtene å oppnå disse formålene på, bidrar til dataminimering.
Pseudonymisering: Hvis identifiserbare data må brukes, kan pseudonymisering (bruk av dataaliaser) bidra til å beskytte personers identitet og redusere virkningen av potensielle datalekkasjer.

Ved å anvende disse prinsippene kan en eADM støtte dataminimering i organisasjonen din, og dermed bedre beskytte personopplysninger samtidig som lovkrav oppfylles og brukernes personvern fremmes.

Drift og «Grunnleggende prinsipper for IKT-sikkerhet»

På den operative siden har vi basert vårt sikkerhetstankegang på Statens sikkerhetsetats grunnleggende prinsipper for IKT-sikkerhet.

Identifisere og kartlegge enheter, programvare, brukere og behov for tilgang

Oversikt og kontroll over hvor lenge vi oppbevarer brukerdata, og rutiner for sletting.
Tilgang må alltid tildeles på laveste nivå; ingen skal ha høyere tilgang enn det som er nødvendig for å utføre jobben.
Se avsnittene om tilgang for tilgangsnivåer for systembrukere i AD, G Suite og M365.

Beskytt og vedlikehold

Etablere en sikker IKT-arkitektur og beskytte bedriftens nettverk. Kontrollere dataflyten.
Ha kontroll over identiteter og tilgang.
Alle passord må lagres i et passordhvelv. Passord må ikke gjenbrukes. Alle passord og tilganger er personlige.
Hvis du får tilgang til et kundesystem, må passordet og brukernavnet slettes når jobben er utført.
Beskytt data i hvile og under overføring.
Oppbevar viktig informasjon om deaktiverte brukere i eFeide og eADM for å sikre at brukernavn og andre unike identifikatorer ikke kan brukes på nytt.
Etter en bestemt periode blir logger, personlig informasjon og tilgangs-/rettighetshistorikk for en bruker automatisk slettet.

Oppdag og fjern kjente sårbarheter og trusler

I tråd med det første av grunnprinsippene om «privacy by design» arbeider vi aktivt for å finne sårbarheter i systemet vårt. Vi gjennomfører derfor årlige penetrasjonstester av løsningene våre. Disse utføres av Visma sine sikkerhetseksperter. Se mer informasjon under «Penetrasjonstesting».
Trusselvurdering gjøres i samarbeid med Nasjonalt cybersikkerhetssenter (NCSC). Identum er definert som kritisk infrastruktur og mottar varsler fra NCSC når sikkerhetshull og utnyttelser oppdages i serversystemer, programvare og andre IT-systemer. Trusselvurderinger utføres kontinuerlig av Identum basert på informasjon fra NCSC. Relevante sikkerhetshull blir kontinuerlig lappet etter hvert som vi blir kjent med dem.
Alle Identums servere, både i produksjons- og testmiljøer, oppdateres ukentlig. Dette gjelder operativsystemet, installerte apper og annen programvare. I tillegg oppdateres også eFeide og eADM på søndager, i henhold til 14-dagers utviklingssprint. Identum har en dedikert ressurs som er ansvarlig for å sikre dette. Etter oppdatering/patching testes alle systemer for å sikre full funksjonalitet. Søndag er valgt på grunn av lav belastning og bruk på søndager. eFeide oppdateres ikke i forbindelse med skolestart og eksamener, med unntak av operasjonelt kritiske oppdateringer.

Håndtere og gjenopprette

Alle uønskede hendelser knyttet til sikkerhet eller personvern registreres i et eget register, inkludert tid, sted, hvem, tiltak og oppfølging etterpå. Prosedyrene er dokumentert i Identums interne beredskapsplan. Kunder blir varslet om både interne og eksterne uønskede hendelser i henhold til Service Level Agreement (SLA). Prosedyrene er dokumentert i Identums interne beredskapsplan. Der det er relevant, deles trusselvurderinger fra NCSC med kundene.

Identum har en avtale om assistanse fra Vismas egen cybersikkerhetsgruppe dersom selskapet blir utsatt for angrep, hacking eller andre trusler mot datasikkerheten. Visma vil da opprette et beredskapsteam som vil ha ansvaret for å håndtere situasjonen, få den under kontroll og gjenopprette berørte systemer.

Systemovervåking og trusselhåndtering

Fra og med 01.02.2023 er Identum AS et heleid datterselskap av Visma AS og underlagt Vismas rutiner for cybersikkerhet, overvåking og trusselhåndtering. Visma bruker Sentinel One (SentinelOne | AI-drevet cybersikkerhetsplattform for bedrifter) for Managed Detection and Response (MDR). Sentinel One overvåker kontinuerlig Identums servere, klienter, endepunkter og ansattes datamaskiner. Alle hendelser loggføres, evalueres og trusler følges automatisk opp av Vismas Security Operations Centre (SOC)-team.

Ved en tilstrekkelig alvorlig sikkerhetshendelse eller angrep blir Identum varslet av Visma, som har beredskap 24/7/365 og vil iverksette tiltak allerede før Identum blir varslet. Hvis hendelsen/angrepet vurderes som kritisk eller rettet mot en bestemt kunde, blir kunden umiddelbart varslet og inkludert i teamet som håndterer hendelsen. Den normale varslingstjenesten for våre kunder er via e-post, men i slike tilfeller vil du også motta en telefon.

Bakdør og tilgang hvis vanlig pålogging ikke fungerer

Identum har egne «break glass»-kontoer i vårt driftsmiljø. Hvis vanlig pålogging for våre ansatte av en eller annen grunn ikke fungerer, kan slike kontoer brukes til å gi eller gjenopprette tilgang til systemet. Denne bakdøren brukes ikke i normal drift, og alle pålogginger overvåkes med umiddelbar varsling. I tilfeller hvor kundens pålogging til eADM ikke fungerer (f.eks. hvis kundens AAD er nede og SSO derfor er ute av drift), kan Identum bytte til en annen pålogging i den perioden kunden opplever nedetid, f.eks. fra Entra ID SSO til pålogging med ID-porten.

Penetrasjonstesting

Identum er en del av Vismas PENTEST 2.0-program. Kontinuerlig testing utløses basert på faktiske risikosignaler, snarere enn forløpt tid. Testingen drives nå av data fra andre tjenester i Vismas applikasjonssikkerhetsprogram (Software Composition Analysis, Static Application Security Testing, Dynamic Application Security Testing, External Attack Surface Mapping) samt ekspertvurderinger fra Vismas eget penetrasjonstestingsteam. Våre kunder står selvfølgelig fritt til å gjennomføre sine egne penetrasjonstester, med eller uten hjelp fra tredjeparter valgt av kunden.

Drift og hosting

Identums løsninger er skybaserte og drives og vedlikeholdes i Entra ID via vår driftspartner Microsoft, med redundans, ekstern sikkerhetskopiering og lastbalansering. Vi har to Entra ID-miljøer: i Østfold for norske kunder og i Gävle i Sverige for EU-kunder. Oppetidsgarantien er 99,9 % (se vår SLA). Identum er ansvarlig for operativsystemet og programvaren, mens Microsoft håndterer drift av maskinvare, kommunikasjon, ekstern sikkerhetskopiering, redundans og brannmur. Kun ansatte med teknisk ansvar i Identum eller nødvendig driftspersonell hos Microsoft har tilgang til servermiljøet. Dette skjer via Teamviewer-klienter med MFA. Identum har en utvidet SLA-avtale med Microsoft med responstid innen 10 minutter i kontortiden og 1 time utenfor kontortiden.

De eneste brannmurportene som generelt er åpne for innkommende trafikk, er portene 80/443 for bruk av Teamviewer, webklienter og API-klienter. All trafikk til port 80 blir automatisk rutet til 443, slik at kommunikasjonen foregår på en kryptert linje via TLS. Alle webtjenester/sider, interne og eksterne, er sikret med SSL-sertifikater fra Digicert.

Oppdatering og oppgradering

Oppdatering av systemer, komponenter, servere, databaser osv. utføres hver søndag. Identum har en dedikert ressurs for dette. Identum er definert som kritisk infrastruktur og mottar varsler fra Nasjonalt cybersikkerhetssenter (NCSC) når sikkerhetshull og utnyttelser oppdages i serversystemer, programvare og andre IT-systemer. Trusselvurderinger utføres kontinuerlig av Identum basert på informasjon fra NCSC. Relevante sikkerhetshull blir kontinuerlig oppdatert etter hvert som vi blir kjent med dem. Oppdatering av systemer, komponenter, servere, databaser osv. utføres også hver søndag. Identum bruker ikke beta-funksjonalitet eller beta-versjoner som standard.

Kryptering

Identums servere er hostet i Entra ID-skyen og bruker derfor standard serverside-kryptering av alle data under lagring. Krypteringsnøklene håndteres automatisk av Entra ID-plattformen (Serverside-kryptering av Entra ID-administrerte disker – Entra ID Virtual Machines). Kommunikasjonen mellom Identums servere, klienter, nettlesere og tredjepartssystemer er ende-til-ende-kryptert via TLS 1.2 med 2048-biters kryptering, og sertifikatene er utstedt av Digicert. Disse installeres og vedlikeholdes av medlemmene av vårt driftsteam som har nødvendig tilgang til servere og Digicert-tjenesten. De erstattes/har en gyldighet i henhold til bransjestandarder (12 måneder). Database, sikkerhetskopi og operativsystemer er også kryptert. Videre er alle brukerdata kryptert. I eADM og eFeide er alle systempassord (hemmeligheter) sikret med Rijndael AES 256-biters kryptering. Passord for brukere lagres i vår LDAP-database, som bruker standard Active Directory-teknologi og derfor lagrer dem hashet og kryptert. Ved overføring av passord (hemmeligheter) brukes alltid ende-til-ende-kryptering via TLS.

Datadeling og separasjon

Kundedata skilles logisk ved hjelp av en unik kunde-ID, slik at hver kunde behandles som et eget område. Denne arkitekturen speiler multitenant-modellen som finnes i Microsoft Entra,
, hvor logiske grenser sikrer at hver klient eksisterer i et selvstendig miljø.
Alle datatabeller er knyttet til denne unike ID-en, og hver API-forespørsel må inneholde denne nøkkelen som en obligatorisk parameter. Ved å håndheve disse domenebaserte grensene sikrer systemet at
autentisering, autorisasjon og datalagring er strengt begrenset til den spesifikke kunden. Dette garanterer at data forblir isolert og sikre, og forhindrer eksponering på tvers av kunder.

Administratorer kan kun få tilgang til mer enn én instans av eADM av Identum, og administratoren kan ikke tildele andre samme tilgang. Det anbefales at slik tilgang alltid gis med en utløpsdato.

Sikkerhetskopiering og gjenoppretting

Databaser sikkerhetskopieres hvert 10. minutt, og produksjonsmiljøet som helhet sikkerhetskopieres daglig. Sikkerhetskopiene lagres ikke i produksjonsmiljøet, men i et fysisk separat miljø. For å verifisere både kvaliteten og innholdet i sikkerhetskopiene og teste datagjenoppretting, opprettes Identums testmiljø alltid fra sikkerhetskopier. Testmiljøet er en komplett kopi av produksjonsmiljøet. Dette gjøres minst hver 14. dag.

Kontinuitetsplan

Om nødvendig kan hele drifts-/servermiljøet gjenopprettes fra bunnen av på under seks timer, enten i samme miljø eller i et sekundært miljø (f.eks. hvis det primære miljøet utsettes for et DDOS-angrep). Det er også mulig å gjenopprette individuelle kunder fra en sikkerhetskopi. Dette kan gjøres både hvis det oppstår feil i forbindelse med oppgradering eller tekniske endringer i løsningen, eller hvis kunden trenger å gjenopprette, for eksempel etter en import av korrupte data fra kildesystemet. Dette kan bestilles via Identums kundesupport, og slike forespørsler vil bli behandlet som en nivå A-feil i henhold til kundens gjeldende servicenivåavtale til enhver tid. Hvis Identum uavhengig avgjør at enten hele servermiljøet eller en bestemt kunde må gjenopprettes, blir kunden varslet, enten via varslingstjenesten i eADM eller per telefon.

Forebyggende tiltak

Identum har, i likhet med andre Visma-selskaper, egne prosedyrer for risikovurdering, risikoreduksjon og risikostyring. Risikoer identifiseres og vurderes etter alvorlighetsgrad og sannsynlighet (risikovurdering). For hver risiko må det foreligge en forebyggende plan (risikoreduksjon) og en håndteringsplan (risikostyring) dersom risikoen faktisk inntreffer. Dette materialet er en del av Identums interne sikkerhetsdokumentasjon. Dette er naturligvis ikke offentlig informasjon. Se også avsnitt 3 «Systemovervåking og trusselhåndtering» og avsnitt 5 «ISO27001 og Visma Cloud Delivery Model».

Konsekvenser av nedetid på eADM

Hvis eADM opplever nedetid, vil alle kontoer i organisasjonen fungere som før, med alle rettigheter og tilganger. Så lenge eADM er nede, vil ikke kontoer bli opprettet/oppdatert/deaktivert/slettet, og ingen tilganger/lisenser vil bli gitt/endret/fjernet av eADM. Det vil fortsatt være mulig å gjøre dette manuelt i det enkelte målsystemet.

Konsekvenser av nedetid på eFeide

Hvis eFeide, som brukeradministrasjonssystem (BAS) for FEIDE-katalogen, opplever nedetid, vil FEIDE-pålogging fortsatt fungere som før. Det er kun hvis SIKT (Statens informasjonsteknologiske tjeneste, https://sikt.no/ ) opplever nedetid at FEIDE-pålogging blir utilgjengelig. Hvis eFeide har nedetid, vil funksjonaliteten for passordhåndtering, internettilgangsadministrasjon og MFA-administrasjon av FEIDE-kontoer være utilgjengelig.

Konsekvenser av nedetid på kildesystemer

Hvis et kildesystem er nede, vil eADM og eFeide naturligvis ikke bli oppdatert med nye kildedata. Dataflyten fra eADM og eFeide til målsystemene vil fortsette som før. Eksempler på dette er passordendringer, endringer i gruppe-/teammedlemskap, roller og rettigheter. Når kildesystemet er tilgjengelig igjen, vil eADM og eFeide behandle alle kildedataene på nytt, slik at alle ventende brukere osv. får de nødvendige kontoene og tilgangene.

Konsekvenser av nedetid på målsystemer

Hvis et målsystem er nede i en kortere eller lengre periode, plasseres endringene i en eksportkø. Når målsystemet er tilgjengelig igjen, behandles køen. Eksempler på endringer som plasseres i eksportkøen er attributtendringer (f.eks. navn på en bruker), passord, gruppe-/teammedlemskap, roller og tilganger. Det loggføres i eADM når endringer ble plassert i eksportkøen og sendt til de ulike målsystemene.

Melding

Identum har flere typer varsler om feil, nedetid eller andre hendelser som har en negativ innvirkning på tjenesten:

Automatisk systembasert varsling → Systemet sender ut en statusrapport etter hver fullført synkronisering med generell informasjon. I tillegg vil systemet varsle hvis synkroniseringen stopper, f.eks. som følge av korrupte data eller hvis et målsystem ikke svarer. Det er også mulig å sette opp egne varslingskriterier, enten via e-post eller SMS, f.eks. hvis en bruker får administratorrettigheter. eADM kan settes opp til å varsle automatisk i tilfelle feilmeldinger for individuelle brukere, f.eks. hvis en oppdatering mislykkes i et målsystem (forutsatt at målsystemet støtter dette!).
Manuell varsling → Identum har sin egen varslingsliste med e-post og SMS for alle administratorer i eADM og/eller eFeide. Denne listen brukes til å varsle om hendelser som påvirker en eller flere kunder negativt. Både generelle og spesifikke problemer vil bli varslet, i samsvar med SLA.
Vær oppmerksom på at kunder som har egne overvåkingssystemer, kan koble seg til loggene i eADM via API og automatisk hente ut kontinuerlige logger med varsler, oppdateringer og feilmeldinger.

Feilmelding

Alle feil som oppdages av kunden kan rapporteres direkte til Identum via et skjema som er tilgjengelig for administratorer i eFeide og eADM. Dette gjelder alle typer feil, både feil i systemet og meldinger om personvernrelaterte hendelser og tiltak. Alle personvernrelaterte hendelser behandles som en feil på nivå A i henhold til den avtalte servicenivåavtalen (SLA). Alle hendelser håndteres i henhold til grunnleggende prinsipper for IKT-sikkerhet, punkt 4.-4.4. eADM og eFeide har også innebygd funksjonalitet for å sende inn forslag til forbedringer. Alle forslag vurderes fortløpende.

Informasjonssikkerhet

GDPR og personvern

Som et grunnleggende prinsipp for import av kildedata til våre systemer, importerer vi kun brukere og brukerdata som skal behandles videre. Hvis en ansatt ikke skal ha en konto i AD, filtrerer vi dette bort fra importen til våre systemer. Foreldredata brukes ikke ved import til Feide-kataloger. Bare relevante brukerdata importeres; for eksempel importerer vi ansettelsesprosent (som kan være relevant i forbindelse med tildeling av lisenser), mens vi ikke importerer lønnsdata. Det er viktig å understreke at det er kildedatasystemene (HRM og SAS) som har forrang. Når en bruker opprettes i HRM, opprettes brukeren i eADM. Når en bruker deaktiveres eller slettes fra systemet, vil også tilknyttede data slettes, i henhold til regler fastsatt i eADM. For eksempel kan det automatiseres at brukere først deaktiveres og deretter slettes fra systemet etter en gitt periode.

Sikkerheten og personvernet i eADM er helt avhengig av at kunden har gode rutiner for registrering og avregistrering av brukere fra kildesystemene sine. Et vanlig klagemål fra administratorer når det gjelder livssyklusen til brukerkontoer, er at «alle legger merke til når noen begynner, men ingen legger merke til når noen slutter». Dermed risikerer du at gamle brukerkontoer og personopplysninger ligger igjen i lang tid. Løsningen på dette er gode regelsett i eADM som sikrer at data som ikke skal lagres, slettes, f.eks. når brukeren deaktiveres, går på permisjon, dør eller slutter. eADM automatiserer dette og sørger for at alle brukerkontoer enten fjernes automatisk eller at nødvendige mottakere blir varslet når noe må gjøres manuelt. Via meldingsmaler kan IT, drift og administrasjon varsles når utstyr skal leveres inn, eller tilgang skal endres eller fjernes. Alle brukere har pålogging til brukergrensesnittet, og alle kan når som helst se alle data som er registrert for sin egen bruker.

I forbindelse med GDPR og personvern kan sluttbrukere se sine data i en personvernseksjon hvor vi også oppgir hvor dataene kommer fra, hvem de skal kontakte hvis noe er feil, eller hvis de ønsker at dataene skal slettes. Identums løsninger oppfyller alle krav til Normen for informasjonssikkerhet. Se vedlegg 9 i kontrakten for Identum ASs databehandlingsavtale. Vi har et prinsipp om at vi tilpasser oss kundene våre, i stedet for at de må tilpasse seg oss. Hvis vår standard databehandlingsavtale ikke dekker kundens behov, tilpasser vi oss og bruker den avtalen kunden ønsker.

Underleverandører

Se Visma Trust Centre for informasjon om våre hostingleverandører og databehandlere:

https://www.visma.com/trust-centre-products/identum

ISO27001 og Visma Cloud Delivery Model

Fra og med 01.02.2023 er Identum AS et heleid datterselskap av Visma AS og dermed underlagt deres kvalitetssystem og leveringsmodell som beskrevet her: Visma Cloud Delivery Model (VCDM) beskriver vår tilnærming til utvikling, levering og drift av skytjenester. Den beskriver aspekter ved hvordan vi bør være organisert, hvordan vi bør arbeide (prosesser), samt tekniske krav og beste praksis som er nødvendig for vellykket levering av skytjenester. Mer informasjon om VCDM finner du på: Visma Cloud Delivery Model (VCDM). Modellen er basert på en rekke kjerneprinsipper og fokuserer på DevOps og kontinuerlig levering. VCDM har følgende revisjonserklæring og sertifiseringer:

ISAE 3402 SOC 1 Type II
ISO 27001

Visma Security Programme og Visma Architecture and Technology Programme er integrert i Visma Cloud Delivery Model. Vårt informasjonssikkerhetsstyringssystem (ISMS) er sertifisert i henhold til ISO 27001 og revideres årlig av en uavhengig IT-revisor. I tillegg blir Vismas evne til å overholde ISMS og kvalitetsstyringssystemet i VCDM revidert av et uavhengig revisjonsfirma i henhold til ISAE 3402. Denne omfattende kontrollen utføres også årlig og oppsummeres i en ISAE 3402 Type II-rapport. Vår tilnærming til implementering av endringer er kontinuerlig integrering og kontinuerlig distribusjon (CI/CD). Metodikken er i stadig utvikling når det gjelder teknologi, kompetanse og prosedyrer. Akkurat nå betyr dette at endringer kontinuerlig verifiseres og implementeres i vårt staging-miljø. Der utføres manuelle tester både internt i utviklingsavdelingen og av fageksperter. For mer omfattende endringer bruker vi også pilotkunder som tester endringene i normal drift i en periode før de slippes til alle kunder.Https://www.visma.com/trust-centre Visma Cloud Delivery Model.

Endringer og oppdateringer

Endringer og oppdateringer medfører vanligvis ikke nedetid. Hvis dette skjer, vil det bli utført i forhåndsdefinerte servicevinduer og varslet i samsvar med SLA. Vi har en felles, automatisk oppgraderingsprosess for alle miljøer. Hyppige og små oppdateringer gir lav risiko for feil ved hver endring. Vi bruker i økende grad implementering av oppgraderinger direkte i produksjonsmiljøet, men skjult bak funksjonsbrytere, slik at funksjonaliteten bare aktiveres når den er klar for kunden. I kombinasjon med automatiserte tester gir dette høy stabilitet, færre feil og rask utrulling av nye funksjoner. Oppdateringer vil bli kommunisert forskjellig avhengig av endringens størrelse og omfang:

Mindre endringer, som feilrettinger som ikke påvirker kunden eller brukeren, vil bli varslet gjennom en oppdatering av versjonsnotater.
Mellomstore endringer, som endringer eller tillegg til arbeidsprosesser eller skjermbilder, vil bli kunngjort i versjonsnotater, varsler på startsiden, oppdatert brukerdokumentasjon og på Visma Community.
Store endringer, som ny nøkkelfunksjonalitet eller en større endring i en arbeidsprosess, kan i tillegg omfatte webinarer og/eller oppdatert e-læring.

For større endringer som krever opplæring og/eller konfigurering av systemet, vil vi involvere kunden før vi implementerer endringen. Omfanget av dette vil variere avhengig av hva slags endring det dreier seg om. Vår strategi for håndtering av eventuelle feil som kan oppstå under oppdateringer, er å «rulle fremover». Dette betyr at vi ønsker å rette feilen og oppdatere med en ny versjon, i stedet for å rulle tilbake. Kun i unntakstilfeller og ved alvorlige feil vil det være relevant å rulle tilbake.

Sikkerhet og tilgangsstyring

Identum driver sin programvare hovedsakelig via nettapplikasjoner: https://mega.efeide.no, https://mega.eadm.no og https://mega.eADM.se. All tilgang til nettapplikasjonene er beskyttet av en captcha, brukernavn og passord, samt 2FA-autentisering. Kunden kan selv bruke disse portalene til administrasjon og selvbetjening, men da med andre tilganger og rettigheter (se avsnittet om tilgangsadministrasjon). Vi anbefaler alle våre kunder å bruke autentisering med MFA aktivert, og vi krever at all tilgang til alle våre systemer på administratornivå må være med MFA. Vi tilbyr pålogging via brukernavn/passord med MFA, ID-porten eller SSO med Entra ID. Hvis SSO brukes, krever vi at tilgangen er beskyttet på rettighetsnivået avdelingsleder og oppover. Det er et viktig prinsipp å ikke gi høyere tilgang enn det som er nødvendig.

Vi anbefaler derfor at du er restriktiv med å gi tilgang på administratornivå. For de aller fleste daglige operasjoner er tilgang som servicedesken bruker tilstrekkelig. For brukere som bare trenger å løse en spesifikk oppgave, for eksempel å administrere passord for en avdeling, er superbruker-tilgang tilstrekkelig. Kun absolutt nødvendig personell bør ha administratoradgang til systemet, og dette bør være tidsbegrenset. Dette prinsippet begrenser tilgangen til personopplysninger og mulighetene for å tildele tilgang eller rettigheter. Alle endringer som utføres via webgrensesnittet loggføres automatisk. Kunden blir rutinemessig varslet i tilfelle uønskede hendelser, i tillegg til den daglige statusrapporten fra våre systemer.

Vi understreker at vi anbefaler at tilgang til eFeide og eADM beskyttes med tofaktorautentisering for alle brukere med administratorrettigheter. Denne funksjonaliteten er en del av løsningene. Vår policy for tilgangsstyring er at brukere ikke skal gis høyere tilgangsnivå enn det de trenger i det daglige. Høyere tilgang vurderes ut fra behov. Administratoradgang bør kun tildeles noen få utvalgte brukere som har gjennomført opplæring i bruk av systemet. Et eksempel kan være at førstelinjesupport hos kunden har tilgang til servicedesk, mens kun tredjelinje har tilgang til systemet på administratornivå. Identum anbefaler alle våre kunder å følge denne policyen når de setter opp regler for automatisk eller manuell tilgangsstyring til forretningssystemer, tredjeparter osv. via eADM.

Internt personell

Dette gjelder også Identums egne ansatte. Ansatte får kun nødvendig tilgang i henhold til stilling og funksjon. Når ansatte slutter, fjernes all tilgang umiddelbart. Identum bruker ikke hjelp fra eksterne tredjeparter og har en policy om at kun ansatte som aktivt arbeider med drift og brukerstøtte av løsningen har tilgang til kundenes data. De ulike tilgangsnivåene og rollene i Identum er klart definert, og blir revidert og behovstestet med jevne mellomrom i henhold til ISO27001. Alle endringer som gjøres i systemet loggføres på samme måte som kundens egne brukere. Så hvis en ansatt i Identum gir tilgang til et forretningssystem hos en kunde, loggføres dette i historikken til brukeren som fikk tilgangen. Det er ikke mulig å kopiere brukerdata mellom de ulike instansene i brukergrensesnittet, kun maler og regelsett.

Adgangskontroll

Både eFeide og eADM støtter ulike metoder for brukerinnlogging, inkludert tofaktorautentisering. Vi tilbyr (selvsagt) FEIDE-innlogging, ID-porten, ADFS/LDAP, SSO med Entra ID/EntraID, SSO med Google Workspace og andre SAML2.0-autorisasjonsløsninger. Vi forventer at kundene beskytter SSO-pålogging med MFA. Det anbefales ikke å gi tilgang til eADM og eFeide uten tofaktorbeskytelse, selv ikke på ansatt-/avdelingsledernivå. På servicedesk- og administratornivå krever vi at kundene våre beskytter SSO med MFA, eller alternativt bruker ID-porten. Systemtilgang kan gis automatisk basert på regelsett eller manuelt for den enkelte brukeren. Vi anbefaler at administratortilgang kun gis manuelt og basert på behov. Tilgang kan gis med eller uten utløpsdato, og systemet har en løsning for både aktiv og passiv tilgangsrevisjon med gitte tidsintervaller. De ulike tilgangsnivåene kan administreres på gruppe-, rolle- og personlig nivå. For eksempel kan påloggingen til brukergrensesnittet for eFeide reguleres slik at alle som har tilgang til å se personopplysninger om andre brukere, må logge på med tofaktorautentisering, mens studenter (som kun kan se sine egne opplysninger) kan logge på uten å bruke tofaktorautentisering.

Ansatte

Systemet tar også hensyn til at én og samme bruker kan ha forskjellige roller i forskjellige avdelinger, med varierende behov og tilgang. En ansatt kan se all tilgjengelig informasjon om seg selv og endre passordet sitt. En avdelingsleder ser bare sine egne ansatte. Hvis en bruker er avdelingsleder og samtidig er ansatt på et annet nivå i organisasjonen, vil denne brukeren bare ha administratorrettigheter til avdelingen der han/hun er avdelingsleder. I den andre avdelingen vil han/hun bare ha vanlige ansattrettigheter. De seks rollene gir tilgang til funksjonsområder, underliggende informasjon og funksjonalitet.

Historikk, logger og tilgangsgranskning i eADM

eADM har full loggføring av alle endringer som gjøres på objektnivå, dvs. for brukere, grupper og avdelinger. Loggene er tilgjengelige for alle med administratoradgang i løsningen. Både endringer som kommer inn fra kildesystemer og endringer som gjøres i eADM blir loggført. Systemet loggfører også alle data som sendes til de ulike kildesystemene, slik at du har full oversikt over hvilke data som er eksportert hvor. Alle oppføringer logges med objekt-ID, dato/klokkeslett, årsaken til endringen, hvem som utførte endringen hvis det er en manuell endring, den forrige verdien og den nye verdien. Alle endringer i selve systemoppsettet logges også. Dette betyr alle endringer i regelsett, synkroniseringsmaler, meldingsflyt, tilgangskontroller og arbeidsflyt. Alle logger lagres, krypteres og beskyttes digitalt og fysisk i henhold til de samme standardene som Identums andre data. Loggene kan ikke endres av noen type bruker, inkludert Identums egen «superduper»-administratorrolle. Loggene kan eksporteres for behandling i tredjepartssystemer. Alle hendelser, logger osv. kan konfigureres til å utløse en varsling via e-post eller SMS når de oppstår. Systemet kan for eksempel varsle om spesifikke feilmeldinger i forbindelse med eksport til sensitive systemer eller når en bruker logger seg på med en IP-adresse utenfor et gitt geografisk område.

Loggføring av endringer i brukerdata, rettigheter og tilgang

I brukergrensesnittet til eADM kan man også se alle tilganger og lisenser som er tildelt en bruker, både i eADM og i tilknyttede målsystemer. Historikken viser når en tilgang eller lisens ble tildelt, enten den ble gitt automatisk basert på et regelsett eller manuelt av en bruker. Man vil kunne se hva en bruker har tilgang til i et saks-/arkivsystem, og hvilken type tilgang det dreier seg om. eFeide loggfører alle rettighetsendringer i tillegg til endringer i brukerdata og passord. Hvis en tilgang er gitt av et regelsett, kan man videre spore hvem som har gjort endringen i regelsettet som utløste tilgangen.

Sikkerhets- og passordlogger

Sikkerhetsloggføring i eADM loggfører alle påloggingsforsøk, både autoriserte og uautoriserte, med hvem, tidspunkt, sted (IP), type autentisering og status. I tillegg loggføres alle feilmeldinger, med metode (f.eks. type API-kall), tidspunkt, bruker og IP. Alle passordendringer logges, med tids- og datostempel, hvordan passordendringen ble gjort, hvem som initierte passordendringen, om passordet ble eksportert videre til andre målsystemer, og med eventuelle feilmeldinger.

Tredjeparts tilgang

Kunden kontrollerer selv hvem som har tilgang til kundedata i eADM via brukergrensesnittet. Dataflyt til målsystemer kontrolleres via synkroniseringsmaler, hvor kunden selv bestemmer hvilke data som skal eksponeres for/overføres til hver enkelt tredjepart. eADM tillater ikke tredjeparter å hente data fra systemet etter eget forgodtbefinnende, med mindre kunden spesifikt gir denne tilgangen via API. Se også punktet om «Penetrasjonstesting».

Passordhåndtering

I eADM og eFeide er alle systempassord (hemmeligheter) sikret med Rijndael AES 256-biters kryptering. Passord for brukere lagres i vår LDAP-database, som bruker standard Active Directory-teknologi og derfor lagrer dem hashet og kryptert. Ved overføring av passord (hemmeligheter) brukes alltid ende-til-ende-kryptering via TLS. Dette gjelder all overføring av data til og fra løsningen. Passordene er ikke tilgjengelige for noen brukere i eADM eller eFeide, verken for de ansatte selv, avdelingsledere eller administratorer. Det eneste unntaket er startpassord, da disse naturligvis må være lesbare, utskrivbare og sendes til den ansatte. Etter første pålogging vil dette passordet bli endret og lagret kryptert. Fra da av vil ingen kunne se det; det kan bare endres. Startpassord for brukere opprettes i eADM/eFeide når en brukerkonto opprettes. Passordet genereres i henhold til regelsett som er satt opp i henhold til krav fra kunden, f.eks. 16 tegn, stor bokstav, minst 1 spesialtegn.

Når en brukerkonto opprettes i målsystemer som AD, Entra ID eller forretningssystemer, kan brukerne opprettes med samme startpassord. Dette overføres kryptert. Passord kan endres i våre løsninger og overføres i sanntid til målsystemene. Det kan stilles krav om at brukerne må endre startpassordet sitt i forbindelse med pålogging til Entra ID, AD og Google før de får lov til å logge inn. Identum har en løsning for å tilbakestille passord via SMS eller via autentisering gjennom ID-porten, og vi anbefaler ID-porten på det sterkeste. Alle passordendringer loggføres, med tids- og datostempel, hvordan passordendringen ble gjort, hvem som initierte passordendringen, om passordet ble eksportert videre til andre målsystemer, og med eventuelle feilmeldinger. I eADM kan avdelingsledere endre passord for sine ansatte, enten ved å tildele et nytt passord eller sende et generert passord til den ansatte via SMS hvis et mobilnummer er registrert på brukeren.

Vi anbefaler imidlertid at prosedyren bør være at ansatte gjør dette selv via portalen for glemt passord. Servicedeskbrukere og administratorer i eADM kan endre passord for alle brukere, enten ved å tildele et nytt passord eller sende et generert passord til den ansatte via SMS hvis et mobilnummer er registrert på brukeren. Vi anbefaler imidlertid at prosedyren bør være at ansatte gjør dette selv via portalen for glemt passord. I eFeide kan lærere endre passord for elever, skoleadministratorer kan endre passord for elever og lærere på sin skole, og kommunale administratorer kan endre passord for alle brukere. Feide støtter ikke tvungen passordendring.

Sikkerhet og Feide-tjenester

I eFeide kan administratorer administrere pålogging med MFA for gitte Feide-tjenester for ansatte. Krav til MFA for Feide-tjenester kan settes både individuelt og for hele skoler. En tofaktormetode er det en bruker bruker for å bevise sin identitet når en Feide-tjeneste krever tofaktorautentisering. Feide har fire forskjellige tofaktormetoder tilgjengelig: pålogging via ID-porten, kode via SMS, kodeark og autentiseringsklient (MS Authenticator eller Google Authenticator). Hvilke Feide-tjenester som skal beskyttes med MFA, er opp til den enkelte kunde. Vår tommelfingerregel er at alle Feide-tjenester der det lagres personopplysninger om elever og/eller ansatte, bør beskyttes med MFA. Et skybasert skoleadministrasjonssystem er et eksempel på et system som etter vår mening bør beskyttes med tofaktorautentisering.

Eksport av personopplysninger til målsystemer

Både eADM og eFEIDE inneholder personopplysninger, og man bør være forsiktig med hvilke opplysninger som eksporteres til hvilke målsystemer. En tommelfingerregel bør være at man kun eksporterer det minimum av opplysninger som målsystemet trenger. I tillegg bør det gjennomføres en behovsvurdering for opplysninger som personnummer, privat kontaktinformasjon, lønnsopplysninger osv.

Bruk av nasjonale identitetsnumre i Active Directory

Vi anbefaler at hvis et nasjonalt identitetsnummer brukes som et unikt identifikasjonsattributt i AD (f.eks. i attributtene employeeID eller employeeNumber), bør dette enten krypteres (det finnes funksjonalitet for dette i begge systemene) eller skjules, slik at kun administratorer har tilgang til å se disse attributtene: Hvordan skjule brukerattributter i Active Directory.

Bruk av nasjonale identifikasjonsnumre i Entra ID / Entra ID

Vi anbefaler ikke bruk av personnummer som unik identifikator i Entra ID, da dette feltet ikke kan beskyttes eller skjules. Bruk i stedet ansattnummer eller en annen unik nummerserie.

Sammendrag for AI og søk

Dette dokumentet beskriver det omfattende sikkerhetsrammeverket for Identums eADM- og eFeide-produkter. Det omfatter utviklingsfilosofien «Privacy by Design» og «Zero Trust», ISO 27001-sertifisering via Visma Cloud Delivery Model og sikker hosting i Microsoft Entra ID. Rammeverket inkluderer kontinuerlig trusselovervåking av Visma SOC, årlige penetrasjonstester, robuste sikkerhetskopierings- og katastrofegjenopprettingsplaner, samt detaljerte retningslinjer for kryptering, tilgangskontroll og GDPR-kompatibel datahåndtering.