Kunskapsbas

Generellt

Säkerhetsdokumentation

1. Utveckling och "Privacy by design"

Identum utvecklar sina lösningar med Privacy by design som grundfilosofi. De 7 principerna är:

Proaktiv inte Reaktiv; Förebyggande inte Åtgärdande
Integritet som standardinställning
Integritet inbyggd i design
Full Funktionalitet — Positiv-Sum, inte Noll-Sum.
Säkerhet från början till slut — Full Livscykelskydd
Synlighet och Transparens — Håll det Öppet
Respekt för användarens integritet — Håll det Användarcentrerat

För slutkunden innebär detta att våra lösningar i grunden är säkra; integritet är inbyggd i lösningen, det behöver inte konfigureras.

1.1 Zero trust

Zero trust-principen i kontexten av Identity and Access Management (IAM) är en säkerhetsmodell och strategi som bygger på konceptet att ingen användare eller enhet, vare sig inom eller utanför organisationens nätverk, någonsin ska ges de facto tillit. Istället för att anta att allt bakom brandväggen är säkert kräver zero trust att all åtkomst verifieras och auktoriseras kontinuerligt.

Här är några viktiga aspekter av zero trust-principen i samband med eADM:

Identitetsverifiering: Varje begäran om åtkomst till systemet kräver strikt verifiering av användarens eller enhetens identitet. Detta implementeras ofta med starka autentiseringsmetoder, såsom multifaktorautentisering (MFA).
Minimering av åtkomst: Användarna får endast åtkomst till de resurser de behöver för att utföra sina uppgifter (principen om minst privilegium). Behörigheter är ofta granulära och dynamiska, anpassade baserat på användarens behov och beteende. Detta gäller både användares åtkomst till eADM och de rättigheter som systemet är konfigurerat för att ge andra användare. Typiskt sett är behovsbaserad åtkomsthantering bättre för känsliga system än t.ex. rollbaserad kontrollerad åtkomst (RBAC).
Kontinuerlig övervakning: All aktivitet övervakas och analyseras för att upptäcka misstänkt eller ovanligt beteende. Detta kan inkludera ovanliga åtkomstmönster eller försök att komma åt känslig data.
Dataskydd: Även om identitets- och åtkomsthantering är kritisk fokuserar zero trust också starkt på dataskydd. Detta inkluderar kryptering av data både i transitering och i vila, samt säker datalagring med åtkomst baserad på behov.

Implementeringen av zero trust i eADM är central för att skydda organisationer från säkerhetshot genom att utmana traditionella säkerhetsmodellförutsättningar.

1.2 Dataminimering

Dataminimering handlar om att minska mängden personuppgifter och känsliga data som samlas in, behandlas och lagras, till det strikt nödvändiga för att utföra legitima funktioner. Detta princip är en nyckelkomponent i allmänna dataskyddsförordningen (GDPR) och andra dataskyddslagar, och det bidrar till att minska risken för dataintrång och integritetsbrott.

Begränsad insamling: Endast den data som är nödvändig för specifika funktioner eller tjänster bör samlas in. eADm importerar t.ex. inte löneutgifter som standard, endast om det är nödvändigt för den enskilde kunden.
Kortare lagringstider: Data bör bara lagras så länge det finns en operationell eller juridisk åtagande. eADm har data policyer som automatiskt raderar eller anonymiserar data efter behov. Som standard använder eADM 365 dagar som lagring för inaktiverade användare, detta kan justeras för den individuella kunden.
Aggregerad data istället för individuella data: När det är möjligt bör data anonymiseras eller aggregeras, så att behandlingen inte baseras på individuell identifiering.
Åtkomstkontroll och minst privilegium: Implementering av strikt åtkomstkontroll säkerställer att endast auktoriserad personal har tillgång till personuppgifter, och användarna ges endast de rättigheter de behöver.
Dataändamål och transparens: Klara riktlinjer om varför och hur data används, som är begränsade till de minst intrångiga sätten för att uppnå dessa ändamål, bidrar till dataminimering.
Pseudonymisering: Om identifierbara data måste användas kan pseudonymisering (användning av dataaliaser) hjälpa till att skydda individers identitet och minska effekterna vid potentiella dataläckage.

Genom att tillämpa dessa principer kan ett eADM stödja dataminimeringen i din organisation och därmed bättre skydda personuppgifter samtidigt som det uppfyller regulatoriska krav och främjar användarskydd.

2. Drift och "Grundprinciperna för IKT-säkerhet"

På driftsidan har vi baserat vår säkerhetstänkande på den Nationella Säkerhetsmyndighetens grundprinciper för IKT-säkerhet.

2.1 Identifiera och kartlägga enheter, programvara, användare och behov av åtkomst

Översikt och kontroll på hur länge vi lagrar användardata, och rutiner för radering.
Åtkomster ska alltid tilldelas på minimumnivå, ingen ska ha högre åtkomst än vad som krävs för att få jobbet gjort.
Se avsnitten om åtkomst för åtkomstnivå för systemanvändare i AD, G Suite och M365.

2.2 Skydda och upprätthålla

Etablera en säker IKT-arkitektur och skydda företagets nätverk. Kontrollera dataflödet.
Ha kontroll över identiteter och åtkomster.
Alla lösenord ska lagras i ett lösenordfack. Lösenord ska inte återanvändas. Alla lösenord och åtkomster är personliga.
Om man får åtkomst till ett kundesystem ska lösenord och användarnamn raderas när jobbet är utfört.
Skydda data i vila och under överföring.
Bevara kritisk information om inaktiverade användare i eFeide och eADM för att säkerställa blockering av återanvändning av användarnamn och andra unika identifierare. Efter en bestämd period raderas loggar, personinformation och åtkomst/rättighetshistorik för en användare automatiskt.

2.3 Upptäck och ta bort kända sårbarheter och hot

I linje med det första av grundprinciperna om "privacy by design" strävar vi aktivt efter att hitta sårbarheter i våra system. Vi genomför därför årliga penetrationstester av våra lösningar. Dessa utförs av Vismas experter inom säkerhetsfältet, se mer information under "Penetrationstesting".
Hotbedömning görs i samarbete med Nationellt cybersäkerhetscenter (NCSC). Identum är definierad som kritisk infrastruktur och får varning från NCSC när säkerhetshål och exploits upptäcks i serversystem, programvara och andra IT-system. Hotbedömningar görs löpande av Identum baserat på information från NCSC. Relevanta säkerhetshål patchas fortlöpande när vi blir medvetna om dem.
Alla Identums servrar, både i produktions- och testmiljö, uppdateras veckovis. Detta gäller både operativsystem, installerade appar och annan programvara. Dessutom uppdateras också eFeide och eADM på söndagar, enligt 14-dagars utvecklingssprintar. Identum har en särskild resurs som ansvarar för detta. Efter patchning/uppdatering testas alla system för att säkerställa full funktionalitet. Söndag är valt på grund av låg belastning och användning på söndag. eFeide uppdateras inte i samband med skolstart och examinationsavveckling, med undantag för driftkritiska uppdateringar.

2.4 Hantera och återställa

Alla oönskade händelser rörande säkerhet eller integritet registreras i ett eget register, med tid, plats, vem, åtgärder och uppföljning i efterhand. Procedurerna är dokumenterade i Identums interna beredskapsplan.
Kunder varnas rutinmässigt om både interna och externa oönskade händelser. Procedurerna är dokumenterade i Identums interna beredskapsplan.
Där det är relevant delas hotbedömningar från NCSC med kunderna.
Identum har avtal om hjälp från Visma sin egen cybersäkerhetsgrupp om företaget utsätts för angrepp, blir hackat eller om datasäkerheten på annat sätt är hotad. Visma etablerar då ett responsteam som är ansvarigt för att hantera situationen, få den under kontroll och återställa eventuellt drabbade system. Dessutom har vi "hot backup" av våra system, vilket gör att man inom några minuter kan etablera en alternativ servermiljö om den vanliga går ner på grund av DDOS eller andra typer av angrepp.

3. Systemövervakning och hotbearbetning

Identum AS är sedan 01.02.2023 ett helägt dotterbolag till Visma AS och underlagt Vismas rutiner för cybersäkerhet, övervakning och hotbearbetning. Visma använder Sentinel One (https://www.sentinelone.com/) för Managed Detection and Response (MDR). Sentinel One kör kontinuerlig övervakning av Identums servrar, klienter, slutpunkter och anställdas datorer. Alla händelser loggas, utvärderas och hot följs automatiskt aktivt av Vismas Security Operations Centre (SOC)-team.

Vid en tillräckligt allvarlig säkerhetshändelse eller angrepp informeras Identum av Visma. De har respons 24/7/365 och vidtar åtgärder även innan Identum informeras. Om händelsen/angreppet bedöms som kritiskt eller riktad mot en specifik kund informeras kunden omedelbart och tas in i teamet som hanterar händelsen. Normal varningstjänst för våra kunder är via epost, i sådana fall blir ni också uppringda.

Bakdörr och åtkomst om ordinarie inloggning är nere

Identum har sina egna "break glass"-konton i vår driftmiljö. Om ordinarie inloggning för våra anställda av någon anledning är ur drift kan sådana konton användas för att ge eller återställa åtkomst till systemet. Denna bakdörr används inte i ordinarie drift, och all inloggning övervakas med omedelbar varning.

I de fall där kundens inloggning till eADM inte fungerar (t.ex. om kundens AAD är nere och SSO därför ur drift) kan Identum ändra till en annan inloggning under perioden kunden har nedtid, t.ex. från Azure AD SSO till inloggning med IDporten.

Penetrationstesting

Årligen utförs en säkerhetsgranskning och penetrationstest av våra lösningar av Vismas cybersäkerhetsteam. Granskningen visar eventuella svagheter eller förbättringspunkter som vi då förbättrar fortlöpande. Vid senaste genomförda test upptäcktes inga allvarliga riskomoment. Om så önskas kan vi ha en genomgång av resultaten från detta test. Av säkerhetsskäl önskar vi inte dela själva rapporten.

Våra kunder står självklart fria att utföra sin egen penetrationstesting, med ellerutan hjälp från tredjepartsleverantörer valda av kunden.

4. Drift och hosting

Identum sina lösningar är molnbaserade och drivs och underhålls av vår driftspartner Microsoft Norge, med redundans, extern backup och lastbalansering. Fysiskt står servrarna i Östlandet i Norge. Drifttidsgaranti är 99,9 % (se vår SLA).

Identum är ansvarig för operativsystem och programvara medan Microsoft ansvarar för drift av maskinvara, kommunikation, offsite backup, redundans och brandvägg. Endast anställda med tekniskt ansvar på Identum eller nödvändigt driftspersonal hos Microsoft har access till servermiljön. Detta sker via Teamviewer-klienter med MFA. Identum har ett utökat SLA-avtal med Microsoft med svarstid inom 10 minuter inom kontorstid och 1 timme annars.

De enda brandväggsportarna som är öppna för inkommande trafik är port 80/433 för användning av Teamviewer, webbklienter och API-klienter. All trafik till port 80 omdirigeras automatiskt till port 433 så att kommunikationen sker på en krypterad linje via TLS. Alla webbtjänster/sidor interna och externa är säkrade med SSL-certifikat från Digicert.

Patching och uppdatering

Patching av system, komponenter, servrar, databaser osv. görs varje söndag. Identum har en dedikerad resurs för detta. Identum är definierad som kritisk infrastruktur och tar emot varning från Nationella cybersäkerhetscentret (NCSC) när säkerhetshål och exploits upptäcks i serversystem, programvara och andra IT-system. Hotbedömningar görs löpande av Identum baserat på information från NCSC. Relevanta säkerhetshål patchas fortlöpande efter att vi blir medvetna om dem.

Uppdatering av system, komponenter, servrar, databaser osv. görs också varje söndag. Identum använder som standard inte beta-funktionalitet eller beta-versioner.

Kryptering

Identums servrar är hostade i Azure-molnet och använder standard server-side-kryptering av all data vid lagring. Krypteringsnycklarna hanteras av Azure-plattformen automatiskt.

Kommunikation mellan Identums servrar, klienter, webbläsare och tredjepartssystem är krypterad från början till slut via TLS 1.2 med 2048 bit-kryptering, och certifikaten utfärdas av Digicert. Dessa installeras och underhålls av de medlemmar i vårt driftteam som har nödvändig tillgång till servrar och Digicert-tjänsten. De byts ut/har giltighet efter branschstandard (12 månader).

Databas, backup och driftssystem är också krypterade. Vidare är alla användardata krypterade. I eADM och eFeide är alla systemlösenord (secrets) skyddade med Rijndael AES 256-bit-kryptering. Lösenord till användarna är lagrade i vår LDAP-databas som använder standardteknik från Active Directory och lagras därmed hasade och krypterade. Vid överföring av lösenord (secrets) används alltid kryptering från början till slut via TLS.

Separering

Data separeras logiskt med hjälp av ett unikt kund-ID lagrat i kundtabellen. Alla andra datatabeller är kopplade till kundtabellen via främmande nycklar. Varje begäran till externa eller interna API:er för hämtning eller lagring av data innehåller en obligatorisk kundenyckel som parameter, som specificerar vilken kund det gäller. Detta säkerställer att varje kunds data förblir separerade och säkra och förhindrar datamixning mellan olika klienter.

Administratörer kan endast ges åtkomst till mer än en instans av eADM av Identum, och administratören kan inte tilldela andra samma åtkomst. Det rekommenderas att sådan åtkomst alltid ges med utgångsdatum.

Backup och återställning

Databaser säkerhetskopieras var 10:e minut, produktionsmiljön som helhet säkerhetskopieras dagligen. Backup lagras inte i produktionsmiljön utan i en fysiskt separat miljö.

För att verifiera både kvalitet och innehåll på säkerhetskopior och testa återställning av data skapas Identums testmiljö alltid från säkerhetskopior. Testmiljön är en fullständig kopia av produktionsmiljön. Detta görs minst var 14:e dag.

Kontinuitetsplan

Vid behov kan hela drift/servermiljön återställas från noll på under sex timmar, antingen i samma miljö eller i en sekundär miljö (t.ex. om primärmiljön utsätts för ett DDOS-angrepp). Det är också möjligt att återställa enskilda kunder från backup. Detta kan göras både vid fel i samband med uppgradering eller tekniska förändringar av lösningen, eller om kunden behöver återställas efter en import av korrupta data från källsystemet. Detta kan beställas via Identum sin support och sådana förfrågningar behandlas som ett fel på nivå A enligt kundens vid varje tidpunkt gällande Service Level Agreement. Om Identum på eget initiativ bestämmer sig för att antingen hela servermiljön eller en specifik kund måste återställas, blir kunden informerad, antingen via varningstjänsten i eADM eller per telefon.

Förebyggande åtgärder

Identum har, liksom andra Visma-företag, egna procedurer för Risk assessment, Risk mitigation och Risk management. Risker identifieras och bedöms enligt allvarlighetsgrad och sannolikhet (risk assessment). För varje risk ska det finnas en förebyggande plan (risk mitigation) och en hanteringsplan (risk management) om risken verkligen inträffar. Detta material ingår i Identums interna säkerhetsdokumentation. Detta är naturligtvis inte offentlig information.

Se också avsnitt 3 "Systemövervakning och hotbearbetning" och avsnitt 5. "ISO27001 och Visma Cloud Delivery Model"

Konsekvenser av nedtid på eADM

Om eADM har nedtid kommer alla konton i organisationen att fungera som tidigare, med alla rättigheter och åtkomster. Så länge eADM är nere kommer konton inte att skapas/uppdateras/inaktiveras/raderas och inga åtkomster/licenser kommer att ges/ändras/avlägsnas av eADM. Det kommer fortfarande att vara möjligt att göra detta manuellt i respektive målsystem.

Konsekvenser av nedtid på eFeide

Om eFeide, som Användaradministrationssystem (BAS) för FEIDE-katalogen, upplever nedtid, kommer FEIDE-inloggning att fortsätta fungera som tidigare. Det är endast om SIKT (Kunskapssektorns tjänstleverantör, https://sikt.no/) har nedtid som FEIDE-inloggning blir otillgänglig.

Om eFeide har nedtid kommer lösenordshanteringsfunktionalitet, eTID internetåtkomststyrning och MFA-administration av FEIDE-konton att vara otillgängliga.

Nedtid på källsystem

Om ett källsystem är nere uppdateras eADM och eFeide inte med nya källdata. Dataflödet från eADM och eFeide till målsystemen kommer att fortsätta som tidigare. Ett exempel på detta är lösenordsändringar, ändringar i grupp/lagmedlemskap, roller och rättigheter.

När källsystemet åter blir tillgängligt kommer eADM och eFeide att bearbeta alla källdata på nytt så att alla väntande användare osv. får de nödvändiga konton och åtkomster.

Nedtid på målsystem

Om ett målsystem är nere under en kortare eller längre period, placeras ändringar i en exportkö. När målsystemet åter blir tillgängligt bearbetas köen. Exempel på ändringar som placeras i exportkö är attributändringar (t.ex. namn på en användare), lösenord, grupp/lagmedlemskap, roller och åtkomster. Det loggas i eADM när ändringar placeras i exportkö och skickas till de olika målsystemen.

Varning

Identum har flera typer av varningar för fel, nedtid eller andra händelser som har negativ påverkan för tjänsten:

Automatisk systembaserad varning -> Systemet skickar ut en statusrapport efter varje slutförd synkronisering med övergripande information. Dessutom kommer systemet att varna om synkroniseringen stoppas, till exempel som ett resultat av korrupta data eller om ett målsystem inte svarar. Det är också möjligt att ställa in sina egna varningskriterier, antingen via e-post eller SMS, till exempel om en administratörsåtkomst ges till en användare.
eADM kan ställas in för att varna automatiskt vid felmeddelanden på enskilda användare, t.ex. om en uppdatering misslyckas i ett målsystem (förutsatt att målsystemet stödjer detta!).
Manuell varning -> Identum har en egen varningslista med e-post och SMS för alla administratörer i eADM och/eller eFeide. Denna lista används för att varna om incidenter som negativt påverkar en eller flera kunder. Identum har låg tröskel för att skicka ut varningar.
Kunder som har sina egna övervakningssystem kan koppla sig till loggarna i eADM via API och automatiskt hämta löpande loggar med varning, uppdateringar och fel.

Felrapportering

Alla fel som upptäcks av kunden kan rapporteras direkt till Identum via formulär tillgängligt för administratörer i eFeide och eADM. Detta gäller alla typer av fel, både fel med systemet och varningar om integritetsrelaterade incidenter och åtgärder. Alla integritetsrelaterade händelser hanteras som ett A-fel enligt överenskommet tjänstenivåavtal (SLA). Alla händelser hanteras enligt grundprinciperna för IKT-säkerhet, punkterna 4.-4.4.

eADM och eFeide har också inbyggd funktionalitet för att skicka in förbättringsförslag. Alla förslag utvärderas löpande.

5. Informationssäkerhet

GDPR och integritet

Som grundprincip för import av källdata till våra system gäller att vi endast importerar användare och användardata som ska behandlas vidare. Om en anställd inte ska ha konto i AD, kommer vi att filtrera bort denna från att bli importerad in överhuvudtaget. Föräldraalternativ används inte vid import till Feide-kataloger. Endast relevanta användardata importeras, exempelvis importerar vi tjänstgöringsgrad (som kanvara relevant när det gäller tilldelning av licenser) till skillnad från löneuppgifter som vi inte importerar.

Det är viktigt att understryka att det är källdatasystemen (HRM och SAS) som är överordnande. När en användare skapas i HRM, skapas användaren i eADM. När en användare inaktiveras eller raderas från systemet kommer tillhörande data också att raderas enligt regler som satts i eADM. Det kan till exempel automatiseras att användare först inaktiveras och sedan raderas från systemet efter en given tidsperiod. Säkerheten och integriteten i eADM är helt beroende av att kunden har bra rutiner för in- och utmönstring av användare från sina källsystem.

Ett vanligt klagomål från administratörer när det gäller användarkontots livscykel är att "alla märker när någon börjar, men ingen märker när någon slutar". Därmed kan man riskera att gamla användarkonton och persondata ligger kvar under lång tid. Lösningen på detta är bra regelverk i eADM som ser till att data som inte ska lagras raderas till exempel när användaren inaktiveras, går på ledighet, dör eller slutar. eADM automatiserar detta och ser till att alla användarkonton antingen tas bort automatiskt eller att nödvändiga mottagare varnas där något måste göras manuellt. Via meddelandemallar kan man varna IT, drift, admin när utrustning ska returneras, åtkomster ska ändras eller tas bort.

Alla användare har inloggning till användargränssnitt och alla kan när som helst se alla data som är registrerade för deras egen användare. I samband med GDPR och integritet kan slutanvändare se sina data i en integritetssektion där vi också anger varifrån data kommer, vem de ska vända sig till om något inte är rätt eller om de vill ha sina data raderade.

Identums lösningar uppfyller alla krav i Norm för informationssäkerhet.

Se bilaga 9 i avtalet för personuppgiftsbiträdesavtalet med Identum AS. Vi har som princip att vi anpassar oss till våra kunder istället för att de måste anpassa sig till oss. Om vårt standard personuppgiftsbiträdesavtal inte täcker kundens behov anpassar vi oss och använder det som kunden önskar.

ISO27001 och Visma Cloud Delivery Model

Identum AS är sedan 01.02.2023 ett helägt dotterbolag till Visma AS och underlagt deras kvalitetssystem och leveransmodell som beskrivs här:

Visma Cloud Delivery Model (VCDM) beskriver vår strategi för att utveckla, leverera och driva molntjänster. Den beskriver aspekter av hur vi bör vara organiserade, hur vi bör arbeta (processer) samt tekniska krav och bästa praxis som är nödvändiga för framgångsrik leverans av molntjänster. Ytterligare information om VCDM finns på: https://www.visma.com/trust-centre/vismaclouddelivery

Modellen baseras på en uppsättning kärnprinciper och fokuserar på DevOps och Continuous Delivery. VCDM har följande revisionsuttalande och certifikat:

ISAE 3402 SOC 1 Typ II
ISO 27001

Visma Security Program och Visma Architecture and Technology Programme är integrerade i Visma Cloud Delivery Model. Vårt styrsystem för informationssäkerhet (ISMS) är certifierat enligt ISO 27001 och revideras årligen av en oberoende IT-revisor.

Dessutom revideras Vismas förmåga att följa ISMS och kvalitetsstyrningssystemet i VCDM av ett oberoende revisionsföretag enligt ISAE 3402. Denna omfattande kontroll genomförs också årligen och sammanfattas i en ISAE 3402 Typ II-rapport.

Vår strategi för att implementera ändringar är fortlöpande integrering och implementering (Continuous Integration and Continuous Deployment - CI/CD).

Metodiken utvecklas ständigt med avseende på teknik, kompetens och procedurer. För närvarande innebär detta att ändringar verifieras och implementeras löpande i vår stagingmiljö. Där görs manuella tester både internt i utvecklingsavdelningen och av fagexperter. För mer omfattande ändringar använder vi oss också av pilotkunder som testar ändringarna i normala driftförhållanden under en period innan de släpps till alla kunder.

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

Visma Cloud Delivery Model

Ändringar och uppdateringar

Ändringar och uppdateringar medför som huvudregel inte nedtid. Om det sker, kommer det att genomföras i fördefinierade servicefönster och meddelas enligt SLA.

Vi har en gemensam, automatisk, process för uppgradering för alla miljöer. Frekventa och små uppdateringar ger låg risk för fel vid varje ändring. Vi använder i allt högre grad implementering av uppgraderingar direkt i produktionsmiljön, men dolt bakom funktionsbrytare ("feature toggles"), såd att funktionaliteten först aktiveras när den är redo för kunden. I interaktion med automatiska tester ger detta hög stabilitet, färre fel och snabb utrullning av nya funktioner.

Uppdateringar kommer att kommuniceras på olika sätt beroende på storlek och omfattning av ändringen:

Mindre ändringar som felkorrigeringar som inte påverkar kunden eller användaren kommer att meddelas genom uppdatering av release notes
Medelstora ändringar som exempelvis ändringar eller tillägg i arbetsprocesser eller skärmar kommer att tillkännages i release notes, meddelanden på startsidan, uppdaterad användardokumentation och på Visma Community.
Större ändringar som nyckelfunktionalitet eller en större ändring i en arbetsprocess kan även ha webbseminarier och/eller uppdaterad e-lärning.

För större ändringar som kräver träning och/eller konfiguration av systemet kommer vi att involvera kunden innan vi implementerar ändringen. Omfattningen av detta kommer att bero på vilken typ av ändring det är. Vår strategi för hantering av eventuella fel som skulle kunna uppstå vid uppdateringar är att "rulla framåt" (roll-forward). Detta innebär att vi vill rätta till felet och uppdatera med en ny version, snarare än att rulla tillbaka. Endast undantagsvis och vid allvarliga fel kommer det att vara lämpligt att rulla tillbaka.

6. Säkerhet och åtkomsthantering

Identum driver sin programvara i huvudsak via webbapplikationer: http://mega.efeide.no och http://mega.eADM.no. All åtkomst till webbapplikationerna skyddas med captcha, användarnamn och lösenord samt tvåfaktorsautentisering. Kunden kan själv använda dessa portaler för administration och självbetjäning, men då med andra åtkomster och rättigheter (se avsnittet om åtkomsthantering).

Vi rekommenderar alla våra kunder att använda autentisering med tvåfaktorsautentisering aktiverad och vi har som krav att alla åtkomster till alla våra system på administratörsnivå ska vara med tvåfaktorsautentisering. Vi erbjuder inloggning via användarnamn/lösenord med tvåfaktorsautentisering, ID-porten eller SSO med Azure AD. Om SSO används kräver vi att åtkomst skyddas på rättighetsnivå Avdelningsledare och uppåt.

Det är ett viktigt princip att inte ge högre åtkomst än vad som är nödvändigt. Vi rekommenderar därför att ni är restriktiva med att ge åtkomst på administratörsnivå. För det allra mesta av daglig drift är servicedeskbrukartillgång tillräckligt. För användare som bara ska lösa en specifik uppgift, till exempel hantera lösenord för en avdelning, är superanvändartillgång tillräckligt. Endast absolut nödvändig personal bör ha administratörsåtgång till systemet och detta bör övervägas tidsbegränsat. Detta princip begränsar insyn i persondata och möjligheterna att tilldela åtkomster eller rättigheter.

Alla förändringar som utförs via webbgränssnittet loggas automatiskt. Kunden informeras regelbundet vid oönskade händelser, utöver den dagliga statusrapporten från våra system. Vi understryker att vi rekommenderar att åtkomst till eFeide och eADM skyddas med tvåfaktorsautentisering för alla användare med administratörsåtgång, eftersom this functionality is a part of our solutions.

Vår policy för åtkomsthantering är att användare inte ska få en högre rättighetsnivå än de behöver i det dagliga, högre åtkomst bör övervägas enligt behov. Administratörsåtkomst ska endast tilldelas ett fåtal utvalda användare som har genomfört träning i användning av systemet. Ett exempel kan vara att första linjens användarsupport hos kunden har servicedesktillgång, medan endast tredje linjen har åtgång till systemet på administratörsnivå. Identum rekommenderar alla våra kunder att följa denna policy när de sätter upp regler för automatiserad eller manuell åtkomsthantering till facksystem, tredjeparter osv. via eADM.

Internt personal

Detta gäller också Identums egna anställda. Anställda får endast nödvändig åtkomst enligt tjänst och funktion. När anställda slutar tas alla åtkomster omedelbart bort. Identum använder sig inte av hjälp från externa tredjeparter och har en policy där endast anställda som aktivt arbetar med drift och användarsupport av lösningen har åtkomst till kundernas data.

De olika åtkomstnivåerna och rollerna i Identum är fast definierade och revideras regelbundet och behovsprövade i enlighet med ISO27001.

Alla ändringar som görs i systemet loggas på samma sätt som kundens egna användare. Så, om en anställd på Identum ger en åtkomst till ett facksystem hos en kund, loggas det i historiken för användaren som fick åtkomsten. Det är inte möjligt att kopiera användardata mellan de olika instanserna i användargränssnittet, endast mallar och regelverk.

Åtkomstkontroll

Både eFeide och eADM stödjer olika metoder för användarinloggning, inklusive tvåfaktorsautentisering. Vi erbjuder (självklart) FEIDE-inloggning, ID-porten, ADFS/LDAP, SSO med Azure/EntraID, SSO med Google Workspace och andra SAML2.0-autentiseringslösningar. Vi förväntar oss att kunder skyddar SSO-inloggning med tvåfaktorsautentisering, det rekommenderas inte att åtkomst till eADM och eFeide är utan tvåfaktorskydd, även på anställd/avdelningsledarnivå. På servicedesk och administratörsnivå har vi krav på att våra kunder ska skydda SSO med tvåfaktorsautentisering, alternativt använda ID-porten.

Systemåtkomster kan ges automatiskt baserat på regelverk eller manuellt för den individuella användaren. Vi rekommenderar att administratörsåtkomster endast ges manuellt och behovsprövs. Åtkomster kan ges med eller utan utgångsdatum och systemet har lösning för både aktiv och passiv åtkomstrevision vid givna tidsintervall.

De olika åtkomstnivåerna kan administreras på grupp, roll och person nivå. Till exempel kan inloggning till användargränssnitt för eFeide regleras så att alla som har åtkomst till att se personaldata om andra användare måste logga in med tvåfaktorsautentisering, medan studenter (som endast kan se sina egna data) kan logga in utan användning av tvåfaktor.

Systemet tar också hänsyn till att en och samma användare kan ha olika roller i de olika avdelningarna, med varierande behov och åtkomster. En anställd kan se all tillgänglig information om sig själv och byta lösenord. En avdelningsledare ser endast sina anställda. Om en användare är avdelningsledare och samtidigt är anställd på en annan nivå i organisationen, kommer denna användare endast att ha administratörsåtkomster till den avdelning där han/hon är avdelningsledare. På den andra avdelningen kommer han/hon endast att ha ordinär anställd-åtkomst.

De sex rollerna ger åtkomst till funktionella områden, underliggande information och funktionalitet. Nedan följer en tabell som visar vilka operationer rollerna har åtkomst till:

Historik, loggar och åtkomstrevision i eADM

eADM har fullständig loggning av alla ändringar som görs på objektsnivå, dvs. för användare, grupper och avdelningar. Loggarna är tillgängliga för alla med administratörsåtkomst i lösningen. Både ändringar som kommer in från källsystem och ändringar som görs i eADM loggas. Systemet loggar också all data som skickas till de olika källsystemen, så att man har full översikt över vilka data som exporterats var. Alla poster loggas med objekt-ID, datum/tid, anledning till förändring, vem som utförde förändringen om det är en manuell förändring, tidigare värde och nytt värde.

Alla ändringar i själva systeminställningen loggas också. Det betyder alla ändringar på regler, synkroniseringsmallar, meddelandeflöden, åtkomsthanteringar och arbetsflöden.

Alla loggar lagras, krypteras och skyddas digitalt och fysiskt i enlighet med samma standarder som Identums övriga data. Loggar kan inte ändras av någon användartyp, inklusive Identums egen superduperadministratörsroll. Loggar kan exporteras för behandling i tredjepartssystem.

Alla händelser, loggar osv. kan ställas in för att utlösa varningar via e-post eller SMS när de inträffar. Till exempel kan systemet varna för specifika felmeddelanden vid export till känsliga system eller när en användare loggar in med en IP-adress utanför ett givet geografiskt område.

Loggning av förändringar på användardata, rättigheter och åtkomster

I användargränssnittet för eADM kan man också se alla åtkomster och licenser som har beviljats en användare både i eADM och i anknutna målsystem. Historiken visar när en åtkomst eller licens beviljades, om det gavs automatiskt på basis av regelverk eller manuellt av en användare. Man kan se vad en användare har åtkomst till i exempelvis ett ärende-/arkivsystem och vilken typ av åtkomst det gäller. eFeide loggar alla rättighetsförändringar samt förändringar i användardata och lösenord. Om åtgärden är gjort av ett regelverk kan man vidare spåra vem som gjorde förändringen i regelverket som utlöste åtgärden.

Säkerhets- och lösenordsloggar

Säkerhetsloggning i eADM loggar alla inloggningsförsök, både auktoriserade och icke-auktoriserade med vem, tid, plats (IP), autentiseringstyp och status. Dessutom loggas alla felmeddelanden, med metod (t.ex. typ av API-anrop), tid, användare och IP.

Alla lösenordsbyten loggas, med tid och datumstämpel, hur lösenordsbytet gjordes, vem som initierade lösenordsändringen, om lösenordet exporterades vidare till andra målsystem och med eventuella felmeddelanden.

Tredjepartsåtkomst

Kunden styr själv vem som har åtkomst till kunddata i eADM via användargränssnittet. Identum använder sig inte av underleverantörer och ger inte åtkomst till kunddata till tredjeparter.

Dataflöde till tredjeparter styrs via synkroniseringsmallar där kunden själv bestämmer vilka data som ska exponeras för/överföras till varje enskild tredje part. För API-baserade integrationer kör eADM endast PUSH, det vill säga att eADM är den som initierar dataöverföring och styr vilka data som överförs. eADM tillåter inte att tredje parter kan hämta data från systemet efter eget godtycke.

Det är inte möjligt att få åtkomst till andra kunders data genom eADM. Även om t.ex. en administratörskonto hos kund A tas över av en extern part, kan denna åtkomst inte användas för att få insyn i kunddata hos kund B. Se även punkten "Penetrationstesting".

Hantering av lösenord

I eADM och eFeide är alla systemlösenord (secrets) skyddade med Rijndael AES 256-bit-kryptering. Lösenord till användare ligger i vår LDAP-databas som använder standard Active Directory-teknologi och lagras därmed hasade och krypterade. Vid överföring av lösenord (secrets) används alltid kryptering från början till slut via TLS. Detta gäller för all dataöverföring till och från lösningen.

Lösenord är inte tillgängliga för någon användare i eADM eller eFeide, det gäller anställda själva, avdelningsledare eller administratörer. Det enda undantaget är förstgångslösenord, naturligtvis eftersom de måste kunna läsas, skrivas ut och skickas till den anställde. Efter den första inloggningen kommer det lösenordet att ändras och lagras krypterat. Efter det kommer ingen kunna se det, det kan endast ändras.

Förstgångslösenord för användare skapas i eADM/eFeide när ett användarkonto skapas. Lösenordet genereras enligt regelverk som satts upp enligt kundens krav, t.ex. 16 tecken, stor bokstav, minst 1 specialtecken. När ett användarkonto skapas i målsystem som AD, Azure eller facksystem kan användarna skapas med samma förstgångslösenord. Detta överförs krypterat.

Lösenord kan ändras i våra lösningar och överförs i realtid till målsystemen. Det kan ställas krav på att användare måste ändra förstgångslösenord innan de får åtkomst till att logga in. Identum har lösning för att återställa lösenord via SMS eller via autentisering genom ID-porten, och vi rekommenderar starkt ID-porten.

I eADM kan avdelningsledare ändra lösenord för sina anställda, antingen genom att tilldela ett nytt lösenord eller skicka ett genererat lösenord till den anställde via SMS om det finns ett mobiltelefonnummer registrerat på användaren. Vi rekommenderar dock att proceduren bör vara att anställda gör detta själva via glömt-lösenord-portalen.

Servicedesk-användare och administratörer i eADM kan ändra lösenord för alla användare, antingen genom att tilldela ett nytt lösenord eller skicka ett genererat lösenord till den anställde via SMS om det finns ett mobiltelefonnummer registrerat på användaren. Vi rekommenderar dock att proceduren bör vara att anställda gör detta själva via glömt-lösenord-portalen.

I eFeide kan lärare ändra lösenord på elever, skoladministratörer kan ändra lösenord för elever och lärare vid sin skola, och kommunaadministratörer kan ändra lösenord för alla användare.

Säkerhet och Feidetjänster

I eFeide kan administratörer hantera inloggning med tvåfaktorautentisering till givna Feidetjänster för anställda. Krav på tvåfaktorautentisering för Feidetjänster kan sättas både individuellt och för hela skolor. En metod för tvåfaktor är vad en användare använder för att bevisa sin identitet när en Feidetjänst kräver tvåfaktorautentisering. Feide har fyra olika tillgängliga metoder för tvåfaktorautentisering; inloggning via ID-porten, kod via sms, kodblad och godkännarklient (MS Authenticator eller Google Authenticator).

Vilka Feidetjänster som ska skyddas med tvåfaktorautentisering är upp till den enskilda kunden, vår tumregel är att alla Feidetjänster där det lagras personinformation om elever och/eller anställda bör skyddas med tvåfaktorautentisering. Ett molnbaserat skoladministrativt system är ett exempel på ett system som enligt vår mening bör skyddas med tvåfaktorinloggning.

Export av persondata till målsystem

Både eADM och eFEIDE innehåller persondata, och man borde vara försiktig med vilka data som exporteras till vilka målsystem. En tumregel bör vara att man endast ska exportera det minimum av data som målsystemet har behov av. Utöver detta bör det göras en behovsprövning för data som personnummer, personlig kontaktinformation, löneinformation osv.

Användning av personnummer i Active Directory

Vi rekommenderar att om personnummer används som en unik identifierande attribut i AD (t.ex. i attributen employeeID eller employeeNumber), bör detta antingen krypteras (detta finns det funktionalitet för i båda systemen) eller döljas så att visning av denna attribut endast är tillgänglig för administratörer: Hur dölja visning av attribut på AD-användare?

Användning av personnummer i Azure AD / Entra ID

Vi rekommenderar inte användning av personnummer som en unik identifierande attribut i Azure AD, eftersom detta fält inte kan skyddas eller döljas. Använd istället anställningsnummer eller en annan unik nummerserie.