Dokumentation om säkerhet

Detta dokument ger en omfattande översikt över säkerhetsramverket för Identums produkter och tjänster, inklusive eADM och eFeide. Vår säkerhetsställning bygger på bästa praxis inom branschen, robusta operativa förfaranden och ett åtagande att skydda kunddata.

Utvecklings- och designfilosofi

Vår utvecklingsprocess styrs av en "säkerhet först"-filosofi, som omfattar grundläggande principer för modern cybersäkerhet.

"Inbyggt integritetsskydd"

Identum utvecklar sina lösningar med Privacy by design som grundläggande filosofi. De sju principerna är:

Proaktiv, inte reaktiv; förebyggande, inte avhjälpande
Sekretess som standardinställning
Integritetsskydd inbyggt i designen
Full funktionalitet – positiv summa, inte nollsumma
End-to-End-säkerhet – fullständigt skydd under hela livscykeln
Synlighet och transparens – håll det öppet
Respekt för användarnas integritet – fokusera på användaren

För slutkunden innebär detta att våra lösningar är säkra som standard; integritet är inbyggt i lösningen och behöver inte konfigureras.

Nollförtroende

Nollförtroendeprofilen inom identitets- och åtkomsthantering (IAM) är en säkerhetsmodell och strategi som bygger på principen att ingen användare eller enhet, vare sig den befinner sig inom eller utanför organisationens nätverk, någonsin ska beviljas förtroende. Istället för att utgå från att allt bakom brandväggen är säkert kräver nollförtroende att all åtkomst kontinuerligt verifieras och auktoriseras.

Här är några viktiga aspekter av principen om nollförtroende 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 hjälp av 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 minsta möjliga behörighet). Behörigheter är ofta detaljerade och dynamiska och anpassas efter användarens behov och beteende. Detta gäller både användarnas åtkomst till eADM och de behörigheter som systemet är inställt på att bevilja andra användare. Vanligtvis är behovsbaserad åtkomsthantering (ABAC eller JIT) bättre på känsliga system än t.ex. rollbaserad kontokontroll (RBAC).
Kontinuerlig övervakning: All aktivitet övervakas och analyseras för att upptäcka misstänkt eller ovanligt beteende. Detta kan omfatta ovanliga åtkomstmönster eller försök att få tillgång till känslig information.
Dataskydd: Även om identitets- och åtkomsthantering är avgörande, fokuserar zero trust också starkt på att skydda data. Detta inkluderar kryptering av data både under överföring och i vila, samt säkring av åtkomst till lagrade data baserat på behov.

Implementeringen av nollförtroende i eADM är avgörande för att skydda organisationer mot säkerhetshot genom att ifrågasätta traditionella antaganden om säkerhetsmodeller.

Dataminimering

Dataminimering handlar om att minska mängden personuppgifter och känsliga uppgifter som samlas in, behandlas och lagras till vad som är absolut nödvändigt för att utföra legitima funktioner. Denna princip är en viktig del av den allmänna dataskyddsförordningen (GDPR) och andra dataskyddslagar, och den bidrar till att minska risken för dataintrång och integritetskränkningar.

Begränsad insamling: Endast data som är nödvändiga för specifika funktioner eller tjänster ska samlas in. Till exempel importerar eADM inte lönedata som standard, utan endast om det är nödvändigt för den enskilda kunden.
Kortare lagringstider: Data ska endast lagras så länge det finns en operativ eller juridisk skyldighet . eADM har policyer för datalagring som automatiskt raderar eller anonymiserar data efter behov. Som standard använder eADM 365 dagar för lagring av inaktiverade användare, vilket kan justeras för den enskilda kunden.
Aggregerade uppgifter istället för individuella uppgifter: När det är möjligt bör uppgifter anonymiseras eller aggregeras så att behandlingen inte baseras på individuell identifiering.
Åtkomstkontroll och minsta möjliga behörighet: Genom att införa strikt åtkomstkontroll säkerställs att endast behörig personal har åtkomst till personuppgifter och att användarna endast beviljas de rättigheter de behöver.
Datans syfte och transparens: Tydliga riktlinjer för varför och hur data används, begränsade till de minst ingripande sätten att uppnå dessa syften, bidrar till dataminimering.
Pseudonymisering: Om identifierbara uppgifter måste användas kan pseudonymisering (användning av alias för uppgifter) bidra till att skydda personers identitet och minska effekterna av eventuella dataläckor.

Genom att tillämpa dessa principer kan ett eADM stödja dataminimering i din organisation, vilket innebär bättre skydd av personuppgifter samtidigt som lagkrav uppfylls och användarnas integritet främjas.

Drift och "Grundläggande principer för IKT-säkerhet"

På den operativa sidan har vi baserat vårt säkerhetstänkande på den norska nationella säkerhetsmyndighetens grundläggande principer för IKT-säkerhet.

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

Översikt och kontroll av hur länge vi lagrar användardata samt rutiner för radering.
Åtkomstbehörigheter måste alltid tilldelas på lägsta nivå; ingen ska ha högre åtkomstbehörighet än vad som är nödvändigt för att utföra sitt arbete.
Se avsnitten om åtkomst för åtkomstnivåer för systemanvändare i AD, G Suite och M365.

Skydda och underhålla

Upprätta en säker IKT-arkitektur och skydda företagets nätverk. Kontrollera dataflödet.
Ha kontroll över identiteter och åtkomst.
Alla lösenord måste lagras i ett lösenordsvalv. Lösenord får inte återanvändas. Alla lösenord och åtkomstuppgifter är personliga.
Om du får tillgång till ett kundsystem måste lösenordet och användarnamnet raderas när jobbet är klart.
Skydda data i vila och under överföring.
Spara viktig information om inaktiverade användare i eFeide och eADM för att säkerställa att användarnamn och andra unika identifierare inte kan återanvändas.
Efter en viss tid raderas loggar, personlig information och åtkomst-/rättighetshistorik för en användare automatiskt.

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

I enlighet med den första av de grundläggande principerna om ”inbyggt integritetsskydd” strävar vi aktivt efter att hitta sårbarheter i vårt system. Därför genomför vi årliga penetrationstester av våra lösningar. Dessa utförs av Vismas säkerhetsexperter. Mer information finns under ”Penetrationstestning”.
Hotbedömning sker i samarbete med Nationella cybersäkerhetscentret (NCSC). Identum definieras som kritisk infrastruktur och får meddelanden från NCSC när säkerhetshål och säkerhetsbrister upptäcks i serversystem, programvara och andra IT-system. Identum genomför kontinuerligt hotbedömningar baserade på information från NCSC. Relevanta säkerhetshål åtgärdas kontinuerligt i takt med att vi upptäcker dem.
Alla Identums servrar, både i produktions- och testmiljöer, uppdateras varje vecka. Detta gäller operativsystem, installerade appar och annan programvara. Dessutom uppdateras eFeide och eADM även på söndagar, i enlighet med 14-dagars utvecklingssprintar. Identum har en dedikerad resurs som ansvarar för att säkerställa detta. Efter patchning/uppdatering testas alla system för att säkerställa full funktionalitet. Söndagen har valts på grund av låg belastning och användning på söndagar. eFeide uppdateras inte i samband med skolstarten och tentor, med undantag för driftskritiska uppdateringar.

Hantera och återhämta sig

Alla oönskade incidenter som rör säkerhet eller integritet registreras i ett separat register, inklusive tid, plats, vem, åtgärder och uppföljning efteråt. Förfarandena dokumenteras i Identums interna beredskapsplan. Kunderna informeras om både interna och externa oönskade incidenter i enlighet med servicenivåavtalet (SLA). Förfarandena dokumenteras i Identums interna beredskapsplan. I relevanta fall delas hotbedömningar från NCSC med kunderna.

Identum har ett avtal om assistans från Vismas egen cybersäkerhetsgrupp om företaget utsätts för angrepp, hackas eller om datasäkerheten på annat sätt hotas. Visma kommer då att inrätta ett insatsteam som ansvarar för att hantera situationen, få den under kontroll och återställa alla drabbade system.

Systemövervakning och hot hantering

Sedan den 1 februari 2023 är Identum AS ett helägt dotterbolag till Visma AS och omfattas av Vismas rutiner för cybersäkerhet, övervakning och hothantering. Visma använder Sentinel One (SentinelOne | AI-Powered Enterprise Cybersecurity Platform) för Managed Detection and Response (MDR). Sentinel One övervakar kontinuerligt Identums servrar, klienter, slutpunkter och anställdas datorer. Alla incidenter loggas, utvärderas och hot följs automatiskt upp av Vismas Security Operations Centre (SOC)-team.

Vid en tillräckligt allvarlig säkerhetsincident eller attack underrättas Identum av Visma, som har en jourtjänst dygnet runt, året om, och vidtar åtgärder redan innan Identum underrättas. Om incidenten/attacken bedöms som kritisk eller riktad mot en specifik kund underrättas kunden omedelbart och inkluderas i teamet som hanterar incidenten. Den normala underrättelsetjänsten för våra kunder sker via e-post, men i sådana fall får du även ett telefonsamtal.

Bakdörr och åtkomst om vanlig inloggning inte fungerar

Identum har egna ”break glass”-konton i vår driftsmiljö. Om den vanliga inloggningen för våra anställda av någon anledning inte fungerar kan sådana konton användas för att bevilja eller återställa åtkomst till systemet. Denna bakdörr används inte vid normal drift, och alla inloggningar övervakas med omedelbar avisering. I fall där kundens inloggning till eADM inte fungerar (t.ex. om kundens AAD är nere och SSO därför inte fungerar) kan Identum byta till en annan inloggning under den tid kunden upplever driftstopp, t.ex. från Entra ID SSO till inloggning med ID-porten.

Penetrationstestning

Identum ingår i Vismas PENTEST 2.0-program. Kontinuerlig testning utlöses baserat på faktiska risksignaler, snarare än förfluten tid. Testningen drivs nu av data från andra tjänster i Vismas program för applikationssäkerhet (Software Composition Analysis, Static Application Security Testing, Dynamic Application Security Testing, External Attack Surface Mapping) samt expertbedömningar från Vismas eget penetrationstestningsteam. Våra kunder är naturligtvis fria att utföra sina egna penetrationstester, med eller utan hjälp från tredje part som kunden själv väljer.

Drift och hosting

Identums lösningar är molnbaserade och drivs och underhålls i Entra ID via vår driftpartner Microsoft, med redundans, fjärrbackup och lastbalansering. Vi har två Entra ID-miljöer: i Østfold för norska kunder och i Gävle, Sverige, för EU-kunder. Driftstiden garanteras till 99,9 % (se vårt SLA). Identum ansvarar för operativsystemet och programvaran, medan Microsoft sköter driften av hårdvara, kommunikation, extern säkerhetskopiering, redundans och brandvägg. Endast anställda med tekniskt ansvar hos Identum eller nödvändig driftpersonal hos Microsoft har tillgång till servermiljön. Detta sker via Teamviewer-klienter med MFA. Identum har ett utökat SLA-avtal med Microsoft med en responstid på 10 minuter under kontorstid och 1 timme övriga tider.

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

Korrigeringar och uppdateringar

Patchning av system, komponenter, servrar, databaser etc. utförs varje söndag. Identum har en dedikerad resurs för detta. Identum definieras som kritisk infrastruktur och får meddelanden från National Cyber Security Centre (NCSC) när säkerhetshål och säkerhetsbrister upptäcks i serversystem, programvara och andra IT-system. Identum genomför kontinuerligt hotbedömningar baserade på information från NCSC. Relevanta säkerhetshål åtgärdas kontinuerligt när vi upptäcker dem. Uppdatering av system, komponenter, servrar, databaser etc. sker också varje söndag. Identum använder inte betafunktioner eller betaversioner som standard.

Kryptering

Identums servrar är hostade i Entra ID-molnet och använder därför standardiserad serversidekryptering av all data under lagring. Krypteringsnycklarna hanteras automatiskt av Entra ID-plattformen (Serversidekryptering av Entra ID-hanterade diskar – Entra ID Virtual Machines). Kommunikationen mellan Identums servrar, klienter, webbläsare och tredjepartssystem är krypterad från ändpunkt till ändpunkt via TLS 1.2 med 2048-bitars kryptering, och certifikaten utfärdas av Digicert. Dessa installeras och underhålls av medlemmarna i vårt driftsteam som har nödvändig åtkomst till servrarna och Digicert-tjänsten. De byts ut/har en giltighetstid enligt branschstandarder (12 månader). Databas, säkerhetskopiering och operativsystem är också krypterade. Dessutom är all användardata krypterad. I eADM och eFeide är alla systemlösenord (hemligheter) säkrade med Rijndael AES 256-bitars kryptering. Lösenord för användare lagras i vår LDAP-databas, som använder standard Active Directory-teknik och därför lagrar dem hashade och krypterade. Vid överföring av lösenord (hemligheter) används alltid end-to-end-kryptering via TLS.

Datadifferentiering och separering

Kunddata separeras logiskt med hjälp av ett unikt kund-ID, vilket innebär att varje kund behandlas som en separat sfär. Denna arkitektur speglar den multitenantmodell som finns i Microsoft Entra,
, där logiska gränser säkerställer att varje klient existerar i en självständig miljö.
Alla datatabeller är länkade till detta unika ID, och varje API-förfrågan måste inkludera denna nyckel som en obligatorisk parameter. Genom att tillämpa dessa sfärbaserade gränser säkerställer systemet att
autentisering, auktorisering och datalagring strikt begränsas till den specifika kunden. Detta garanterar att data förblir isolerade och säkra, vilket förhindrar exponering mellan kunder.

Administratörer kan endast beviljas å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 ett utgångsdatum.

Säkerhetskopiering och återställning

Databaser säkerhetskopieras var 10:e minut; produktionsmiljön som helhet säkerhetskopieras dagligen. Säkerhetskopiorna lagras inte i produktionsmiljön, utan i en fysiskt separat miljö. För att verifiera både kvaliteten och innehållet i säkerhetskopiorna samt testa dataåterställningen skapas Identums testmiljö alltid från säkerhetskopior. Testmiljön är en komplett kopia av produktionsmiljön. Detta görs minst var 14:e dag.

Kontinuitetsplan

Vid behov kan hela drifts-/servermiljön återställas från grunden på mindre än sex timmar, antingen i samma miljö eller i en sekundär miljö (t.ex. om den primära miljön utsätts för en DDOS-attack). Det är också möjligt att återställa enskilda kunder från en säkerhetskopia. Detta kan göras både om fel uppstår i samband med uppgradering eller tekniska förändringar av lösningen, eller om kunden behöver återställa, till exempel efter en import av korrupta data från källsystemet. Detta kan beställas via Identums kundsupport, och sådana förfrågningar hanteras som ett fel av nivå A enligt kundens gällande servicenivåavtal vid varje given tidpunkt. Om Identum självständigt beslutar att antingen hela servermiljön eller en specifik kund måste återställas, meddelas kunden, antingen via meddelandetjänsten i eADM eller per telefon.

Förebyggande åtgärder

Identum har, liksom andra Visma-företag, egna rutiner för riskbedömning, riskminimering och riskhantering. Risker identifieras och bedöms utifrån allvarlighetsgrad och sannolikhet (riskbedömning). För varje risk måste det finnas en förebyggande plan (riskminimering) och en hanteringsplan (riskhantering) om risken faktiskt inträffar. Detta material ingår i Identums interna säkerhetsdokumentation. Det är naturligtvis inte offentlig information. Se även avsnitt 3 ”Systemövervakning och hot hantering” och avsnitt 5 ”ISO27001 och Visma Cloud Delivery Model”.

Konsekvenser av driftstopp på eADM

Om eADM drabbas av driftstopp kommer alla konton i organisationen att fungera som tidigare, med alla rättigheter och åtkomster. Så länge eADM är nere kommer inga konton att skapas/uppdateras/inaktiveras/raderas och inga åtkomster/licenser kommer att beviljas/ändras/tas bort av eADM. Det kommer fortfarande att vara möjligt att göra detta manuellt i det enskilda målsystemet.

Konsekvenser av driftstopp på eFeide

Om eFeide, som är användaradministrationssystemet (BAS) för FEIDE-katalogen, drabbas av driftstopp, kommer FEIDE-inloggningen fortfarande att fungera som tidigare. Det är endast om SIKT (den norska myndigheten för gemensamma tjänster inom utbildning och forskning, https://sikt.no/ ) drabbas av driftstopp som FEIDE-inloggningen blir otillgänglig. Om eFeide drabbas av driftstopp kommer funktionerna för hantering av lösenord, internetåtkomst och MFA-administration av FEIDE-konton att vara otillgängliga.

Konsekvenser av driftstopp i källsystem

Om ett källsystem är nere kommer eADM och eFeide naturligtvis inte att uppdateras med nya källdata. Dataflödet från eADM och eFeide till målsystemen fortsätter som tidigare. Exempel på detta är lösenordsändringar, ändringar i grupp-/teammedlemskap, roller och rättigheter. När källsystemet är tillgängligt igen kommer eADM och eFeide att bearbeta alla källdata igen, så att alla väntande användare etc. får de konton och åtkomster som behövs.

Konsekvenser av driftstopp på målsystem

Om ett målsystem är nere under en kortare eller längre period placeras ändringarna i en exportkö. När målsystemet är tillgängligt igen bearbetas kön. Exempel på ändringar som placeras i exportkön är attributändringar (t.ex. användarnamn), lösenord, grupp-/teammedlemskap, roller och åtkomstbehörigheter. Det loggas i eADM när ändringar placerades i exportkön och skickades till de olika målsystemen.

Anmälan

Identum har flera typer av meddelanden om fel, driftstopp eller andra incidenter som har en negativ inverkan på tjänsten:

Automatisk systembaserad avisering → Systemet skickar ut en statusrapport efter varje avslutad synkronisering med allmän information. Dessutom meddelar systemet om synkroniseringen avbryts, t.ex. på grund av korrupta data eller om ett målsystem inte svarar. Det är också möjligt att ställa in egna meddelandekriterier, antingen via e-post eller SMS, t.ex. om en administratör får åtkomst till en användare. eADM kan ställas in så att det automatiskt skickar ett meddelande vid felmeddelanden för enskilda användare, t.ex. om en uppdatering misslyckas i ett målsystem (förutsatt att målsystemet stöder detta!).
Manuell avisering → Identum har en egen aviseringlista med e-post och SMS för alla administratörer i eADM och/eller eFeide. Denna lista används för att meddela incidenter som påverkar en eller flera kunder negativt. Både allmänna och specifika problem kommer att meddelas, i enlighet med SLA.
Observera att kunder som har egna övervakningssystem kan ansluta till loggarna i eADM via API och automatiskt extrahera kontinuerliga loggar med aviseringar, uppdateringar och fel.

Felrapportering

Alla fel som upptäcks av kunden kan rapporteras direkt till Identum via ett formulär som är tillgängligt för administratörer i eFeide och eADM. Detta gäller alla typer av fel, både fel i systemet och anmälningar om integritetsrelaterade incidenter och åtgärder. Alla integritetsrelaterade incidenter behandlas som ett fel av nivå A enligt det överenskomna serviceavtalet (SLA). Alla incidenter hanteras enligt de grundläggande principerna för IKT-säkerhet, avsnitt 4.-4.4. eADM och eFeide har också inbyggda funktioner för att lämna förslag på förbättringar. Alla förslag utvärderas löpande.

Informationssäkerhet

GDPR och integritet

Som grundprincip för import av källdata till våra system importerar vi endast användare och användardata som ska bearbetas vidare. Om en anställd inte ska ha ett konto i AD filtrerar vi bort detta från att importeras till våra system överhuvudtaget. Förmyndardata används inte vid import till Feide-kataloger. Endast relevant användardata importeras; till exempel importerar vi anställningsprocent (vilket kan vara relevant i samband med tilldelning av licenser) men inte lönedata. Det är viktigt att betona att det är källdatasystemen (HRM och SAS) som har företräde. När en användare skapas i HRM skapas användaren i eADM. När en användare inaktiveras eller raderas från systemet raderas även tillhörande data, enligt regler som fastställts i eADM. Det kan till exempel automatiseras så att användare först inaktiveras och sedan raderas från systemet efter en viss tid.

Säkerheten och integriteten i eADM är helt beroende av att kunden har bra rutiner för att registrera och avregistrera användare från sina källsystem. En vanlig suck från administratörer när det gäller användarkontons livscykel är att ”alla märker när någon börjar, men ingen märker när någon slutar”. Därmed riskerar man att gamla användarkonton och personuppgifter ligger kvar under lång tid. Lösningen på detta är bra regelsatser i eADM som säkerställer att data som inte ska lagras raderas, t.ex. när användaren inaktiveras, går på ledighet, avlider eller slutar. eADM automatiserar detta och säkerställer att alla användarkonton antingen tas bort automatiskt eller att nödvändiga mottagare meddelas när något måste göras manuellt. Via meddelandemallar kan IT, drift och administration meddelas när utrustning ska lämnas in eller åtkomstbehörigheter ska ändras eller tas bort. Alla användare har en inloggning till användargränssnittet och alla kan när som helst se alla uppgifter som är registrerade för sin egen användare.

I samband med GDPR och integritet kan slutanvändarna se sina uppgifter i ett integritetsavsnitt där vi också anger varifrån uppgifterna kommer, vem de ska kontakta om något är felaktigt eller om de vill att uppgifterna ska raderas. Identums lösningar uppfyller alla krav i normen för informationssäkerhet. Se bilaga 9 i avtalet för Identum AS:s databehandlingsavtal. Vi har som princip att vi anpassar oss efter våra kunder, istället för att de ska behöva anpassa sig efter oss. Om vårt standarddatabehandlingsavtal inte täcker kundens behov anpassar vi oss och använder det avtal som kunden önskar.

Underleverantörer

Se Visma Trust Centre för information om våra webbhotellleverantörer och databehandlare:

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

ISO27001 och Visma Cloud Delivery Model

Sedan den 1 februari 2023 är Identum AS ett helägt dotterbolag till Visma AS och omfattas därmed av deras kvalitetssystem och leveransmodell som beskrivs här: Visma Cloud Delivery Model (VCDM) beskriver vår strategi för utveckling, leverans och drift av molntjänster. Den beskriver aspekter av hur vi bör organiseras, hur vi bör arbeta (processer) samt tekniska krav och bästa praxis som är nödvändiga för en framgångsrik leverans av molntjänster. Mer information om VCDM finns på: Visma Cloud Delivery Model (VCDM). Modellen baseras på en uppsättning grundläggande principer och fokuserar på DevOps och kontinuerlig leverans. VCDM har följande revisionsuttalande och certifieringar:

ISAE 3402 SOC 1 Typ II
ISO 27001

Visma Security Programme och Visma Architecture and Technology Programme är integrerade i Visma Cloud Delivery Model. Vårt informationssäkerhetshanteringssystem (ISMS) är certifierat enligt ISO 27001 och granskas årligen av en oberoende IT-revisor. Dessutom granskas Vismas förmåga att följa ISMS och kvalitetsledningssystemet i VCDM av ett oberoende revisionsföretag i enlighet med ISAE 3402. Denna omfattande kontroll utförs också årligen och sammanfattas i en ISAE 3402 Type II-rapport. Vår strategi för att genomföra förändringar är kontinuerlig integration och kontinuerlig distribution (CI/CD). Metodiken utvecklas ständigt när det gäller teknik, kompetens och procedurer. Just nu innebär detta att förändringar kontinuerligt verifieras och implementeras i vår stagingmiljö. Där utförs manuella tester både internt i utvecklingsavdelningen och av ämnesexperter. För mer omfattande förändringar använder vi också pilotkunder som testar förändringarna i normal drift 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 i allmänhet ingen driftstopp. Om detta skulle inträffa kommer det att genomföras inom fördefinierade servicefönster och meddelas i enlighet med SLA. Vi har en gemensam, automatisk uppgraderingsprocess för alla miljöer. Frekventa och små uppdateringar innebär en 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 dolda bakom funktionsomkopplare, så att funktionaliteten endast aktiveras när den är klar för kunden. I kombination med automatiserade tester ger detta hög stabilitet, färre fel och snabb lansering av nya funktioner. Uppdateringar kommer att kommuniceras på olika sätt beroende på förändringens storlek och omfattning:

Mindre ändringar, såsom buggfixar som inte påverkar kunden eller användaren, kommer att meddelas genom en uppdatering av release notes.
Medelstora förändringar, såsom ändringar eller tillägg i arbetsprocesser eller skärmbilder, kommer att meddelas i release notes, meddelanden på startsidan, uppdaterad användardokumentation och på Visma Community.
Stora förändringar, såsom nya viktiga funktioner eller en större förändring i en arbetsprocess, kan dessutom åtföljas av webbseminarier och/eller uppdaterad e-learning.

Vid större förändringar som kräver utbildning och/eller konfiguration av systemet kommer vi att involvera kunden innan vi genomför förändringen. Omfattningen av detta kommer att variera beroende på vilken typ av förändring det rör sig om. Vår strategi för att hantera eventuella fel som kan uppstå under uppdateringar är att "rulla framåt". Det innebär att vi vill korrigera felet och uppdatera med en ny version, snarare än att rulla tillbaka. Endast i undantagsfall och vid allvarliga fel är det relevant att rulla tillbaka.

Säkerhet och åtkomsthantering

Identum driver sin programvara huvudsakligen via webbapplikationer: https://mega.efeide.no, https://mega.eadm.no och https://mega.eADM.se. All åtkomst till webbapplikationerna skyddas av en captcha, användarnamn och lösenord samt 2FA-autentisering. Kunden kan själv använda dessa portaler för administration och självbetjäning, men då med andra åtkomsträttigheter (se avsnittet om åtkomsthantering). Vi rekommenderar alla våra kunder att använda autentisering med MFA aktiverat, och vi kräver att all åtkomst till alla våra system på administratörsnivå måste ske med MFA. Vi erbjuder inloggning via användarnamn/lösenord med MFA, ID-porten eller SSO med Entra ID. Om SSO används kräver vi att åtkomsten är skyddad på behörighetsnivån avdelningschef och uppåt. Det är en viktig princip att inte bevilja högre åtkomst än vad som är nödvändigt.

Vi rekommenderar därför att du är restriktiv när det gäller att bevilja åtkomst på administratörsnivå. För de allra flesta dagliga arbetsuppgifter räcker det med åtkomst på servicedesk-nivå. För användare som endast behöver lösa en specifik uppgift, till exempel hantera lösenord för en avdelning, räcker det med superanvändaråtkomst. Endast absolut nödvändig personal bör ha administratörsåtkomst till systemet, och detta bör vara tidsbegränsat. Denna princip begränsar åtkomsten till personuppgifter och möjligheterna att tilldela åtkomst eller rättigheter. Alla ändringar som görs via webbgränssnittet loggas automatiskt. Kunden underrättas rutinmässigt om oönskade incidenter, utöver den dagliga statusrapporten från våra system.

Vi betonar att vi rekommenderar att åtkomst till eFeide och eADM skyddas med tvåfaktorsautentisering för alla användare med administratörsåtkomst; denna funktion ingår i lösningarna. Vår policy för åtkomsthantering är att användare inte ska ges en högre åtkomstnivå än de behöver i det dagliga arbetet; högre åtkomst bedöms utifrån behov. Administratörsåtkomst bör endast tilldelas ett fåtal utvalda användare som har genomgått utbildning i användningen av systemet. Ett exempel kan vara att första linjens support hos kunden har tillgång till servicedesk, medan endast tredje linjen har tillgång till systemet på administratörsnivå. Identum rekommenderar alla våra kunder att följa denna policy när de fastställer regler för automatisk eller manuell åtkomsthantering till affärssystem, tredje part etc. via eADM.

Intern personal

Detta gäller även Identums egna anställda. Anställda får endast nödvändig åtkomst i enlighet med sin position och funktion. När anställda slutar tas all åtkomst omedelbart bort. Identum använder inte hjälp från externa tredje parter och har en policy som innebär att 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 tydligt definierade och granskas och behovstestas regelbundet i enlighet med ISO27001. Alla ändringar som görs i systemet loggas på samma sätt som kundens egna användare. Om en anställd i Identum beviljar åtkomst till ett affärssystem hos en kund loggas detta i historiken för den användare som fått åtkomsten. Det är inte möjligt att kopiera användardata mellan de olika instanserna i användargränssnittet, endast mallar och regelsatser.

Åtkomstkontroll

Både eFeide och eADM stöder olika metoder för användarinloggning, inklusive tvåfaktorsautentisering. Vi erbjuder (naturligtvis) FEIDE-inloggning, ID-porten, ADFS/LDAP, SSO med Entra ID/EntraID, SSO med Google Workspace och andra SAML2.0-auktoriseringslösningar. Vi förväntar oss att kunderna skyddar SSO-inloggningen med MFA. Det rekommenderas inte att åtkomst till eADM och eFeide sker utan tvåfaktorsskydd, inte ens på medarbetar-/avdelningschefsnivå. På servicedesk- och administratörsnivå kräver vi att våra kunder skyddar SSO med MFA eller alternativt använder ID-porten. Systemåtkomst kan ges automatiskt baserat på regeluppsättningar eller manuellt för den enskilda användaren. Vi rekommenderar att administratörsåtkomst endast ges manuellt och baserat på behov. Åtkomst kan ges med eller utan utgångsdatum, och systemet har en lösning för både aktiv och passiv åtkomstgranskning vid givna tidsintervall. De olika åtkomstnivåerna kan administreras på grupp-, roll- och personlig nivå. Till exempel kan inloggningen till användargränssnittet för eFeide regleras så att alla som har åtkomst till att se personuppgifter om andra användare måste logga in med tvåfaktorsautentisering, medan studenter (som bara kan se sina egna uppgifter) kan logga in utan att använda tvåfaktorsautentisering.

Anställda

Systemet tar också hänsyn till att en och samma användare kan ha olika roller i olika avdelningar, med olika behov och åtkomstbehörigheter. En anställd kan se all tillgänglig information om sig själv och ändra sitt lösenord. En avdelningschef ser endast sina anställda. Om en användare är avdelningschef och samtidigt är anställd på en annan nivå i organisationen, har denna användare endast administratörsåtkomst till den avdelning där han/hon är avdelningschef. I den andra avdelningen har han/hon endast vanlig anställdsåtkomst. De sex rollerna ger åtkomst till funktionsområden, underliggande information och funktionalitet.

Historik, loggar och åtkomstgranskning i eADM

eADM loggar alla ändringar som görs på objektnivå, dvs. för användare, grupper och avdelningar. Loggarna är tillgängliga för alla som har administratörsbehörighet i lösningen. Både ändringar som kommer in från källsystem och ändringar som görs i eADM loggas. Systemet loggar också alla data som skickas till de olika källsystemen, så att du får en fullständig översikt över vilka data som har exporterats och vart. Alla poster loggas med objekt-ID, datum/tid, orsaken till ändringen, vem som utförde ändringen om det är en manuell ändring, det tidigare värdet och det nya värdet. Alla ändringar av själva systeminställningarna loggas också. Det innebär alla ändringar av regelsatser, synkroniseringsmallar, meddelandeflöden, åtkomstkontroller och arbetsflöden. Alla loggar lagras, krypteras och skyddas digitalt och fysiskt enligt samma standarder som Identums övriga data. Loggarna kan inte ändras av någon typ av användare, inte ens Identums egen ”superduper”-administratörsroll. Loggarna kan exporteras för bearbetning i tredjepartssystem. Alla incidenter, loggar etc. kan ställas in så att de utlöser en avisering via e-post eller SMS när de inträffar. Systemet kan till exempel meddela specifika felmeddelanden i samband med export till känsliga system eller när en användare loggar in med en IP-adress utanför ett visst geografiskt område.

Loggning av ändringar av användardata, rättigheter och åtkomst

I eADM:s användargränssnitt kan man också se alla åtkomstbehörigheter och licenser som tilldelats en användare, både i eADM och i associerade målsystem. Historiken visar när en åtkomst eller licens tilldelades, oavsett om den tilldelades automatiskt baserat på en regeluppsättning eller manuellt av en användare. Man kan se vad en användare har åtkomst till i ett ärende-/arkivsystem och vilken typ av åtkomst det rör sig om. eFeide loggar alla rättighetsändringar utöver ändringar i användardata och lösenord. Om en åtkomst beviljas av en regeluppsättning kan man dessutom spåra vem som gjorde ändringen i regeluppsättningen som utlöste åtkomsten.

Säkerhets- och lösenordsloggar

Säkerhetsloggningen i eADM loggar alla inloggningsförsök, både auktoriserade och icke auktoriserade, med vem, tid, plats (IP), typ av autentisering och status. Dessutom loggas alla felmeddelanden, med metod (t.ex. typ av API-anrop), tid, användare och IP. Alla lösenordsändringar loggas, med tids- och datumstämpel, hur lösenordsändringen 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 tillgång till kunddata i eADM via användargränssnittet. Dataflödet till målsystemen styrs via synkroniseringsmallar där kunden själv bestämmer vilka data som ska exponeras för/överföras till varje enskild tredje part. eADM tillåter inte tredje parter att hämta data från systemet efter eget gottfinnande, såvida inte kunden uttryckligen beviljar denna åtkomst via API:et. Se även punkten om ”Penetrationstestning”.

Hantering av lösenord

I eADM och eFeide skyddas alla systemlösenord (hemligheter) med Rijndael AES 256-bitars kryptering. Användarnas lösenord lagras i vår LDAP-databas, som använder standardtekniken Active Directory och därför lagrar dem hashade och krypterade. Vid överföring av lösenord (hemligheter) används alltid end-to-end-kryptering via TLS. Detta gäller all överföring av data till och från lösningen. Lösenord är inte tillgängliga för några användare i eADM eller eFeide, vare sig det är de anställda själva, avdelningschefer eller administratörer. Det enda undantaget är initiala lösenord, eftersom de naturligtvis måste vara läsbara, utskrivbara och skickas till den anställde. Efter den första inloggningen kommer detta lösenord att ändras och lagras krypterat. Från och med då kommer ingen att kunna se det; det kan bara ändras. Initiala lösenord för användare skapas i eADM/eFeide när ett användarkonto skapas. Lösenordet genereras enligt regelsatser som ställts in enligt kundens krav, t.ex. 16 tecken, versaler, minst 1 specialtecken.

När ett användarkonto skapas i målsystem som AD, Entra ID eller affärssystem kan användarna skapas med samma initiala lösenord. Detta överförs krypterat. Lösenord kan ändras i våra lösningar och överföras i realtid till målsystemen. Det kan ställas krav på att användarna måste ändra sitt initiala lösenord i samband med inloggning på Entra ID, AD och Google innan de får logga in. Identum har en lösning för att återställa lösenord via SMS eller via autentisering genom ID-porten, och vi rekommenderar starkt ID-porten. Alla lösenordsändringar loggas med tids- och datumstämpel, hur lösenordsändringen gjordes, vem som initierade lösenordsändringen, om lösenordet exporterades vidare till andra målsystem och med eventuella felmeddelanden. I eADM kan avdelningschefer ä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 ett mobilnummer är registrerat på användaren.

Vi rekommenderar dock att rutinen ska vara att anställda gör detta själva via portalen för glömda lösenord. 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 ett mobilnummer är registrerat för användaren. Vi rekommenderar dock att rutinen är att anställda gör detta själva via portalen för glömda lösenord. I eFeide kan lärare ändra lösenord för elever, skoladministratörer kan ändra lösenord för elever och lärare på sin skola, och kommunala administratörer kan ändra lösenord för alla användare. Feide stöder inte tvingad lösenordsändring.

Säkerhet och Feide-tjänster

I eFeide kan administratörer hantera inloggning med MFA för vissa Feide-tjänster för anställda. Krav på MFA för Feide-tjänster kan ställas både individuellt och för hela skolor. En tvåfaktorsmetod är vad en användare använder för att bevisa sin identitet när en Feide-tjänst kräver tvåfaktorsautentisering. Feide har fyra olika tvåfaktorsmetoder tillgängliga: inloggning via ID-porten, kod via SMS, kodblad och autentiseringsklient (MS Authenticator eller Google Authenticator). Vilka Feide-tjänster som ska skyddas med MFA är upp till den enskilda kunden. Vår tumregel är att alla Feide-tjänster där personlig information om elever och/eller anställda lagras ska skyddas med MFA. Ett molnbaserat skoladministrativt system är ett exempel på ett system som enligt vår mening bör skyddas med tvåfaktorsinloggning.

Export av personuppgifter till målsystem

Både eADM och eFEIDE innehåller personuppgifter, och man bör vara försiktig med vilka uppgifter som exporteras till vilka målsystem. En tumregel bör vara att man endast exporterar den minsta mängd uppgifter som målsystemet behöver. Dessutom bör en behovsbedömning göras för uppgifter som personnummer, privat kontaktinformation, löneuppgifter etc.

Användning av nationella identitetsnummer i Active Directory

Vi rekommenderar att om ett nationellt identitetsnummer används som ett unikt identifieringsattribut i AD (t.ex. i attributen employeeID eller employeeNumber), bör detta antingen krypteras (det finns funktioner för detta i båda systemen) eller döljas så att endast administratörer kan se dessa attribut: Hur man döljer användarattribut i Active Directory.

Användning av personnummer i Entra ID / Entra ID

Vi rekommenderar inte att nationella identitetsnummer används som unikt identifieringsattribut i Entra ID, eftersom detta fält inte kan skyddas eller döljas. Använd istället personalnummer eller någon annan unik nummerserie.

Sammanfattning för AI och sök

Detta dokument beskriver det omfattande säkerhetsramverket för Identums produkter eADM och eFeide. Det omfattar utvecklingsfilosofierna ”Privacy by Design” och ”Zero Trust”, ISO 27001-certifiering via Visma Cloud Delivery Model och säker hosting i Microsoft Entra ID. Ramverket omfattar kontinuerlig övervakning av hot från Visma SOC, årliga penetrationstester, robusta planer för säkerhetskopiering och katastrofåterställning samt detaljerade policyer för kryptering, åtkomstkontroll och GDPR-kompatibel datahantering.