Ekstern sikkerhetsdokumentasjon
1. Utvikling og «Privacy by design»
Identum utvikler sine løsninger med Privacy by design som grunnfilosofi. De 7 prinsippene er:
Proactive not Reactive; Preventative not Remedial
Privacy as the Default Setting
Privacy Embedded into Design
Full Functionality — Positive-Sum, not Zero-Sum.
End-to-End Security — Full Lifecycle Protection
Visibility and Transparency — Keep it Open
Respect for User Privacy — Keep it User-Centric
For sluttkunde betyr dette at våre løsninger som utgangspunkt er sikre; personvern er innebygget i løsningen, det må ikke konfigureres.
1.1 Zero trust
Zero trust-prinsippet i konteksten av Identity and Access Management (IAM) er en sikkerhetsmodell og strategi som bygger på konseptet at ingen bruker eller enhet, enten innenfor eller utenfor organisasjonens nettverk, noen gang skal få de facto tillit. I stedet for å anta at alt bak brannmuren er trygt, krever zero trust at all tilgang verifiseres og autoriseres kontinuerlig.
Her er noen viktige aspekter av zero trust-prinsippet i forbindelse med eADM:
Identitetsverifisering: Enhver forespørsel om tilgang til systemet krever streng verifisering av identiteten til brukeren eller enheten. Dette er ofte implementert ved hjelp av sterke autentiseringsmetoder, som multifaktorautentisering (MFA).
Minimering av tilgang: Brukerne får kun tilgang til ressursene de trenger for å utføre sine oppgaver (prinsippet om minste privilegium). Tillatelser er ofte granulære og dynamiske, justert basert på brukerens behov og atferd. Dette gjelder både brukeres tilgang til eADM og de rettighetene som systemet settes opp for å gi andre brukere. Typisk vil behovsprøvd tilgangsstyring være bedre på sensitive systemer enn f.eks role based account cotnrol (RBAC).
Kontinuerlig monitorering: All aktivitet overvåkes og analyseres for å oppdage mistenkelig eller uvanlig atferd. Dette kan inkludere uvanlige tilgangsmønstre eller forsøk på å få tilgang til sensitive data.
Databeskyttelse: Selv om identitets- og tilgangsstyring er kritisk, fokuserer zero trust også sterkt på å beskytte data. Dette inkluderer kryptering av data både i transit og i ro, samt å sikre datalagret tilgang basert på behov.
Implementeringen av zero trust i eADM er sentral for å beskytte organisasjoner mot sikkerhetstrusler ved å utfordre tradisjonelle sikkerhetsmodellforutsetninger.
1.2 Dataminimering
Dataminimering handler om å redusere mengden personopplysninger og sensitive data som samles inn, behandles og lagres, til det strengt nødvendige for å utføre legitime funksjoner. Dette prinsippet er en nøkkelkomponent i personvernforordningen (GDPR) og andre databeskyttelseslover, og det bidrar til å redusere risikoen for databrudd og personvernsbrudd.
Begrenset innsamling: Bare de dataene som er nødvendige for spesifikke funksjoner eller tjenester bør samles inn. eADm importerer f.eks ikke lønnsdata som standard, kun dersom det er nødvendig for den enkelte kunde.
Kortere oppbevaringsperioder: Data bør bare lagres så lenge det er en operasjonell eller juridisk forpliktelse. eADm har dataoppbevaringspolicyer som automatisk sletter eller anonymiserer data etter behov. Som standard benytter eADM 365 dager som oppbevaring av deaktiverte brukere, dette kan justeres for den enkelte kunde.
Aggregert 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 identifikasjon.
Tilgangskontroll og minste privilegium: Implementering av streng tilgangskontroll sikrer at kun autorisert personell har tilgang til personopplysninger, og brukerne gis kun de rettighetene de har behov for.
Dataformål og transparens: Klare retningslinjer om hvorfor og hvordan data brukes, som er begrenset til de minst påtrengende måtene for å oppnå de formålene, bidrar til dataminimering.
Pseudonymisering: Hvis identifiserbare data må brukes, kan pseudonymisering (bruk av dataaliaser) bidra til å beskytte personers identitet og redusere effekten ved potensielle datalekkasjer.
Ved å anvende disse prinsippene kan et eADM støtte opp om dataminimeringen i din organisasjon, og dermed bedre beskytte personopplysninger samtidig som det oppfyller regulatoriske krav og fremmer brukervern.
2. Drift og «Grunnprinsippene for IKT-sikkerhet»
På driftssiden har vi basert vår sikkerhetstenkning på Nasjonal Sikkerhetsmyndighet sine grunnprinsipper for IKT-sikkerhet.
2.1 Identifisere og kartlegge enheter, programvare, brukere og behov for tilgang
Oversikt og kontroll på hvor lenge vi tar vare på brukerdata, og rutiner for sletting.
Tilganger skal alltid tildeles på minimumsnivå, ingen skal ha høyere tilgang enn det som er nødvendig for å få jobben gjort
Se avsnittene om tilgang for tilgangsnivå for systembrukere i AD, G suite og M365.
2.2 Beskytte og opprettholde.
Etablere en sikker IKT-arkitektur og beskytt virksomhetens nettverk. Kontrollere dataflyt.
Ha kontroll på identiteter og tilganger.
Alle passord skal lagres i et passordhvelv. Passord skal ikke gjenbrukes. Alle passord og tilganger er personlige.
Får man tilgang til et kundesystem så skal passord og brukernavn slettes når jobben er utført.
Beskytt data i ro og i transitt.
Ta vare på kritisk informasjon om deaktiverte brukere i eFeide og eADM slik at man sørger for å sperre for gjenbruk av brukernavn og andre unike identifikatorer. Etter en satt periode blir logger, personinformasjon og tilgangs/rettighetshistorikk for en bruker automatisk slettet.
2.3 Oppdag og fjern kjente sårbarheter og trusler.
I tråd med det første av grunnprisippene om “privacy by design” streber vi aktivt for å finne sårbarheter i systemet vårt. Vi gjennomfører derfor årlige penetrasjonstester av våre løsninger. Disse utføres av Visma sine eksperter på sikkerhetsfeltet, se mer informasjon under “Penetrasjonstesting”.
Trusselvurdering gjøres i samarbeid med Nasjonalt cybersikkerhetssenter (NCSC). Identum er definert som kritisk infrastruktur og mottar varsling fra NCSC når det oppdages sikkerhetshull og exploits i serversystemer, programvare og andre IT-systemer. Trusselvurderinger gjøres løpende av Identum basert på info fra NCSC. Relevante sikkerhetshull blir patchet fortløpende etter hvert som vi blir kjent med dem.
Alle Identum sine serverer, både i produksjon og testmiljø, blir oppdatert ukentlig. Det gjelder både operativsystem, installerte apper og annen programvare. I tillegg oppdateres også eFeide og eADM på søndager, iht 14-dagers utviklingssprinter. Identum har en egen ressurs med ansvar for å ivareta dette. Etter patching/oppdatering blir alle systemer testet for å sikre full funksjonalitet. Søndag er valgt pga lav belastning og bruk på søndag. eFeide blir ikke oppdatert ifm skolestart og eksamensavvikling, med unntak av driftskritiske oppdateringer.
4. Håndtere og gjenopprette
Alle uønskede hendelser angående sikkerhet eller personvern registreres i eget register, med tid, sted, hvem, tiltak og oppfølging i etterkant. Prosedyrene er dokumentert i Identum sin interne beredskapsplan.
Kunder varsles rutinemessig om både interne og eksterne uønskede hendelser. Prosedyrene er dokumentert i Identum sin interne beredskapsplan.
Der det er relevant, blir trusselvurderinger fra NCSS delt med kundene.
Identum har avtale om bistand fra Visma sin egen cybersikkerhetsgruppe hvis selskapet kommer under angrep, blir hacket eller hvis datasikkerheten på annet vis er truet. Visma vil da etablere et responsteam som vil være ansvarlig for å håndtere situasjonen, få den under kontroll og gjenopprette ev berørte systemer. I tillegg har vi “hot backup” av våre systemer, som gjør at man ila minutter kan etablere et alternativt servermiljø dersom det vanlige går ned pga DDOS eller andre typer angrep.
3. Systemovervåkning og trusselhåndtering
Identum AS er fra 01.02.2023 et heleid datterselskap av Visma AS og underlagt Visma sine rutiner for cybersikkerhet, overvåkning og trusselhåndtering. Visma benytter Sentinel One (https://www.sentinelone.com/ ) for Managed Detection and Response (MDR). Sentinel One kjører kontinuerlig overvåkning av Identum sine servere, klienter, endepunkter og ansatte sine datamaskiner. Alle hendelser blir logget, evaluert og trusler blir automatisk aktivt fulgt opp av Visma sitt Security Operations Centre (SOC)-team.
Ved en tilstrekkelig alvorlig sikkerhetshendelse eller angrep blir Identum varslet av Visma, de har respons 24/7/365 og vil iverksette tiltak også før Identum blir varslet. Dersom hendelsen/angrepet blir evaluert til å være kritisk eller rettet mot en spesifikk kunde, blir kunden varslet umiddelbart og tatt med inn i teamet som håndterer hendelsen. Normal varslingstjeneste for våre kunder er via epost, i slike tilfeller vil dere også bli oppringt.
Bakdør og tilgang hvis ordinær pålogging er nede
Identum har sine egne “break glass”-kontoer i vårt driftsmiljø. Dersom ordinær pålogging for våre ansatte er av en eller annen grunn er ute av drift, kan slike kontoer benyttes til å gi eller gjenopprette tilgang til systemet. Denne bakdøren benyttes ikke i ordinær drift, og all pålogging er overvåket med øyeblikkelig varsling.
I de tilfeller der kunden sin pålogging til eADM ikke fungerer (f.eks hvis kunden sin AAD er nede og SSO derfor ute av drift), kan Identum endre til en annen innlogging i perioden kunden har nedetid, f.eks fra Azure AD SSO til innlogging med IDporten.
Penetrasjonstesting
Årlig utføres en sikkerhetsgjennomgang og penetreringstest av våre løsninger av Visma sitt cybersikkerhetsteam. Gjennomgangen viser eventuelle svakheter eller forbedringspunkt som vi da forbedrer fortløpende. Ved sist gjennomførte test ble ingen alvorlige risikomomenter oppdaget. Om ønskelig kan vi ha en gjennomgang av resultatene av denne testen. Av sikkerhetsårsaker ønsker vi ikke å dele selve rapporten.
Våre kunder står selvsagt fritt til å kjøre sin egen penetrasjonstesting, med eller uten bistand fra tredjeparter valgt av kunde.
4. Drift og hosting
Identum sine løsninger er skybaserte og driftes og vedlikeholdes hos vår driftspartner Microsoft Norge, med redundans, ekstern backup og lastbalansering. Fysisk står serverene på Østlandet i Norge. Oppetidsgaranti er 99,9 % (se vår SLA).
Identum er ansvarlig for operativsystem og software mens Microsoft tar seg av drift av maskinvare, kommunikasjon, offsite backup, redundans og brannmur. Kun ansatte med teknisk ansvar i Identum eller nødvendig driftspersonell hos Microsoft har aksess til servermiljø. Dette skjer via Teamviewer klienter med MFA. Identum har en utvidet SLA avtale med Microsoft med responstid innen 10 min innen kontortid og 1 time ellers.
De eneste brannmurporter som er generelt åpen for inngående trafikk er port 80/433 for bruk av Teamviewer, webklienter og api klienter. All trafikk til port 80 blir automatisk routet til 433 slik at kommunikasjonen skjer på kryptert linje via TLS. Alle webtjenester / sider interne og eksterne er sikret med SSL sertifikater fra Digicert.
Patching og oppdatering
Patching av systemer, komponenter, servere, databaser osv gjøres hver søndag. Identum har en dedikert ressurs til dette. Identum er definert som kritisk infrastruktur og mottar varsling fra Nasjonalt cybersikkerhetssenter (NCSC) når det oppdages sikkerhetshull og exploits i serversystemer, programvare og andre IT-systemer. Trusselvurderinger gjøres løpende av Identum basert på info fra NCSC. Relevante sikkerhetshull blir patchet fortløpende etter hvert som vi blir kjent med dem.
Oppdatering av systemer, komponenter, servere, databaser osv gjøres også hver søndag. Identum benytter seg som standard ikke at beta-funksjonalitet eller -versjoner.
Kryptering
Identum sine servere er hostet i Azure sky og benytter da standard server-side kryptering av all data ved lagring. Krypteringsnøklene håndteres av Azure plattformen automatisk. https://learn.microsoft.com/en-us/azure/virtual-machines/disk-encryption.
Kommunikasjon mellom Identum sine servere, klienter, nettlesere og tredjepartssystemer er ende-til-ende kryptert via TLS 1.2 med 2048 bit kryptering, og sertifikatene blir utstedt av Digicert. Disse installeres og vedlikeholdes av de medlemmer av vårt driftsteam som har nødvendig tilgang til servere og digicert tjenesten. De byttes ut/har gyldighet etter bransjestandard (12 måneder)
Database, backup og driftssystemer er også kryptert. Videre så er alle brukerdata kryptert. I eADM og eFeide er alle systempassord (secrets) sikret med Rijndael AES 256-bit kryptering. Passord til brukere er lagret i vår LDAP database som benytter standard Active Directory teknologi og lagrer da de hashet og kryptert. Ved overføring av passord (secrets) så benyttes alltid ende til ende kryptering via TLS.
Backup og gjenoppretting
Databaser blir sikkerhetskopiert hver 10 minutter, produksjonsmiljøet som helhet blir sikkerhetskopiert daglig. Backup blir ikke lagret i produksjonsmiljøet, men på et fysisk separat miljø.
For å verifisere både kvalitet og innhold på sikkerhetskopier og teste gjenoppretting av data, blir Identum sitt testmiljø alltid opprettet fra sikkerhetskopier. Testmiljøet er en fullstendig kopi av produksjonsmiljøet. Dette gjøres minimum hver 14 dag.
Kontinuitetsplan
Ved behov kan hele drift/servermiljøet gjenopprettes fra null på under seks timer, enten i samme miljø eller i et sekundært miljø (f.eks hvis primærmiljø blir utsatt for et DDOS-angrep). Det er også mulig å gjenopprette enkeltkunder fra backup. Dette kan gjøres både dersom det oppstår feil ifm oppgradering eller tekniske endringer av løsningen, eller dersom kunden har behov for å gjenopprette f.eks etter en import av korrupte data fra kildesystemet. Dette kan bestilles via Identum sin brukerstøtte, og slike henvendelser vil bli behandlet som en nivå A-feil iht kunden sin enhver tid gjeldende Service Level Agreement. Dersom Identum på egen hånd bestemmer seg for at enten hele servermiljøet eller en spesifikk 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 Risk assessment, Risk mitigation og Risk management. Risikoer blir identifisert og vurdert iht alvorlighetsgrad og sannsynlighet (risk assessment). For hver risiko skal det foreligge en forebyggende plan (risk mitigation) og en håndteringsplan (risk management) dersom risikoen faktisk inntreffer. Dette materialet er en del av Identum sin interne sikkerhetsdokumentasjon. Dette er, naturlig nok, ikke offentlig informasjon.
Se også avsnitt 3 “Systemovervåkning og trusselhåndtering” og avsnitt 5. “ISO27001 og Visma Cloud Delivery Model”
Konsekvenser av nedetid på eADM
Dersom eADM har nedetid vil alle kontoer i organisasjonen fungere som før, med alle rettigheter og tilganger. Så lenge eADM er nede, vil kontoer ikke bli opprettet/oppdatert/deaktivert/slettet og ingen tilganger/lisenser vil bli gitt/endret/fjernet av eADM. Det vil fremdeles være mulig å gjøre dette manuelt i det enkelte målsystem.
Konsekvenser av nedetid på eFeide
Dersom eFeide, som Brukeradministrasjonssystem (BAS) for FEIDE-katalogen, opplever nedetid vil FEIDE-innlogging fortsatt fungere som før. Det er kun dersom SIKT (Kunnskapssektorens tjenesteleverandør, https://sikt.no/) opplever nedetid at FEIDE-pålogging blir utilgjengelig.
Dersom eFeide har nedetid vil passordhåndteringsfunksjonalitet, eTID internettilgangsstyring og MFA-administrasjon av FEIDE-kontoer være utilgjengelig.
Nedetid på kildesystemer
Dersom et kildesystem er nede vil eADM og eFeide naturlig nok ikke bli oppdatert med nye kildedata. Dataflyt fra eADM og eFeide til målsystemer vil fortsette som før. Eksempel på dette er passordendringer, endringer i gruppe/teamsmedlemskap, roller og rettigheter.
Når kildesystemet igjen er tilgjengelig vil eADM og eFeide prosessere alle kildedata på nytt, slik at alle ventende brukere osv. får de nødvendige kontoer og tilganger.
Nedetid på målsystemer
Dersom et målsystem er nede i en kortere eller lengre periode, blir endringer lagt i en eksportkø. Når målsystemet er tilgjengelig igjen blir køen prosessert. Eksempler på endringer som legges i eksportkø er attributtendringer (f.eks navn på en bruker), passord, gruppe/teams-medlemskap, roller og tilganger. Det loggføres i eADM når endringer ble lagt i eksportkø og sendt til de forskjellige målsystemene.
Varsling
Identum har flere typer varsling om feil, nedetid eller andre hendelser som har negativ påvirkning for tjenesten:
Automatisk systembasert varsling -> Systemet sender ut en statusrapport etter hver fullførte synkronisering med overordnet informasjon. I tillegg vil systemet varsle dersom synkronisering stanser, f.eks som en følge av korrupte data eller om et målsystem ikke svarer. Det er også mulig å sette opp sine egne varslingskriterier, enten på epost eller SMS, f.eks dersom en administratortilgang blir gitt til en bruker.
eADM kan settes opp til å varsle automatisk ved feilmeldinger på enkeltbrukere, f.eks dersom en oppdatering feiler i et målsystem (gitt at målsystemet støtter dette!).
Manuell varsling -> Identum har en egen varslingsliste med epost og SMS for alle administratorer i eADM og/eller eFeide. Denne listen brukes til å varsle om hendelser som negativt påvirker en eller flere kunder. Identum har lav terskel for å sende ut varsel.
Kunder som har sine egne overvåkningssystemer kan knytte seg opp til loggene i eADM via API og automatisk hente ut fortløpende logger med varsel, oppdateringer og feil
Feilrapportering
Alle feil som oppdages av kunde kan meldes direkte til Identum via skjema tilgjengelig for administratorer i eFeide og eADM. Dette gjelder alle typer feil, både feil med systemet og varsler om personvern-relaterte hendelser og tiltak. Alle personvern-relaterte hendelser blir behandlet som en feil med nivå A iht avtalt tjenestenivå (SLA). Alle hendelser blir håndtert iht grunnprinsippene for IKT-sikkerhet, pkt 4.-4.4.
eADM og eFeide har også innebygd funksjonalitet for å sende inn forbedringsforslag. Alle forslag vurderes fortløpende.
5. Informasjonssikkerhet
GDPR og personvern
Som grunnprinsipp for import av kildedata til våre systemer gjelder det at vi kun importerer brukere og brukerdata som skal behandles videre. Dersom en ansatt ikke skal ha konto i AD, vil vi filtrere denne fra å bli importert inn i våre systemer overhodet. Foresattdata benyttes ikke ved import til Feidekataloger. Kun relevante brukerdata blir importert, eksempelvis importerer vi stillingsprosent (som kan være relevant ifm tildeling av lisenser) i motsetning til lønnsdata som vi ikke importerer.
Det er viktig å understreke at det er kildedatasystemene (HRM og SAS) som er overstyrende. Når en bruker opprettes i HRM, blir brukeren opprettet i eADM. Når en bruker deaktiveres eller slettes fra systemet vil tilhørende data også bli slettet, iht regler satt i eADM. Det kan for eksempel automatiseres at brukere først deaktiveres og så slettes fra systemet etter en gitt tidsperiode. Sikkerheten og personvernet i eADM er helt avhengig av at kunden har gode rutiner ifm inn- og utmelding av brukere fra sine kildesystemer.
Et vanlige hjertesukk fra administratorer når det kommer til livssyklusen til brukerkontoer er at “alle får med seg når noen begynner, men ingen får med seg når noen slutter”. Dermed kan man risikere at gamle brukerkontoer og persondata liggende igjen i lang tid. Løsningen på dette er gode regelsett i eADM som sørger for at data som ikke skal lagres blir slettet f.eks når brukeren blir deaktivert, går ut i permisjon, dør eller slutter. eADM automatiserer dette og sørger for alle brukerkontoer enten fjernes automatisk eller at nødvendige mottakere varsles der noe må gjøres manuelt. Via meldingsmaler kan man varsle IT, drift, admin, når utstyr skal leveres inn, tilganger skal endres eller fjernes.
Alle brukere har pålogging til brukergrensesnittet, og alle kan se alle data som er registrert for egen bruker til enhver tid. I forbindelse med GDPR og personvern kan sluttbrukere se sine data i en personvernseksjon der vi også opplyser om hvor dataene kommer fra, hvem de skal henvende seg til hvis noe ikke stemmer eller om de ønsker dataene slettet.
Identum sine løsninger oppfyller alle krav til Norm for informasjonssikkerhet.
Se bilag 9 i kontrakten for databehandleravtalen til Identum AS. Vi har som prinsipp at vi tilpasser oss kundene våre, istedenfor at de må tilpasse seg oss. Dersom vår standard databehandleravtale ikke dekker kundens behov, tilpasser vi oss og benytter den kunden ønsker.
ISO27001 og Visma Cloud Delivery Model
Identum AS er fra 01.02.2023 et heleid datterselskap av Visma AS og derav underlagt deres kvalitetssystem og leveransemodell som beskrevet her:
Visma Cloud Delivery Model (VCDM) beskriver vår tilnærming til å utvikle, levere og drifte skytjenester. Den beskriver aspekter ved hvordan vi bør være organisert, hvordan vi bør jobbe (prosesser) samt tekniske krav og beste praksis som er nødvendig for vellykket levering av skytjenester. Ytterligere informasjon om VCDM finnere dere på: https://www.visma.com/trust-centre/vismaclouddelivery
Modellen er basert på et sett med kjerneprinsipper og fokuserer på DevOps og Continuous Delivery. VCDM har følgende revisjonserklæring og sertifiseringer:
ISAE 3402 SOC 1 Type II
ISO 27001
Visma Security Program og Visma Architecture and Technology Programme er integrert i Visma Cloud Delivery Model. Vårt styringssystem for informasjonssikkerhet (ISMS) er sertifisert i henhold til ISO 27001 og det revideres årlig av en uavhengig IT-revisor.
I tillegg revideres Vismas evne til å etterleve ISMS og kvalitetsstyringssystemet i VCDM av et uavhengig revisjonsselskap i henhold til ISAE 3402. Denne omfattende kontrollen gjennomføres også årlig og er oppsummert i en ISAE 3402 Type II rapport.
Vår tilnærming til implementering av endringer er fortløpende integrering og implementering (Continuous Integration and Continuous Deployment - CI/CD).
Metodikken utvikler seg stadig med tanke på teknologi, kompetanse og prosedyrer. Akkurat nå betyr dette at endringer blir fortløpende verifisert og implementert i vårt stagingmiljø. Der gjøres det manuelle tester både internt i utviklingsavdelingen og av fageksperter. For mer omfattende endringer benytter vi oss også av pilotkunder som tester endringene i normal drift en periode før de slippes til alle kunder.
Https://www.visma.com/trust-centre
Endringer og oppdateringer
Endringer og oppdateringer medfører som hovedregel ikke nedetid. Dersom det skjer, vil det gjennomføres i forhåndsdefinerte servicevinduer og varsles iht. SLA.
Vi har en felles, automatisk, prosess for oppgradering 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 (eng: “feature toggles”), slik at funksjonaliteten først aktiveres når den er klar for kunden. I samspill med automattester gir dette høy stabilitet, færre feil og hurtig utrulling av nye funksjoner.
Oppdateringer vil bli ulikt kommunisert avhengig av størrelse og omfang av endringen:
Mindre endringer som feilrettinger som ikke påvirker kunden eller brukeren vil bli varslet gjennom oppdatering av release notes
Medium endringer som for eksempel endringer eller tillegg i arbeidsprosesser eller skjermbilder vil bli annonsert i release notes, varslinger i startsiden, oppdatert brukerdokumentasjon og på Visma Community.
Større endringer som ny nøkkelfunksjonalitet eller en større endring i en arbeidsprosess vil i tillegg kunne ha webinarer og/eller oppdatert e-læring
Ved større endringer som krever opplæring og/eller konfigurasjon av systemet vil vi involvere kunde før vi implementerer endringen. Omfanget av dette vil variere avhengig av hva slags endring det er. Vår strategi rundt håndtering av eventuelle feil som skulle oppstå ved oppdateringer, er å “rulle fremover” (roll-forward). Dette innebærer at vi ønsker å rette feilen og oppdatere med ny versjon, fremfor å rulle tilbake. Kun unntaksvis og ved alvorlige feil, vil det være aktuelt å rulle tilbake.
6. Sikkerhet og tilgangsstyring
Identum drifter sin programvare i hovedsak via webapplikasjoner: http://mega.efeide.no og http://mega.eADM.no . All tilgang til webapplikasjonene er beskyttet av captcha, brukernavn og passord samt 2FA autentisering. Kunde kan selv benytte disse portalene for administrasjon og selvbetjening, men da med andre tilganger og rettigheter (se avsnittet om tilgangsstyring).
Vi anbefaler alle våre kunder å benytte autentisering med MFA aktivert, og vi har som krav at alle tilganger til alle våre systemer på administratornivå skal være med MFA. Vi tilbyr pålogging via brukernavn/passord med MFA, IDporten eller SSO med Azure AD. Dersom SSO benyttes krever vi at tilgang beskyttes på rettighetsnivå Avdelingsleder og oppover.
Det er et viktig prinsipp å ikke gi høyere tilgang enn det som er nødvendig. Vi anbefaler derfor at dere er restriktive med å gi tilgang på administratornivå. For det aller meste av daglig drift er servicedeskbrukertilgang godt nok. For brukere som skal løse kun en spesifikk oppgave, for eksempel administrere passord for en avdeling, er superbrukertilgang nok. Kun helt nødvendig personell bør ha administratortilgang til systemet og denne bør vurderes tidsbegrenset. Dette prinsippet begrenser innsyn i persondata og mulighetene for å tildele tilganger eller rettigheter.
Alle endringer som blir utført via webgrensesnittet blir automatisk loggført. Kunden blir rutinemessig varslet ved 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 administratortilgang, denne funksjonaliteten er en del av løsningene.
Vår policy for tilgangsstyring er at brukere ikke skal få et høyere rettighetsnivå enn det de trenger i det daglig, høyere tilgang vurderes etter behov. Administratortilgang skal kun tildeles få utvalgte brukere som har gjennomført opplæring i bruk av systemet. Et eksempel kan være at 1.linje brukerstøtte hos kunden har servicedesktilgang, mens kun 3.linje 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 fagsystemer, tredjeparter osv via eADM.
Internt personell
Dette gjelder også Identum sine egne ansatte. Ansatte får kun nødvendig tilgang iht stilling og funksjon. Når ansatte slutter blir alle tilganger fjernet umiddelbart. Identum benytter seg ikke av bistand fra eksterne tredjeparter og har en policy på at kun ansatte som aktivt arbeider med drift og brukerstøtte av løsningen har tilgang til kundene sine data.
De forskjellige tilgangsnivåene og rollene i Identum er fast definert, og blir iht ISO27001 revidert og behovsprøvd med jevne mellomrom.
Alle endringer som gjøres i systemet blir loggført på lik linje med kunden sine egne brukere. Så om en ansatt i Identum gir en tilgang til et fagsystem hos en kunde, blir det loggført i historikken til brukeren som fikk tilgangen.Det er ikke mulig å kopiere brukerdata mellom de forskjellige instansene i brukergrensesnittet, kun maler og regelsett.
Tilgangskontroll
Både eFeide og eADM støtter forskjellige metoder for brukerpålogging, herunder også tofaktorautentisering. Vi tilbyr (selvsagt) FEIDE-pålogging, IDporten, ADFS/LDAP, SSO med Azure/EntraID, SSO med Google Workspace og andre SAML2.0 autoriseringsløsninger. Vi forventer at kundene beskytter SSO-pålogging med MFA, det er ikke anbefalt at tilgang til eADM og eFeide er uten tofaktorbeskyttelse, selv på ansatt/avdelingsledernivå. På servicedesk og administratornivå har vi krav om at kundene våre skal beskytte SSO med MFA, alternativt benytte IDporten.
Systemtilganger kan gis automatisk basert på regelsett eller manuelt for den enkelte bruker. Vi anbefaler at administratortilganger kun gis manuelt og behovsprøvd. Tilganger kan gis med eller uten utløpsdato og systemet har løsning for både aktiv og passiv tilgangsrevisjon ved gitte tidsintervaller.
De forskjellige tilgangsnivåene kan administreres på gruppe, rolle og personnivå. For eksempel kan påloggingen til brukergrensesnittet for eFeide reguleres slik at alle som har tilgang til å se persondata om andre brukere må logge på med tofaktorautentisering, mens studenter (som kun kan se sine egne data) kan logge på uten bruk av tofaktor.
Systemet tar også høyde for at en og samme bruker kan ha forskjellige roller i de forskjellige avdelingene, med varierende behov og tilganger. En ansatt kan se all tilgjengelig informasjon om seg selv og bytte passord. En avdelingsleder ser kun sine ansatte. Dersom en bruker er avdelingsleder og samtidig er ansatt på et annet nivå i organisasjonen, vil denne brukeren kun ha administratortilgang til avdelingen hvor han/hun er avdelingsleder. På den andre avdelingen vil han/hun kun ha ordinær ansatt-tilgang.
De seks rollene gir tilgang til funksjonsområder, underliggende informasjon og funksjonalitet. Under følger en tabell som viser hvilke operasjoner rollene har tilgang til:
Historikk, logger og tilgangsrevisjon i eADM
eADM har full loggføring av alle endringer som blir gjort på objektnivå, altså for brukere, grupper og avdelinger. Loggene er tilgjengelig for alle med administratortilgang i løsningen. Både endringer som kommer inn fra kildesystem og endringer som gjøres i eADM loggføres. Systemet logger også alle data sendt til de forskjellige kildesystemene, slik at man har full oversikt over hvilke data som er eksportert hvor. Alle oppføringer loggføres med objektID, dato/klokkeslett, årsaken til endring, hvem som utførte endring dersom det er en manuell endring, forrige verdi og ny verdi.
Alle endringer i selve systemoppsettet logges også. Med det menes alle endringer på regelsett, synkroniseringsmaler, meldingsflyter, tilgangsstyringer og arbeidsflyter.
Alle logger blir lagret, kryptert, digitalt og fysisk beskyttet iht de samme standarder som Identum sine øvrige data. Logger kan ikke endres av noen typer brukere, inkludert Identum sin egen superduperadministratorrolle. Logger kan eksporteres for behandling i tredjepartsystemer.
Alle hendelser, logger osv kan settes opp til å utløse varsel på e-post eller SMS når de opptrer. F.eks kan systemet varsle om spesifikke feilmeldinger ifm eksport til sensitive systemer eller når en bruker logger seg på med en IP-adresse utenfor et gitt geografisk område.
Logging av endringer på brukerdata, rettigheter og tilganger
I brukergrensesnittet til eADM kan en 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, om det ble gitt automatisk på basis av regelsett eller manuelt av en bruker. Man vil kunne se hva en bruker har tilgang til i sak/arkivsystem, og hvilken type tilgang det gjelder. eFeide logger alle rettighetsendringer i tillegg til endringer i brukerdata og passord. Dersom en tilgang er gjort av et regelsett, kan man videre spore hvem som gjorde endringen i regelsettet som utløste tilgangen.
Sikkerhets- og passordlogger
Sikkerhetslogging i eADM loggfører alle påloggingsforsøk, både autoriserte og uautoriserte med hvem, tid, sted (IP), type autentisering og status. I tillegg logges alle feilmeldinger, med metode (f.eks type API-kall), tid, bruker og IP.
Alle passordbytter blir loggført, med tid og datostempel, hvordan passordbyttet ble gjort, hvem som initierte passordendringen, om passordet ble eksportert videre til andre målsystemer og med eventuelle feilmeldinger.
Tredjepartstilgang
Kunden styrer selv hvem som har tilgang til kundedata i eADM via brukergrensesnittet. Identum benytter seg ikke av underleverandører og gir ikke tilgang til kundedata til tredjeparter.
Dataflyt til tredjeparter er styrt via synkroniseringsmaler der kunden selv bestemmer hvilke data som skal eksponeres for/overføres til hver enkelt tredjepart. For API-baserte integrasjoner kjører eADM kun PUSH, dvs at eADM er den som initierer dataoverføring og styrer hvilke data som blir overført. eADM tillater ikke at tredjeparter kan hente data fra systemet etter eget forgodtbefinnende.
Det er ikke mulig å få tilgang til andre kunder sine data gjennom eADM. Selv om f.eks en administratorkonto hos kunde A blir overtatt av en ekstern part, vil ikke denne tilgangen kunne brukes til å få innsyn i kundedata hos kunde B. Se også punktet «Penetrasjonstesting».
Håndtering av passord
I eADM og eFeide er alle systempassord (secrets) sikret med Rijndael AES 256-bit kryptering. Passord til brukere er lagret i vår LDAP database som benytter standard Active Directory teknologi og lagrer da de hashet og kryptert. Ved overføring av passord (secrets) så benyttes alltid ende til ende kryptering da via TLS. Dette gjelder for all overføring av data til og fra løsningen.
Passord er ikke tilgjengelig for noen brukere i eADM eller eFeide, det være de ansatte selv, avdelingsleder eller administratorer. Det eneste unntaket er førstegangspassord, naturlig nok siden de må kunne leses, skrives ut og sendes til den ansatte. Etter første pålogging vil dette passordet bli endret og lagret kryptert. Fra da av vil ikke noen kunne se det, det kan kun endres.
Førstegangspassord for brukere blir skapt i eADM/eFeide når en brukerkonto blir opprettet. Passordet blir generert iht regelsett satt opp etter krav fra kunde, f.eks 16 tegn, stor bokstav, minst 1 spesialtegn. Når en brukerkonto blir opprettet i målsystemer som AD, Azure eller fagsystemer, kan brukerne bli opprettet med samme førstegangspassord. Dette blir overført kryptert.
Passord kan endres i våre løsninger og overføres i sanntid til målsystemene. Det kan settes krav om at brukere må endre førstegangspassord før de får tilgang til å logge på. Identum har løsning for å tilbakestille passord via SMS eller via autentisering gjennom IDporten, og vi anbefaler helt klart IDporten.
Alle passordbytter blir loggført, med tid og datostempel, hvordan passordbyttet 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 på SMS dersom det er registrert et mobiltelefonnummer på brukeren. Vi anbefaler dog at prosedyren bør være at ansatte gjør dette selv via glemt-passordportalen.
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 på SMS dersom det er registrert et mobiltelefonnummer på brukeren. Vi anbefaler dog at prosedyren bør være at ansatte gjør dette selv via glemt-passordportalen.
I eFeide kan lærere endre passord på elever, skoleADMinistratorer kan endre passord for elever og lærere ved sin skole og kommuneADMinistratorer kan endre passord for alle brukere.
Sikkerhet og feidetjenester
I eFeide kan administratorer administrere pålogging med MFA til gitte Feidetjenester for ansatte. Krav om MFA for Feidetjenester kan settes både individuelt og for hele skoler. En tofaktor-metode er det en bruker benytter for å bevise sin identitet når en Feidetjeneste krever tofaktor-autentisering. Feide har fire forskjellige tilgjengelige tofaktormetoder; pålogging via IDporten, kode via sms, kodeark og godkjennerklient (MS Authenticator eller Google Authenticator).
Hvilke Feidetjenester som skal beskyttes med MFA er opp til den enkelte kunde, vår tommelfingerregel er at alle Feidetjenester der det er lagret personinformasjon om elever og/eller ansatte bør beskyttes med MFA. Et skybasert skoleADMinistrativt system er et eksempel på et system som etter vår mening bør beskyttes med tofaktorpålogging.
Eksport av persondata til målsystemer
Både eADM og eFEIDE inneholder persondata, og man børe være aktsom med hvilke data som eksporteres til hvilke målsystemer. Tommelfingerregel bør være at man bør kun eksportere det minimum av data som målsystemet har behov for. I tillegg bør det gjennomføres en behovsprøving for data som fødselsnummer, privat kontaktinformasjon, lønnsinformasjon osv.
Bruk av fødselsnummer i Active directory
Vi anbefaler at dersom fødselsnummer benyttes som en unik identifiserende attributt i AD (f.eks i attributtene employeeID eller employeeNumber. , bør denne enten krypteres (dette er det funksjonalitet for i begge systemene) eller skjules slik at visning av denne attributtene kun er tilgjengelig for administratorer: Hvordan skjule visning av attributter på AD-brukere?
Bruk av fødselsnummer i Azure AD / Entra ID
Vi anbefaler ikke bruk av fødselsnummer som unik identifiserende attributt i Azure AD, da dette feltet ikke kan beskyttes eller skjules. Benytt istedenfor ansattnummer eller en annen unik nummerserie.
7. Tilgang til tredjepartsystemer
Tilgang til kildesystemer
Identum har ikke behov for permanent brukertilgang til kildesystemer som HRM/lønn/personalsystem, oppvekstadministrative systemer, barnehagesystem, voksenopplæring osv. Tilgang til utdataeksporten fra systemene det gjelder er tilstrekkelig, enten det er via filoverføring eller API. Ved behov og på forespørsel vil vi kunne få midlertidig tilgang ifm feilsøking, opplæring og lignende.
Tilgang til Dataporten/Feide kundeportal
Vi har ikke behov for permanent tilgang til dataporten eller Uninett sin kundeportal. Ved behov og på forespørsel vil vi kunne få midlertidig tilgang.
Tilgang til Azure Active Directory
Dersom våre systemer skal synkronisere brukere, grupper, passord, lisenser, medlemskap og status til AAD vil vi trenge tilgang tilsvarende brukeradministrator i M365 i prosjektperioden. Denne kontoen skal beskyttes med MFA. Kontoen skal stenges når prosjektperioden er over.
Selve kommunikasjonen mellom eADM/eFeide og Azure AD gjøres via en Azure applikasjon, som beskrevet på vår dokumentasjonsportal: https://docs.identum.no/eadm/klargjre-for-integrasjon-mellom-eadm-efeide-og-azu
Tilgang til Google Workspace
Dersom våre systemer skal synkronisere brukere, grupper, passord, OUer, medlemskap og status til Google Workspace vil vi trenge en bruker med tilgang tilsvarende brukeradministrator. Denne kontoen skal beskyttes med MFA. Denne brukeren kan deaktiveres når prosjektperioden er over om ønskelig. I tillegg vil kunden sin globale administrator måtte legge inne tilgangsnøkler til vår API-klient.
Tilgang til lokal Active Directory
Hvor det er nødvendig så installeres det en egen klient i kundens interne nettverk som kommuniserer med skyløsningen via kryptert linje (TLS 1.2 port 443). Klienten er en Windows-basert .Net konsollapplikasjon som blir kjørt lokalt via Task scheduler via en servicebruker. Hvilke rettigheter denne trenger avhenger av om den skal kun stå for dataflyt til vårt servermiljø, drive lokal AD integrasjon og hvilke objekttyper den skal vedlikeholde i lokal AD. Vi anbefaler at servicebruker bare får akkurat de rettighetene som er nødvendig for å utføre de oppgavene den skal.
Vi har lagt opp til at det alltid er klient som initierer kommunikasjon til serverne, det er ikke nødvendig å åpne opp for innkommende kommunikasjon. Alle kunder har sine egne unike autentiseringsnøkler som benyttes av klienten til å kommunisere med skyen.
I prosjektperioden vil prosjektleder og/eller utførende konsulent trenge tilgang til lokal AD, f.eks via VPN eller Teamviewer. Tilgangen skal være beskyttet med MFA. Dette kan være til primær domenekontroller eller (helst!) en dedikert server for eADM som har tilgang til Active directory users and computers, Active directory module for Windows Powershell og Windows Exchange management tools for Powershell. Krav er at server har minimum .Net 4.0 og minimum Powershell 4.0. Brannmur må ha åpning ut på port 443, standard SSL. Fint om dere også sørger for at Notepad++ er installert på serveren.
Selve eADM-klienten er en Windows-basert .Net konsollapplikasjon som blir kjørt lokalt via Task scheduler via en servicebruker. Derfor trenger vi en servicekonto med følgende rettigheter:
Rettighet i AD for å opprette, slette og endre brukere, grupper og OU
Rettighet til å kjøre oppgaver som en batch job (scheduled task)
Lokal full skrive/leserettighet til c:\eADM og undermapper
Eventuelt rettighet til å opprette og sette NTFS rettigheter for hjemmeområder
Eventuelt rettighet til å opprette mailbokser (enable-mailbox og enable-remotemailbox)
Brannmur må tillate utgående oppkoblinger til https://app1.eADM.no/Service.asmx
Når systemet er i drift, skal våre personlige brukerkontoer stenges, alle driftsoppgaver skal utføres av servicebruker. Passordet til servicebruker skal da endres slik at vi ikke har det. Identum har ikke behov for permanent tilgang til kundens miljø uten prosjektperiode, nødvendig vedlikehold eller på forespørsel ifm support, rekonfigurering eller lignende arbeid.