Lager 1: Säker kommunikation
Spårbara, krypterade kanaler med rätt säkerhetsnivå i varje flöde.
För arkitekter
Så är Hubs uppbyggt.
För er som tar fram tekniskt underlag: en strukturell genomgång av applikationslagren, identiteten, SDK-anslutningen, Teams Bridge och var era data lagras.
Översikt
Arkitekturen i översikt.
Webbaserade klienter, tre applikationslager, identitet via era befintliga lösningar, två anslutningar utåt och en lagring ni själva bestämmer placeringen av.
Applikationslagren
Tre lager, tretton moduler.
Varje lager motsvarar ett verkligt behov. Hubs införs modulärt — många börjar med säker kommunikation, SDK eller Teams Bridge och bygger sedan ut i sin egen takt.
Lager 2: Säkert samarbete
Dokument och arbetsytor med kryptering, behörigheter och versionshistorik.
Lager 3: Verksamhetsverktyg
Strukturerat arbete utan fragmentering mellan verktyg.
Teknisk grund
Byggt på beprövad öppen källkod.
Hubs paketerar etablerade öppen källkods-komponenter i en sammanhållen arbetsyta, anpassad för svenska krav och offentlig sektors verklighet.
Etablerade komponenter
Plattformen bygger på en öppen samarbetskärna och etablerade öppen källkodskomponenter — bland andra Collabora Online, Moodle, OpenProject och Vaultwarden — samt realtidskommunikation (Hubs Meet). Office-modulen bygger på Collabora Online, Lärplattformen på Moodle och projekthanteringen på OpenProject.
Full insyn, ingen inlåsning
Öppen källkod ger full transparens och möjlighet för er organisation att granska, anpassa och bygga vidare — utan att vara beroende av en enskild leverantörs produktbeslut.
En sammanhållen arbetsyta
Hubs är inte en lös samling verktyg utan en arbetsyta med integrerat stöd för identitet, behörighet, kommunikation och dokument.
Bärande komponenter.
Tabellen sammanfattar plattformens bärande komponenter. Versionerna anges på huvudversionsnivå; samtliga komponenter är versionspinnade och uppdateras genom granskade, testade releaser — aldrig genom löpande direktändringar.
| Funktion | Komponent | Ursprung och licens | ITSL:s roll |
|---|---|---|---|
| Samarbetsplattform (kärnan) | Öppen samarbetsplattform (v31) | Öppen källkod (GNU AGPL v3) | Härdad, versionsstyrd bas — kärnan hålls opatchad, anpassningar levereras som separata appar och ett litet antal granskningsbara patchar. |
| Webbfront och TLS | nginx och Apache httpd | Öppen källkod | Instansens enda publika ingång för webbtrafik: TLS 1.2/1.3, tvingad HTTPS och automatiserad certifikathantering, med stöd för kundegna certifikat. |
| Databas | PostgreSQL 17 | Öppen källkod | Paketeras och versionspinnas; en dedikerad databas per kundinstans. |
| Cache och sessioner | Redis 7 | Öppen källkod | Paketeras och versionspinnas; dedikerad per kundinstans. |
| Dokumentredigering | Collabora Online | Öppen källkod | Integreras i filhanteringen och körs som egen, härdad tjänst i instansen. |
| Möten och chatt | Realtidskommunikation (Hubs Meet) med TURN/TURNS-relä | Öppen källkod | Förvaltas med egna, granskningsbara ändringar ovanpå versionspinnad uppströmskod. |
| Lösenordshanterare | Vaultwarden | Öppen källkod (GNU AGPL v3) | Paketeras och versionspinnas; körs som egen tjänst per kundinstans. Fristående projekt, ej associerat med Bitwarden, Inc. |
| Fulltextsökning | Elasticsearch | Öppen källkod | Körs på instansens interna nät och exponeras aldrig publikt. |
| Antivirus | ClamAV | Öppen källkod | Skannar uppladdade filer; åtgärd vid fynd är konfigurerbar per kund. |
| Meddelandetransport | Postfix och Dovecot | Öppen källkod | Intern transport under pseudodomäner som aldrig routas mot internet. |
| Meddelandeklient och SDK-koppling | Meddelandeklient, mellanprogramvara samt meddelandetjänst och accesspunkt | Egenutvecklat; meddelandetjänst och accesspunkt är en tredjepartsprodukt | Utvecklar och förvaltar klient och mellanprogramvara; tredjepartsprodukten ingår i leveranskedjan men utvecklas inte av ITSL. |
| E-legitimation och provisionering | eID-inloggning och SCIM-app | Öppen källkod med ITSL-anpassningar | Anpassas och förvaltas av ITSL för svensk e-legitimation och automatisk kontoprovisionering. |
Livscykel och versioner.
Hubs förvaltas enligt en levande fork-modell: plattformskärnan hålls opatchad och synkroniseras dagligen mot uppströmsprojektet, medan ITSL:s anpassningar ligger isolerade som separata appar och granskningsbara patchar. Varje ändring granskas av minst en ytterligare utvecklare innan den godkänns, och varje release motsvarar en exakt, reproducerbar komponentuppsättning.
| Ändringstyp | Åtagande |
|---|---|
| Säkerhetsrättelser uppströms | Fångas upp i det dagliga synkflödet mot uppströmsprojektet och tas in via obligatorisk kodgranskning och automatiska tester. |
| Kritiska säkerhetspatchar | Byggs och rullas ut skyndsamt genom den ordinarie byggkedjan, med målsättningen 24 timmar. |
| Operativsystemens säkerhetsuppdateringar | Installeras veckovis och automatiserat; säkerhetskopiering genomförs före större ändringar. |
| Plattformsuppgraderingar | Granskade, testade releaser som verifieras i QA-miljö och görs tillgängliga i er demomiljö före produktion — ni får en ändringslogg och kan begära att en uppgradering skjuts upp. |
Driftmodeller
Tre driftmodeller — ni bestämmer var era data lagras.
Valet styrs av era krav på kontroll, isolering och flexibilitet. Modellerna kan kombineras utifrån informationsklass.
| Driftmodell | Var era data lagras | Kännetecken | Passar när |
|---|---|---|---|
| Svensk molndrift | I Sverige — två geografiskt skilda datahallar i Stockholmsregionen. | Tier 3-klassade anläggningar med redundant kraft, kyla och nätförbindelse; drift och övervakning dygnet runt. | Ni vill komma igång snabbt med svensk drift, utan att bygga egen infrastruktur. |
| Lokal installation | I er egen infrastruktur. | Komplett kontroll och hög isolering. | Kraven på isolering, egen kontroll och styrning väger tyngst. |
| Hybrid | Uppdelat — olika delar kan driftas olika. | Stegvis migrering; driftmodeller blandas utifrån informationsklasser och mognad. | Olika informationsklasser behöver olika driftmodell, eller migreringen ska ske stegvis. |
Kapacitet och skalning.
Kapaciteten dimensioneras per kundinstans: varje kund har dedikerade processor-, minnes- och lagringsresurser, och varje tjänst i instansen har egna resurstak som hindrar att en enskild komponent tränger ut övriga. När nyttjandet närmar sig cirka 80 procent av tilldelad kapacitet byggs resurserna ut proaktivt — och eftersom resurserna är dedikerade påverkas inga andra kundinstanser. Plattformen skalar per kundinstans: varje ny organisation får en egen, fristående instans, utan gemensamma flaskhalsar i applikations- eller datalagret.
Ansvarsfördelning vid svensk molndrift.
Tabellen visar hur ansvaret fördelas i driftmodellen svensk molndrift. Vid lokal installation och hybrid definieras ansvarsfördelningen i avtal. En avtalsmässig sammanfattning finns under Avtal och villkor.
| Område | ITSL | Er organisation |
|---|---|---|
| Patchning och sårbarhetsåtgärd | Bevakar omvärlden (bland annat CERT-SE, MSB och CVE-flöden), bygger, testar och rullar ut rättningar genom den ordinarie byggkedjan. | Ingen åtgärd krävs. |
| Uppgradering | Levererar granskade, testade releaser; nya versioner görs tillgängliga i er demomiljö före produktion, med ändringslogg. | Kan verifiera i demomiljön och begära att en uppgradering skjuts upp. |
| Säkerhetskopiering | Krypterade kopior i flera generationer till en åtskild backupmiljö; genomförandet verifieras dagligen och återläsningstester görs regelbundet. | Ingen åtgärd krävs. |
| Övervakning | Övervakar dygnet runt med automatiska larm till jourhavande tekniker, kompletterat med extern säkerhetsövervakning. | Ingen åtgärd krävs. |
| Incidenthantering | Dokumenterad process med eskalering till informationssäkerhetsansvarig, rotorsaksanalys och incidentrapport; vid personuppgiftsincident lämnas underlag skyndsamt så att ni kan fullgöra er anmälningsskyldighet inom 72 timmar enligt GDPR. | Ni är personuppgiftsansvariga och ansvarar för anmälan till IMY; ni informeras enligt avtal. |
| Administration av er instans | Förvaltar instansen som versionshanterad konfiguration, med ändringslogg per instans. | Styr själva behörigheter, gallringstider, krav på tillitsnivå vid inloggning och integrationer via administrationsgränssnittet. |
Identitet
Identiteten kopplas till er befintliga miljö.
Hubs bygger inte en egen identitetssilo. Plattformen använder era befintliga identiteter och svenska e-legitimationer — stark autentisering är en central del av offentlig sektors verkliga kravbild, för både intern och extern åtkomst.
Identitet och inloggning
Federerad identitet med stark autentisering i alla flöden — protokoll för protokoll.
- E-legitimation via förmedlingstjänst: BankID, SITHS för vård och omsorg samt Freja eID
- Federerad inloggning (SSO) mot er egen identitetsleverantör (IdP) via OIDC — SAML 2.0 ansluts via federationsbroker, och er egen MFA-policy gäller
- Automatisk kontoprovisionering via SCIM 2.0, kompletterad med regelbunden avstämning mot Microsoft Graph som fångar inaktiveringar och gruppändringar
- Katalogsynkronisering via LDAPS mot ert Active Directory genom krypterad tunnel
- Gruppstyrda behörigheter — behörighet som tas bort i er katalog slår igenom i Hubs
- Inbyggt stöd för WebAuthn
Anslutningar
Två anslutningar utåt: SDK och Teams Bridge.
Arkitekturen har två definierade vägar ut ur den egna miljön — båda med tydligt syfte och tydlig avgränsning.
SDK-accesspunkten
Hubs innehåller både meddelandeklient och meddelandetjänst för säker digital kommunikation (SDK) — spårbar, standardiserad myndighetspost mellan offentliga aktörer via DIGG:s ramverk, med automatisk spårbarhet, kvittens och ärendelogg.
Teams Bridge mot Microsoft 365
Teams Bridge låter medarbetare boka och delta i Hubs säkra möten direkt från Outlook och få notiser om Hubs-händelser i Teams. Det som passerar Microsofts moln är mötesinbjudningar (tid, titel, deltagare och möteslänk) samt kortfattade notistexter med länk — dokument, filer och mötesströmmar ligger kvar i Hubs.
Säkerhet
Säkerhetsarkitektur i sammandrag.
Kryptering och åtkomstkontroll är inbyggda i modulerna, inte tillägg. Här är de säkerhetsegenskaper som är del av plattformens arkitektur.
Inbyggda säkerhetsegenskaper
- End-to-end-kryptering som standard i modulen Meddelanden
- Server-side-kryptering och valfri end-to-end-kryptering i filhanteringen
- Krypterad grupp- och enskild chatt samt videomöten utan externa tredjepartstjänster
- Granulära behörigheter med roller, grupper och fullständig versionshistorik
- All AI-bearbetning sker i ITSL:s egna datacenter i Sverige, på ITSL:s GPU:er, 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ö.
- Automatisk spårbarhet och kvittens i SDK-flöden
Avgränsningar
Vad Hubs inte är.
En arkitekturbedömning kräver tydlighet även om gränserna. Fyra avgränsningar som hör till bilden.
Ingen funktionskopia av Microsoft 365
Hubs är inte en avskalad kopia av Microsoft 365 — det är en annan arkitektur för andra krav, där kontroll över data och drift är utgångspunkten.
Ingen egen identitetslösning
Hubs ersätter inte er identitetshantering. Plattformen kopplas mot befintlig IdP och svenska e-legitimationer i stället för att bygga en parallell katalog.
Inget krav på helhetsinförande
Ni måste inte införa hela plattformen på en gång. Hubs införs modulärt, och driftmodellerna kan blandas — arkitekturen förutsätter inte ett totalbyte dag ett.
Utanför leveransen
Drift av er IdP och katalogtjänst, era klientenheter samt er nätaccess ligger utanför systemgränsen — med undantag för den krypterade tunnel som etableras för katalogåtkomsten. En IdP kan initialt tillhandahållas av ITSL och senare flyttas till er egen.
Gå igenom arkitekturen mot er miljö.
Boka en teknisk genomgång där vi går igenom lager, driftmodeller, identitet och anslutningar utifrån era förutsättningar — med en lösningsarkitekt, inte en säljpresentation.