Ekstern sikkerhetsdokumentasjon

1. Utvikling og «Privacy by design»

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

1. Proactive not Reactive; Preventative not Remedial

2. Privacy as the Default Setting

3. Privacy Embedded into Design

4. Full Functionality — Positive-Sum, not Zero-Sum.

5. End-to-End Security — Full Lifecycle Protection

6. Visibility and Transparency — Keep it Open

7. 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. 

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. Identum er definert som kritisk infrastruktur og mottar varsling fra NCSS 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 NCSS. 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.

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). Kommunikasjon mellom Identum sine servere, klienter, nettlesere og tredjepartssystemer er ende-til-ende kryptert via TLS 1.2 med 2048 bit kryptering. Database, backup og driftssystemer er også kryptert. Videre så er alle brukerdata kryptert og utilgjengelige også for Identum personell.

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.

Backup og gjenoppretting

Databaser blir sikkerhetskopiert hver 10 minutter, produksjonsmiljøet som helhet blir sikkerhetskopiert daglig. Backup blir ikke lagret i produksjonsmiljøet.

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.

Ved behov kan hele drift/servermiljøet gjenopprettes fra null på under seks timer. 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.

Nedetid på kildesystemer

Dersom et kildesystem er nede vil eADM naturlig nok ikke bli oppdatert med nye kildedata. Dataflyt fra eADM 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 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 to 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 varslingskriter, enten på epost eller SMS, f.eks dersom en administratortilgang blir gitt til en bruker.

• 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.

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.

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.

Https://www.visma.com/trust-centre

Visma Cloud Delivery Model. 

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, Office 365, G Suite og andre SAML2.0 autoriseringsløsninger. 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. 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. Logger blir lagret, kryptert, digitalt og fysisk beskyttet iht de samme standarder som Identum sine øvrige data.

Logger kan eksporteres for behandling i tredjepartsystemer.

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. F.eks vil man kunne se hva en bruker har tilgang til i sak/arkivsystem, og hvilken type tilgang det gjelder.

Sikkerhetslogging i eADM loggfører alle påloggingsforsøk, både autoriserte og uautoriserte med hvem, tid, sted (IP), type autentisering og status. 

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.

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.