Sikkerhetsdokumentasjon

1. Utvikling en "privacy door ontwerp

Identum maakt gebruik van een aantal diensten Privacy door ontwerp in plaats van in een grote wereld. De 7 principes zijn:

1. Proactief niet reactief; preventief niet corrigerend

2. Privacy als standaardinstelling

3. Privacy ingebed in ontwerp

4. Volledige functionaliteit - Positief-som, niet nulsom.

5. End-to-end beveiliging - Volledige levenscyclusbescherming

6. Zichtbaarheid en transparantie - houd het open

7. Respect voor gebruikersprivacy - houd de gebruiker centraal

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 Nul vertrouwen

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.

Hier zijn geen verschillende aspecten van zero trust-prinsippet in combinatie met eADM:

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

2. Minimalisering van 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).

3. Kontinuerlig monitoring: Alle activiteiten worden gecontroleerd en geanalyseerd om een oplossing te vinden voor onduidelijke of ongevoelige gegevens. Dette kan inkludere uvanlige tilgangsmønstre eller forsøk på å få tilgang til sensibiliske data.

4. Databeskyttelse: Selv om identitets- og tilgangsstyring er kritisk, fokuserer zero trust også sterkt på å beskytte data. Dit omvat het versleutelen van gegevens bij doorvoer en in de computer, evenals het beveiligen van gegevens op basis van gedrag.

Implementatie van zero trust in eADM is belangrijk voor het verbeteren van de positie van organisaties op het gebied van sikkerhetstrusler ten opzichte van traditionele sikkerhetsmodellforutsetninger.

1.2 Dataminimalisatie

Dataminimering behandelt het hergebruiken van gemengde persoonsgegevens en gevoelige gegevens die worden verzameld, verwerkt en opgeslagen, tot de sterkste en meest nuttige voor het gebruik van legitieme functies. Dette prinsippet er en nøkkelkomponent i personvernforordningen (GDPR) og andre databeskyttelseslover, og det bidrar til å redusere risikoen for databrudd og personvernsbrudd.

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

2. 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. Standaard benytter eADM 365 dager som oppbevaring av deaktiverte brukere, dette kan justeres for den enkelte kunde.

3. Geaggregeerde gegevens in stedet voor individuele gegevens: Når det er mulig, bør data anonymiseres eller aggregeres, slik at behandlingen ikke er basert på individuell identifikasjon.

4. Tilgangskontroll og minst privilegium: Implementering av streng tilgangskontroll sikrer at kun autorisert personell har tilgang til personopplysninger, og brukerne gis kun de rettighetene de har behov for.

5. Gegevensformulieren en transparantie: 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.

6. Pseudonimisering: Als identificeerbare gegevens worden opgeslagen, kan pseudonimisering (opslag van gegevens) worden gebruikt om de identiteit van de persoon te beschermen en het effect op potentiële datalekken te verminderen.

Bij het naleven van dit principe kan een eADM een voorstel doen voor dataminimalisatie in zijn organisatie, en kan hij bedreigde personele beslissingen nemen op dezelfde manier als de regelgevende instantie of de toezichthouder dat kan doen.

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 Identificeer en kartlegge enheter, programvare, brukere en 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

•  Klik op de knop voor de tilgangsnivå voor systeembrukere i AD, G suite og M365.

2.2 Beskytte og opprettholde.

• Etablere en sikker IKT-arkitektur og beskytt virksomhetens nettverk. Controleer de dataflyt.

•  Ha kontroll på identiteter og tilganger.

•  Alle passen liggen achter elkaar. Passord skal ikke gjenbrukes. Alle passagiers en reizigers zijn persoonlijk.

• Als je je naar een kundesysteem begeeft, kun je het passeren en de brukernavn slettes når jobben er utført.

•  De beste gegevens zijn beschikbaar.

• 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. Dit kan worden gedaan door Visma sine eksperter på sikkerhetsfeltet, zie voor meer informatie "Penetrasjonstesting".

• Trusselvurdering wordt uitgevoerd in samenwerking met het Nasjonalt cybersikkerhetssenter (NCSC). Identum is gedefinieerd als kritisk infrastruktur en het NCSC is verantwoordelijk voor het opsporen van sikkerhetshull en exploits in serversystemen, programma's en andere IT-systemen. Trusselvurderinger gjøres løpende av Identum basert på info fra NCSC. Relevante sikkerhetshulls worden in de toekomst aangepast aan de situatie waarin ze worden gebruikt.

• 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 heeft een speciale oplossing om dit te herstellen. 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 intern 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 kan een responsteam samenstellen dat ansvarlig is voor het verbeteren van de situatie, het onder controle houden en het herstellen van het systeem. 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 is 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/ ) voor Managed Detection and Response (MDR). Sentinel One zorgt voor een voortdurende controle van Identum-servers, klienters, endepunkter en ansatte datamaskiner. Alle hendelser blir logget, evaluert en 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. Als de hendelsen/angrepet worden geëvalueerd om kritisch of rettet te zijn voor een specifieke kunde, kunnen de kunden de hendelsen in het team gebruiken. De normale varslingstjeneste voor onze klanten is via epost, in de andere kant van de zaak kunnen ze ook opbellen.

Bakdør og tilgang hvis ordinær pålogging er nede

Identum har sine egne "break glass"-kontoer i vårt driftsmiljø. Als de gewone logging voor våre ansatte er av en eller annen grunn er ute av drift is, kunnen deze 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.

Penetrasjonstest

Å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 risikomenter oppdaget. Om ønskelig kan vi ha en gjennomgang av resultse av denne test. 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 en 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. De garantie is 99,9% (zie SLA).

Identum is ansvarlig voor besturingssystemen en 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 heeft een 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. Alle verkeer naar poort 80 wordt automatisch omgeleid naar 433 slik at kommunikasjonen skjer på kryptert linje via TLS. Alle webtjenester / sider interne og eksterne er sikret med SSL sertifikater fra Digicert.

Patchen en oppdatering

Patching av systemer, komponenter, servere, databaser osv gjøres hver søndag. Identum heeft een speciaal ressort voor dit doel. Identum is gedefinieerd als 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 sikkerhetshulls worden in de toekomst aangepast aan de situatie waarin ze worden gebruikt.

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.

De communicatie tussen Identum en server, klienter, nettlesere en tredjepartssystemer verloopt via TLS 1.2 met 2048 bit kryptering, en de sertifikatene zijn gebaseerd op 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-, back-up- en driftsystemen zijn ook versleuteld. Ook videogegevens zijn versleuteld. In eADM en eFeide zijn alle systeemcodes (geheimen) beveiligd met Rijndael AES 256-bits versleuteling. De paswoorden voor brukere worden opgeslagen in de LDAP-database die gebruikmaakt van de standaard Active Directory-technologie en worden opgeslagen in de hashet en kryptert. Bij overføring av passord (secrets) så benyttes alltid ende til ende kryptering via TLS.

Scheiding

De gegevens worden logischerwijs gescheiden door een unieke kunde-ID die in de kundetabellen wordt opgeslagen. Alle andere datatabellen zijn beschikbaar in de kundetabellen door middel van fremmednøkler. Elke forespørsel til eksterne eller interne API-er for henting eller lagring av data inkluderer en obligatorisk kundenøkkel som parameter, som spesifiserer hvilken kunde det gjelder. Dit zorgt ervoor dat de gegevens van de kunde worden aangepast en opgeslagen, en versterkt de samensmelting van gegevens tussen verschillende gebruikers.

Administrators kunnen tilgang tilgang til mer enn en instans av eADM av Identum, og administrator kan ikke tildele andre samme tilgang. Det anbefales at slik tilgang alltid gis med utløpsdato

Back-up en gjenoppretting

Databaser blir sikkerhetskopiert hver 10 minutter, produksjonsmiljøet som helhet blir sikkerhetskopiert daglig. Back-up blir ikke lagret i produksjonsmiljøet, men på et fysisk separat miljø.

Om de både kvalitet og innhold på sikkerhetskopier og teste gjenoppretting av data te verifiëren, blir Identum sitt testmiljø alltid opprettet fra sikkerhetskopier. Testmiljøet er en fullstendig kopi av produksjonsmiljøet. Dit moet minimaal 14 dagen duren.

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ø (v.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.

Voorbyggende tiltak

Identum heeft, net als andere Visma-selskapers, verschillende methoden voor risicobeoordeling, risicobeperking en risicomanagement. Risikoer blir identifisert og vurdert iht alvorlighetsgrad og sannsynlighet (risicobeoordeling). Voor elk risico wordt een forebyggende plan (risicobeperking) en een håndteringsplan (risicomanagement) opgesteld, als de risico's faktisk inntreffer zijn. 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

Als eADM is aangemeld, kunnen alle kontoer i organisasjonen functioneren als før, met alle rettigheter en 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. Het kan heel moeilijk zijn om deze functie in dit enkelvoudige systeem te gebruiken.

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.

Als eFeide nedetid is, zijn passordhåndteringsfunksjonalitet, eTID internettilgangsstyring en MFA-administrasjon av FEIDE-kontoer være utilgjengelig.

Nedetid på kildesystemer

Als het kildesysteem er niet is, kunnen eADM en eFeide natuurlijk niet worden gebruikt voor nieuwe kildedata. De gegevens van eADM en eFeide naar målsystemer kunnen worden gefortsette. Voorbeelden hiervan zijn passordendringer, endringer i gruppe/teamsmedlemskap, roller en rettigheter.

Als het kildesysteem igjen er tilgjengelig is, kunnen eADM en eFeide alle kildedata in een keer verwerken, slik alle ventende brukere osv. får de nødvendige kontoer og tilganger.

Nedetid på målsystemer

Als een målsystem er is in een kortere of langere periode, zijn er endringer lagt i en eksportkø. Als het målsystemet er tilgjengelig igjen is, worden de køen prosessert. Voorbeelden van endringers die in een sport worden gebruikt zijn attributtendringer (bijv. navn på en bruker), passord, gruppe/teams-medlemskap, roller en 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 automatisch feilmeldinger toevoegen aan enkeltbrukere, bijvoorbeeld als een oppdatering feiler i et målsystem (gitt at målsystemet støtter dette!).

• Manuell varsling -> Identum heeft een egen varslingsliste met epost en SMS voor alle administratorer i eADM of/eller eFeide. Deze lijst kan worden gebruikt om te zien of deelnemers die negatief zijn, een andere of meer andere gebruikers hebben. Identum har lav terskel for å sende ut varsel.

• Kunntender 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 die door de kunde worden opgevraagd, kunnen direct naar Identum worden gemeld via skjema tilgjengelig for administratorer i eFeide og eADM. Dette gjelder alle type 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 forslagen worden fortløpende.

5. Informasjonssikkerhet

GDPR en personvern

De oplossing voor het importeren van kildata naar andere systemen geeft aan dat je brukere en brukerdata kunt importeren om de video te behandelen. Als een gebruiker een account heeft in de AD, kan hij deze gegevens filteren om ze te importeren in zijn systeem. 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. Als en bruker opprettes i HRM, blir brukeren opprettet i eADM. Als en bruker deaktiveres eller slettes fra systemet vil tilhørende data også bli slettet, iht regler satt i eADM. Det can 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 riskikere at gamle brukerkontoer og persondata liggende igjen i lang tid. Er zijn regels in eADM die ervoor zorgen dat gegevens die ikke skal lagres blir slettet f.eks når brukeren blir deaktivert, går ut i permisjon, dør eller slutter. eADM automatiseert dit en zorgt ervoor dat alle brukerkontoer enten fjernes automatisk eller at nødvendige mottakere varsles der noe må gjøres manuelt. Via meldingsmaler kan man IT, drift, admin, når utstyr skal leveres inn, tilganger skal endres eller fjernes.

Alle brukere hebben een logging voor brukergrensesnittet, en iedereen kan alle gegevens zien die zijn geregistreerd voor egen bruker tot enhver tid. I forbindelse med GDPR og personvern can 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.

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. Als de standaard databehandleravtale ikke dekker kundens behov is, tilpasser vi oss og benytter den kunden ønsker.

ISO27001 en Visma Cloud leveringsmodel

Identum AS is 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) is de drijvende kracht achter het utvikle, levere en drifte skytjenester. Den beskriver aspekter ved at vi bør være organiser, hvordan vi bør jobbe (prosesser) samt tekniske krav og best praksis som er nødvendig for vellykket levering av skytjenester. Meer informatie over VCDM vindt u op: https://www.visma.com/trust-centre/vismaclouddelivery

Het model is gebaseerd op een reeks kjerneprinsipper en fokuserer på DevOps og Continuous Delivery. VCDM beschikt over een uitgebreide reeks herzieningen en certificeringen:

• 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 besturingssysteem voor informasjonssikkerhet (ISMS) is gecertificeerd in het kader van ISO 27001 en wordt herzien door een ervaren 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 kontrol 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 også av pilotkunder som tester endringene i normal drift en periode før de slippes til alle kunder.

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

Visma Cloud leveringsmodel. 

Endringer en oppdateringer

Endringer og oppdateringer medfører som hovedregel ikke nedetid. Als dat het geval is, wordt de servicevinduer gedefinieerd en wordt deze aangepast. SLA.

Vi har en felles, automatisk, prosess for oppgradering for all 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. In combinatie met automaten zorgt dit voor meer stabiliteit, meer flexibiliteit en een beter gebruik van de nieuwe functies.

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. De omzetting hiervan kan variëren, afhankelijk van de vraag welke endring er is. De strategie die je kunt volgen om eventuele problemen op te lossen, is "rulle fremover" (rol vooruit). Dit betekent dat je de feilen moet terughalen en ze moet opperen met een versjon, zodat je ze gemakkelijker kunt omrollen. Kun unntaksvis og ved alvorlige feil, vil det være aktuelt å rulle tilbake.

6. Sikkerhet og tilgangsstyring

Identum stuurt zijn programma's naar je toe via webapplikasjoner: http: //mega.efeide.no og http://mega.eADM.no. Alle toegang tot webapplikasjonene is beskyttet av captcha, brukernavn og passord samt 2FA autentisering. Klanten kunnen deze portalene zelf gebruiken voor beheer en zelfverbetering, maar ook voor andere gebruikers en rettigheter (zie de instructies voor het gebruik van de portalene).

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. Inloggen kan via een MFA-brukernavn/passord, IDporten of SSO in Azure AD. Als je SSO gebruikt, krijg je de mogelijkheid om je aan te melden bij Avdelingsleder en 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 eindringen die via webgrensesnittet worden uitgevoerd, worden automatisch gelogd. Kandidaten kunnen de statusrapporten van hun systemen bekijken. Vi understreker at vi anbefaler at tilgang til eFeide og eADM beskyttes med tofaktorautentisering for all 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 biedt alle klanten de mogelijkheid om dit beleid toe te passen wanneer de klant een regler instelt voor automatische of manuele tilgangsstyring naar fagsystemer, tredjeparter osv via eADM.

Intern personeel

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 en andere 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å. Voor de servicedesk en het beheer is het belangrijk dat kundene de SSO met MFA kunnen gebruiken, als alternatief benytte IDporten.

Systeemtilganger kan automatisch worden uitgevoerd op basis van regels of handmatig worden uitgevoerd voor enkelvoudige druk. Vi anbefaler at administratortilganger kun gis manuelt og behovsprøvd. Tilganger can 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 worden beheerd voor groepen, rollen en personen. Bij wijze van voorbeeld 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 kun 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 alle tilgjengelig informasjon om seg selv og bytte passord zien. En avdelingsleder ser kun sine ansatte. Als en bruker er avdelingsleder is en er tegelijkertijd ansatt is 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. Hieronder vindt u een tabel waarin u kunt zien welke operasjoner rollene heeft:

Historiek, logboek en overgangsreacties in eADM

eADM heeft een volledige loggføring voor alle eindgebruikers die worden geregistreerd voor objektnivå, ook voor brukere, grupper en 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å all 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 eindringen in één systeemoppsettet loggen samen. Dit betekent dat alle deelnemers aan regelsett, synkroniseringsmaler, meldingsflyter, tilgangsstyringer en arbeidsflyter.

Alle loggers 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 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-adres utenfor et gitt geografisk område.

Logging van eindringer 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. De gebruiker kan zien of een bruker een tilgang heeft in het lek-/markeersysteem en welk type tilgang dit oplevert. eFeide logt alle rettighetsendringer i tillegg til endringer i brukerdata og passord. Als en tilgang er is gjort av et regelsett, kan man videre spore hvem som gjorde endringen i regelsettet som utløste tilgangen.

Sikkerhets- en wachtwoordloggers

Sikkerhetslogging in eADM logt alle påloggingsforsøk, både autoriserte og uautoriserte med hvem, tid, sted (IP), type autentisering og status. I tillegg logt alle feilmeldinger, met metode (bijv. type API-kall), tijd, bruker en 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. Voor 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 forgodtbefinnendede.

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

Verandering van pas

In eADM en eFeide zijn alle systeemcodes (geheimen) beveiligd met Rijndael AES 256-bits versleuteling. De wachtwoorden voor het versleutelen worden opgeslagen in een LDAP-database die gebruikmaakt van de standaard Active Directory-technologie en worden opgeslagen met een wachtwoord en versleuteling. Bij overføring av passord (secrets) 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. Als niemand dit kan zien, kan dit eindigen.

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. 

Het wachtwoord kan worden toegewezen aan verschillende løsningers en kan worden toegewezen aan andere systemen. Het kan worden ingesteld om de brukere førstegangspassord te laten eindigen in forbindelse med pålogging til Azure, AD en Google før de får tilgang til å logge på. Identum biedt de mogelijkheid om het wachtwoord via sms of via autentisering gjennom IDporten op te slaan, en 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 can endre passord for all 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.

In eFeide kunt u een eindpas aanvragen voor uw leerlingen, een schooladministrateur kan een eindpas aanvragen voor uw leerlingen en een eindpas aanvragen voor uw school en een kommunabeheerder kan een eindpas aanvragen voor alle leerlingen. Feide støtter ikke tvunget passordbytte.

Sikkerhet og feidetjenester

I eFeide kan administratorer administrere pålogging med MFA til gitte Feidetjenester for ansatte. Krav om MFA for Feidetjenester can settes både individuelt og for hele skoler. Een tofaktor-metode is 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).

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 van persondata naar 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.

Druk op fødselsnummer in 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: Gebruikersattributen verbergen in Active Directory

Druk op fødselsnummer in 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.