Svensk molndrift
Drift med svensk förankring där era data stannar i Sverige.
Säkerhet i Hubs
Kontroll där
den behövs.
Rätt åtkomst. Skyddad information. En drift ni kan granska. Hubs samlar säkerheten kring er organisation och era krav.
Er organisationEn egen Hubs-instans
01Rätt person får tillgång
02e-legitimation · Er identitetsleverantör · Behörigheter
Informationen skyddas
03Kryptering per funktion · Kundunika nycklar
Ni väljer driftmodell
Svenskt moln · Lokal installation · Hybrid
Spårbarhet och dokumenterade rutiner genom hela kedjan.
Skyddet i korthet
Säkerhet i varje del av arbetet.
01
Åtkomst på era villkor
Anslut er identitetslösning och styr behörigheter med roller och grupper.
Granska området 02Skydd per funktion
Se hur meddelanden, filer och möten skyddas under överföring och lagring.
Granska området 03En egen miljö
Varje organisation har en dedikerad instans med separerade miljöer.
Granska området 04Spårbarhet över tid
Följ säkerhetshändelser, ändringar och incidenter med dokumenterade rutiner.
Granska områdetFör er säkerhetsgranskning
Från översikt
till detaljer.
Öppna de områden som är viktiga för er. Här finns plattformens beskrivna skydd, tekniska förutsättningar och gränser för leveransen.
Identitet och behörighetere-legitimation, SAML/OIDC, MFA och kontolivscykel
Inloggning federeras mot er befintliga identitetsleverantör via SAML 2.0 eller OIDC — er egen MFA-policy gäller — och stark autentisering sker med svensk e-legitimation via förmedlingstjänst. Plattformen har därtill inbyggt stöd för WebAuthn.
Kontolivscykeln — att konton skapas, uppdateras och avslutas — automatiseras via standardprotokollet SCIM 2.0: er katalogtjänst — exempelvis Microsoft Entra ID — skapar, uppdaterar och inaktiverar konton, kompletterat med katalogsynkronisering via LDAPS och en återkommande avstämning som fångar ändringar som provisioneringsflödet inte förmedlat. Vid användning av administratörskonton krävs alltid multifaktorautentisering, och alla ändringar via sådana konton dokumenteras.
Kryptering och nycklarSkydd i överföring och lagring, funktion för funktion
Tabellen sammanfattar hur data skyddas under överföring och i lagring, med länk till var respektive funktion beskrivs. Nyckellagring, rotation och möjligheten att dekryptera går vi igenom för er valda lösning.
Tabellen kan rullas i sidled.
| Funktion | I transit | I vila | Beskrivs här |
|---|---|---|---|
| Meddelanden | TLS 1.2 eller högre; end-to-end-kryptering som standard. Autentisering via BankID, SITHS och Freja eID. | Krypterade lagringsvolymer med kundunika nycklar per instans. | Plattform → Meddelanden |
| Filhantering | TLS 1.2 eller högre för all extern åtkomst; kontrollerad extern delning med lösenord och utgångsdatum. | Server-side-kryptering; end-to-end-kryptering på mappnivå som tillval. Säkerhetskopior lagras krypterade. | Plattform → Filhantering |
| Video och chatt | Krypterad realtidstrafik (WebRTC med säkra protokoll); möten hanteras i er miljö utan externa tredjepartstjänster. | Krypterade lagringsvolymer med kundunika nycklar per instans. | Plattform → Video & chatt |
| SDK — säker digital kommunikation | Ömsesidig TLS (mTLS) i meddelandekedjan; spårbar leverans med kvittens och ärendelogg via DIGG:s ramverk. | Krypterade lagringsvolymer; policystyrd gallring per brevlåda. | Plattform → SDK |
| Signering | TLS 1.2 eller högre; undertecknaren skriver under med BankID. | Signerade dokument förseglas kryptografiskt med tidsstämpel och lagras på krypterade volymer — ändringar i efterhand upptäcks. | Plattform → Signering |
| Federation mellan organisationer | TLS server-till-server via det öppna protokollet Open Cloud Mesh; delning och samtal sker endast på uttrycklig inbjudan. | Data stannar i respektive organisations egen instans — även vid samarbete över organisationsgränser. | Plattform → Arkitektur |
| Confidential Computing — tillval | För särskilda säkerhetskrav kan data skyddas även under bearbetning, i betrodda exekveringsmiljöer (TEE) — ett tillval som aktiveras på beställning. | Plattform → Arkitektur | |
| AI-assistent | All AI-bearbetning sker i ITSL:s egna svenska datacenter med lokala öppna språkmodeller — inga anrop till externa AI-tjänster; gäller även vid lokal installation | Plattform → AI-assistent | |
Loggning och spårbarhetHändelser, tidsstämplar och skydd av loggar
Säkerhetsrelevanta händelser loggas centralt och skyddas mot obemärkt manipulation.
Tabellen kan rullas i sidled.
| Händelsetyp | Vad som registreras |
|---|---|
| Inloggningar | Lyckade och misslyckade inloggningsförsök, med användare, tidpunkt och IP-adress. |
| Filhändelser | Skapande, åtkomst och radering av filer. |
| SDK-meddelanden | Skickade SDK-meddelanden, med den sändningslogg och kvittens som DIGG:s regelverk kräver. |
| Konto- och konfigurationsändringar | Ändringar i inställningar samt kontohändelser — skapande, attributändring, inaktivering och radering — i applikationens revisionslogg. |
| Administrativa åtgärder | Åtgärder med förhöjd behörighet loggas separat för granskning. |
Loggarna lagras centralt på en loggserver som är separerad från applikationsservrarna, så att de inte kan manipuleras obemärkt — åtkomst till råloggar kräver särskild behörighet och stark autentisering. Alla servrar tidssynkroniseras via NTP, vilket ger konsistenta tidsstämplar över alla loggkällor, och automatiska realtidslarm utlöses vid avvikande mönster.
Instanser och miljöseparationEr produktion, QA, demo och utveckling
Hubs är uteslutande en single-tenant-plattform: varje organisation har en dedikerad instans i både applikations- och databasskiktet, med kundunika krypteringsnycklar. Hur instansmodellen är uppbyggd beskrivs i arkitekturöversikten.
Tabellen kan rullas i sidled.
| Miljö | Syfte | Separation och data |
|---|---|---|
| Produktion | Er skarpa miljö med verkliga data och användare. | Hårt säkrad med fullständig säkerhetskopiering. Endast behörig driftpersonal kan göra ändringar — utvecklare har ingen direktåtkomst. |
| QA | Integrationstester och kvalitetssäkring tillsammans med er före driftsättning. | Speglar produktionskonfigurationen och ger er möjlighet att verifiera ändringar i förväg. Säkerhetskopieras i mer begränsad omfattning. |
| Demo | Visning och utvärdering under en avgränsad period. | Innehåller aldrig skarp kunddata; miljöerna är temporära och avvecklas efter behov. |
| Utveckling | ITSL:s interna miljöer för ny funktionalitet. | Helt avskilda — ingen kundåtkomst och ingen koppling till produktionsdata eller externa tjänster. |
Alla icke-produktionsmiljöer är strikt avskilda från produktionen och körs på separata instanser och nät — produktionsdata blandas aldrig in i test-, demo- eller QA-miljöer. Eftersom miljöerna byggs ur kod kan de återskapas från grunden i stället för att drivas som permanenta instanser, vilket håller dem identiska med aktuell produktionskonfiguration.
AI och öppen källkodSvensk AI-bearbetning och möjlighet att granska komponenterna
AI på ITSL:s svenska GPU:er
All AI-bearbetning sker i ITSL:s egna datacenter i Sverige, med lokala språkmodeller med öppen källkod och öppna vikter. Inga anrop går till externa AI-tjänster. Det gäller även vid lokal installation: väljer ni AI-stöd sker bearbetningen i ITSL:s driftmiljö.
En plattform byggd på öppen källkod
Hubs paketerar etablerade komponenter som Collabora, Moodle, OpenProject och Vaultwarden. Komponenterna ger möjlighet till granskning och vidareutveckling enligt respektive licens.
Drift, förändring och ansvar
Säkerhet är också
ett arbetssätt.
Rutinerna ska hålla både i vardagen och när något händer. Konstruktionsmål och interna arbetsmål är åtskilda från de servicenivåer ni avtalar om.
Driftmodell och fysisk säkerhetSvenskt moln, lokal installation eller hybrid
Hubs kan driftas i tre modeller. Välj utifrån era informationsklasser och krav. Se arkitekturöversikten.
Lokal installation
Drift i er egen infrastruktur. Om ni väljer AI-stöd bearbetas AI-anrop i ITSL:s svenska driftmiljö.
Hybrid
Blanda driftmodeller utifrån informationsklasser och mognad — stegvis migrering utan tvärstopp.
Driftkedjan bakom svensk molndrift
Svensk molndrift levereras från två geografiskt skilda datahallar i Stockholmsregionen, med redundant kraftförsörjning, kylning och brandskydd samt fysiskt tillträdesskydd i flera lager där all inpassering loggas. Därutöver finns en geografiskt skild, fysiskt skyddad katastrofplats i Sverige med uppdaterade kopior av systemet. Miljön övervakas dygnet runt, och ytterligare detaljer om driftkedjan — anläggningar och partner — redovisas under sekretess i upphandlingar och kundprojekt.
Backup och återställningKonstruktionsmål, geografisk separation och återläsningstester
Tabellen beskriver hur plattformen är konstruerad för säkerhetskopiering och katastrofåterställning. Värdena är konstruktionsmål — det plattformen är byggd och testad för — inte avtalade servicenivåer; avtalade nivåer regleras i ert avtal.
Tabellen kan rullas i sidled.
| Område | Så är plattformen konstruerad |
|---|---|
| Säkerhetskopiering | Täta ögonblickskopior kompletteras med dagliga inkrementella och veckovisa fullständiga kopior av databas, filytor och konfiguration — flera generationer bevaras, så att återställning kan ske till olika tidpunkter. |
| Återställningspunkt (RPO) | Konstruktionsmålet är att högst omkring en timmes arbete ska kunna gå förlorat även vid en totalförlust — ofta mindre. |
| Återställningstid (RTO) | Konstruktionsmålet vid en total katastrof är återställd drift inom minuter till timmar, beroende på händelsens art och omfattning. |
| Geografisk separation | Säkerhetskopior skrivs krypterade till en backupmiljö som är fysiskt och logiskt åtskild från produktionen. En sekundär datahall och en geografiskt skild, fysiskt skyddad katastrofplats i Sverige ger ytterligare redundans. |
| Skydd mot utpressningsangrepp | Produktionsmiljön kan bara lägga till nya säkerhetskopior — inte radera eller skriva över historiken. Åtkomsten till backupmiljön är strikt begränsad, och kopiorna är oläsliga utan rätt nyckelmaterial. |
| Återläsningstester | Återläsning från backup testas regelbundet. Eftersom hela miljön är definierad som kod kan den dessutom återuppbyggas ur kod och återlästa data — oberoende av den ursprungliga servern. |
Ändringar i er miljöStandardändringar, normaländringar och akutändringar
Alla ändringar i er miljö följer en av tre fastställda rutiner enligt ITIL 4 (Change Enablement) — vid planerade ändringar vet ni i förväg vad som ändras, kan verifiera i er egen QA-miljö och kan invända; akutändringar följer i förväg etablerade kontakt- och eskaleringsvägar. Inga direktändringar görs i produktion utanför dessa rutiner.
Tabellen kan rullas i sidled.
| Ändringstyp | När den används | Godkännande | Så genomförs den |
|---|---|---|---|
| Standardändring | Rutinmässiga version- och paketuppgraderingar med låg risk samt säkerhets- och felrättningar som verifierats i QA. | Förhandsgodkänd rutin med tyst godkännande — ni får en changelog i förväg och kan alltid invända aktivt; då planeras driftsättningen om. | Fast rytm: changelog, uppdatering av er QA-miljö, verifieringsfönster där ni testar själva, därefter produktionssättning utanför kontorstid med efterkontroll. Inkommande SDK-meddelanden köas under driftsättningen och behandlas när miljön åter är tillgänglig. |
| Normaländring | Ny integration, ny ansluten organisation, arkitekturförändring eller annan ändring med väsentlig eller svårbedömd påverkan. | Aktivt godkännande av er ändringsauktoritet — till exempel change manager eller ändringsråd — enligt er egen ändringsprocess. | Formell ändringsbegäran med risk- och konsekvensbedömning, testplan och återgångsplan; efterutvärdering genomförs för väsentliga ändringar. |
| Akutändring | Brådskande åtgärd för att åtgärda eller förebygga en incident, till exempel en säkerhetsrättning som inte kan invänta ordinarie cykel. | Påskyndat godkännande via kontakt- och eskaleringsvägar som etablerats i förväg — även utanför kontorstid. Beslutet dokumenteras alltid i efterhand. | Genomförs kontrollerat med verifiering och efterutvärdering. Rutinen får aldrig användas för att kringgå ordinarie planering. |
Gemensamt för alla tre: korrigering sker framåt genom en ny version i stället för återställning bakåt, eftersom databasförändringar är framåtriktade, och varje ändring dokumenteras spårbart med ändrings-ID i ett versionshanterat system. Rutinerna är fastställda i ITSL:s verksamhetsledningssystem som ITSL-RUT-CHG-001, 002 och 003.
SårbarhetshanteringBevakning, bedömning och prioriterad rättning
Sårbarhetsarbetet är en löpande kedja från omvärldsbevakning till applicerad rättelse. Den målsatta tiden om 24 timmar är ett arbetssätt, inte en avtalsnivå — avtalade åtgärdstider regleras i ert avtal.
Bevaka
Aktiv omvärldsbevakning via CERT-SE, MSB och CVE-databaser samt säkerhetsbulletiner för plattformens öppna komponenter. Automatiska skanningar av systemets nätverksytor, även i produktionsmiljön, kompletterar bilden.
Bedöma
När en ny sårbarhet upptäcks analyseras om Hubs är påverkad och vilka skyddsåtgärder som krävs. Med jämna mellanrum görs dessutom manuella genomgångar av säkerhetsarkitektur och hotbild för att fånga risker som verktygen missar.
Åtgärda
Uppdateringar testas i QA-miljö innan de når produktion. Kritiska säkerhetsrättelser prioriteras alltid, med 24 timmar som målsatt tid från tillgänglig rättelse till applicerad — vid behov via akutändringsrutinen. Övriga rättelser tas med i nästa ordinarie release.
När en incident inträffarUpptäckt, begränsning, utredning och återställning
Incidenter hanteras enligt en fast process där ni informeras tidigt och varje steg dokumenteras.
1. Upptäckt och klassificering
Incidenter fångas via larm eller felanmälan och klassificeras direkt utifrån allvarlighetsgrad och påverkan. Vid misstänkt säkerhets- eller personuppgiftsincident larmas den informationssäkerhetsansvariga funktionen omedelbart.
2. Begränsning
Första steget är att begränsa skadan: drabbade system eller konton isoleras för att stoppa pågående angrepp och säkra bevismaterial.
3. Utredning
Intrångsväg, omfattning och vilka data eller användare som påverkats kartläggs genom logganalys och forensiska verktyg.
4. Information till er
Er utsedda kontaktperson får tidigt besked om vad som hänt, vilka initiala fakta som finns och vilka åtgärder som vidtas — med löpande uppdateringar tills incidenten är löst.
5. Återställning och lärdom
När incidenten är åtgärdad görs en rotorsaksanalys, och en incidentrapport med tidslinje, påverkan och lärdomar upprättas och delas med er.
Incidentrapportering och uppföljningUnderlag till er säkerhetsfunktion och ert dataskyddsombud
Stöd vid personuppgiftsincidenter
ITSL underrättar er utan onödigt dröjsmål när vi får vetskap om en personuppgiftsincident. Vi hjälper till med fakta om berörda uppgifter, omfattning, konsekvenser och åtgärder. Ni bedömer anmälningsplikten. Anmälningspliktiga incidenter ska som utgångspunkt anmälas till IMY inom 72 timmar från att ni fått vetskap om dem.
IMY om personuppgiftsincidenter
Rapportering enligt tillämpliga säkerhetsregler
Vi dokumenterar tidslinje, påverkan och åtgärder och ger er de tekniska fakta ni behöver. Vilka skyldigheter och tidsfrister som gäller beror på er verksamhet, tillämpliga regler och ert avtal.
Efter incidenten
Rotorsaken utreds. En rapport med tidslinje, påverkan och lärdomar delas med er och följs vid behov av förbättringsåtgärder.
Styrning och ansvarInformationssäkerhetspolicy, riskhantering och utbildning
Informationssäkerhetsarbetet styrs av en fastställd informationssäkerhetspolicy som omfattar all informationshantering och gäller alla medarbetare, konsulter och samarbetspartners med tillgång till företagets informationsresurser. VD har det yttersta ansvaret, och en utsedd informationssäkerhetsansvarig leder den dagliga styrningen och den kontinuerliga förbättringen.
Riskhanteringen bedrivs proaktivt och är integrerad i verksamhetens löpande processer, alla medarbetare genomgår obligatorisk säkerhetsutbildning, och policyn granskas årligen eller vid betydande förändringar i verksamheten eller hotbilden.
Granska tillsammans
Låt era krav styra samtalet.
Ta med era säkerhetsfrågor. Vi går igenom skydd, drift och ansvar utifrån den Hubs-miljö ni behöver.