Att ha härdat sina Kubernetes-kluster är bra. Att kunna visa det är det som räknas när tillsynsmyndigheten hör av sig. Cybersäkerhetslagen (2025:1506) kräver säkerhetsåtgärder, och sedan den 1 oktober 2026 preciserar föreskrifterna MCFFS 2026:11 vad de ska innehålla. Ingen av dem nämner Kubernetes, men nästan varje paragraf landar i klustret.
Den här artikeln går igenom hur du gör Kubernetes-härdning till bevis som håller vid tillsyn: vilka krav i lag och föreskrift som berör plattformen, hur CIS Benchmark, policyer och audit-loggar fungerar som underlag, och vilka artefakter du bör kunna ta fram på en eftermiddag.
Har du frågor om ämnet? Tveka inte att höra av dig till oss!
Det här är en teknisk genomgång och inte juridisk rådgivning. Om du är osäker på om er verksamhet omfattas, ta hjälp av en jurist. De juridiska uppgifterna är kontrollerade den 19 oktober 2026.
Av Johan Kuylenstierna, VD Agency 42 · Senast granskad 19 oktober 2026
Varför "bevis" och inte bara "härdning"?
Enligt 3 kap. 3 § cybersäkerhetslagen ska den som står under tillsyn på begäran lämna de uppgifter och handlingar som behövs. Tillsynsmyndigheten får göra regelbundna säkerhetsrevisioner av väsentliga verksamhetsutövare (3 kap. 5 §), riktade revisioner om det finns särskilda skäl (6 §) och säkerhetsskanningar i samarbete med er (7 §). För viktiga verksamhetsutövare sker tillsynen i efterhand, när myndigheten har anledning att anta att reglerna inte följs (3 kap. 2 §).
Tänk på det som bokföring. Ett företag kan ha betalat varenda faktura i tid, men utan verifikationer går det inte att visa för revisorn. Säkerhetsåtgärder fungerar likadant. En hårdare kluster-konfiguration utan spårbara resultat, versioner och datum är en känsla, inte ett bevis.
Vilka krav landar i klustret?
Lagens 2 kap. 3 § räknar upp tio områden som säkerhetsåtgärderna åtminstone ska omfatta. Fyra av dem är rena plattformsfrågor: säkerhet vid förvärv, utveckling och underhåll (punkt 5), bedömning av åtgärdernas effektivitet (punkt 6), cyberhygien (punkt 7) och åtkomstkontroll och tillgångsförvaltning (punkt 9). Hur lagen fungerar i stort har vi gått igenom i Cybersäkerhetslagen för dig som driftar plattformen.
MCFFS 2026:11 gör det konkret. Några av kraven i 4 kap. översatta till Kubernetes:
| Krav i MCFFS 2026:11 | Vad det betyder i klustret |
|---|---|
| 4 kap. 9 § förteckning över den digitala miljön | Inventering av kluster, versioner, namespaces, ägare och leverantörer |
| 4 kap. 11 § segmentering, bara godkända flöden | NetworkPolicies med default deny, separata kluster eller nodpooler för känsliga system |
| 4 kap. 13 § säkerhetskonfigurering | Härdning enligt leverantörens rekommendationer och standarder, till exempel CIS; inga onödiga funktioner |
| 4 kap. 16–17 §§ minsta behörighet och MFA för administratörer | RBAC utan breda cluster-admin-roller, SSO med MFA för kubectl och konsoler |
| 4 kap. 21–22 §§ säkerhetsloggning och logganalys | API-serverns audit-logg, centralt insamlad och analyserad |
| 4 kap. 23 § robust och korrekt tid | NTP på alla noder, spårbar till UTC(SP), så att loggar går att jämföra |
| 4 kap. 27 § säkerhetstester | Kontroll av senaste godkända version, åtgärdade sårbarheter och att vald konfiguration faktiskt gäller |
| 4 kap. 30–31 §§ ändringshantering och säkerhetsuppdateringar | GitOps-historik, uppgraderingsplan och patchrutin |
Två saker är viktiga att känna till:
- Allmänna råd är inte tvingande. Föreskrifterna innehåller både krav ("ska") och allmänna råd ("bör"). Ett exempel på ett råd är att börja införa en säkerhetsuppdatering inom 72 timmar efter att den blivit tillgänglig (allmänt råd till 4 kap. 31 §). Det är inget lagkrav, men det är en tydlig fingervisning om vad myndigheten förväntar sig.
- Alla omfattas inte av samma föreskrifter. Enligt 1 kap. 1 § gäller MCFFS 2026:11 bara kraven på ledningens utbildning för verksamhetsutövare som uteslutande verkar inom bland annat digital infrastruktur, digitala leverantörer och förvaltning av IKT-tjänster mellan företag. För till exempel moln- och datacenterleverantörer och MSP:er gäller i stället de tekniska kraven i EU:s genomförandeförordning (EU) 2024/2690. Plattformsarbetet blir ungefär detsamma, men hänvisningarna i er dokumentation blir andra.
Fem bevis som klustret kan producera själv
1. CIS Benchmark-resultat, med datum och version
CIS Kubernetes Benchmark är en allmänt använd standard för säkerhetskonfiguration och passar bra in i 4 kap. 13 §. Kör kontrollerna automatiskt, till exempel med kube-bench, med den inbyggda CIS-profilen i RKE2 eller med Compliance Operator (som bygger på OpenSCAP) i OpenShift. Det viktiga för bevisvärdet:
- spara resultatet per kluster och datum, maskinläsbart,
- dokumentera avsteg med motivering och beslutsfattare, eftersom ett "fail" med en godkänd motivering är bättre än ett "pass" ingen förstår,
- kör om efter varje uppgradering, eftersom resultatet gäller den version ni faktiskt kör.
Samma tänk gäller noderna. Härdning av operativsystemet med OpenSCAP och CIS- eller DISA STIG-profiler ger rapporter av samma typ. Mer om det på Linux.
2. Policyer som kod, och rapporter om vad de stoppat
Det räcker inte att skriva i en policy att containrar inte får köras som root. Det ska vara omöjligt att göra fel.
- Slå på Pod Security Admission med nivån
restricted(eller minstbaseline) per namespace. Det är en etikett på namnrymden:
kubectl label namespace betalning pod-security.kubernetes.io/enforce=restricted
En pod som till exempel saknar runAsNonRoot eller inte släpper alla capabilities avvisas då direkt av API-servern.
- PodSecurityPolicy togs bort i Kubernetes 1.25, så har ni fortfarande gamla PSP:er i dokumentationen är det dags att städa.
- Använd Kyverno eller OPA Gatekeeper för regler som Kubernetes inte har inbyggt: tillåtna register, krav på signerade images, obligatoriska resursgränser och etiketter för ägare.
- Spara policyrapporterna. Varje avvisad deployment är ett bevis på att kontrollen fungerar, och samlade rapporter visar effekten över tid (2 kap. 3 § punkt 6).
3. Audit-loggar som går att läsa i efterhand
API-serverns audit-logg är klustrets kvittorulle: vem gjorde vad, mot vilken resurs och när. Den täcker flera av punkterna i 4 kap. 21 §, till exempel användning av administrativ behörighet och ändrade behörigheter. Ett enkelt utgångsläge för en audit-policy:
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
- level: Metadata
resources:
- group: ""
resources: ["secrets", "configmaps"]
- level: RequestResponse
resources:
- group: "rbac.authorization.k8s.io"
- level: Metadata
Reglerna läses uppifrån och första träffen gäller. Hemligheter loggas bara på metadatanivå, så att innehållet inte hamnar i loggen. RBAC-ändringar loggas i sin helhet. Skicka loggen till ett centralt system utanför klustret (allmänt råd till 4 kap. 22 §), skydda den mot ändringar och kryptera den under överföring, vilket 4 kap. 25 § kräver för säkerhetsloggar.
4. Ändringshistorik i Git
Med GitOps, till exempel Argo CD eller Flux, blir Git själva ändringsloggen. Varje ändring har en författare, en granskare, ett datum och en motivering. Det är strukturerad och spårbar ändringshantering enligt 4 kap. 30 § utan att någon behöver fylla i ett extra formulär. Det är också så ni upptäcker configuration drift, när klustret inte längre ser ut som det som står i Git.
5. Version och patchstatus per kluster
4 kap. 27 § kräver säkerhetstester som visar att systemen är uppdaterade till senaste godkända version och att publicerade sårbarheter är omhändertagna. För plattformen betyder det:
- en lista över varje kluster med Kubernetes-version, distribution och supportstatus,
- skanningsresultat för images som körs i produktion, till exempel från Trivy,
- en plan för kluster som närmar sig end of life. Programvara utan säkerhetsuppdateringar ska bytas ut eller uppgraderas utan onödigt dröjsmål (4 kap. 31 §).
Bevispaketet: det här ska du kunna ta fram på en eftermiddag
Vår tumregel: om tillsynsmyndigheten ringer på måndag ska du kunna skicka följande innan fredag, utan att någon behöver jobba natt. Svaret på livet, universum och allting är kanske 42, men svaret på "visa er härdning" bör vara en mapp.
- Förteckning över kluster, versioner, ägare och leverantörer.
- Senaste CIS-resultat per kluster, med dokumenterade avsteg.
- Aktiva policyer, exporterade från Git, och policyrapporter för de senaste tre månaderna.
- Audit-policy och exempel på analys av audit-loggen (larm, utredda händelser).
- RBAC-översikt: vem har cluster-admin, och varför.
- Ändringslogg och uppgraderingshistorik.
- Patch- och sårbarhetsstatus för images i produktion.
- Senaste uppföljningen av säkerhetsåtgärderna. För sektorskritiska system ska den göras minst en gång per år (MCFFS 2026:11, 3 kap. 19 §).
AI kan hjälpa till att sammanställa paketet, sammanfatta loggar och hitta luckor. Men det är en människa som granskar, bedömer och står för underlaget. Det är också den personen som ska kunna förklara det för ledningen, som enligt 2 kap. 4 § ska ha utbildning om säkerhetsåtgärderna.
Sammanfattning
- Cybersäkerhetslagen kräver säkerhetsåtgärder (2 kap. 3 §) och ger tillsynsmyndigheten rätt att begära handlingar, göra revisioner och skanna (3 kap.).
- MCFFS 2026:11 gäller sedan 1 oktober 2026 och ställer konkreta krav på bland annat konfigurering, behörigheter, loggning, tid, säkerhetstester och ändringshantering. Moln-, datacenter- och IKT-leverantörer följer i stället (EU) 2024/2690 för de tekniska kraven.
- Gör härdningen mätbar: CIS-resultat, policyrapporter, audit-loggar, Git-historik och patchstatus.
- Samla allt i ett bevispaket som byggs löpande, inte natten före revisionen.
Du ska prioritera det här nu om:
- ni omfattas av cybersäkerhetslagen och kör produktion på Kubernetes,
- ni inte vet vem som har cluster-admin i alla kluster i dag,
- audit-loggen inte är påslagen, eller bara sparas inne i klustret.
Vanliga frågor
Nämner cybersäkerhetslagen Kubernetes?
Nej. Lagen och föreskrifterna är teknikneutrala. Kraven på konfigurering, behörigheter, loggning och ändringshantering gäller ändå alla system som bär tjänsten, och där ingår klustret.
Måste vi följa CIS Kubernetes Benchmark?
Inte uttryckligen. MCFFS 2026:11 säger i ett allmänt råd att leverantörens rekommendationer och relevanta standarder bör användas vid säkerhetskonfigurering. CIS är ett etablerat och lätt mätbart sätt att visa det.
Måste säkerhetsuppdateringar installeras inom 72 timmar?
Lagkravet är att de ska genomföras skyndsamt (4 kap. 31 §). Att påbörja arbetet inom 72 timmar är ett allmänt råd, alltså en rekommendation och inte ett krav.
Hur länge ska audit-loggar sparas?
Föreskrifterna anger ingen fast tid. Säkerhetsloggar ska sparas så länge de behövs för att kunna utreda brister i cybersäkerheten (4 kap. 21 §). Bestäm en tid utifrån er riskanalys och dokumentera beslutet.
Gäller MCFFS 2026:11 för oss som molnleverantör?
Bara kravet på ledningens utbildning, om ni uteslutande verkar inom till exempel digital infrastruktur eller IKT-tjänster mellan företag. De tekniska kraven finns för er i genomförandeförordningen (EU) 2024/2690.
Kan tillsynsmyndigheten skanna våra kluster?
Den får genomföra säkerhetsskanningar hos den som står under tillsyn, i samarbete med verksamhetsutövaren (3 kap. 7 §).
Vill du ha hjälp att göra er Kubernetes-plattform redo för tillsyn?
Vi är Sveriges go-to-specialister på Kubernetes och arbetar med härdning, policyer, DevSecOps och drift i reglerade miljöer. Vi har erfarenhet från plattformsdrift i försvarssektorn och har gjort uppdrag för danska myndigheter, bland annat Forsvaret och tidigare Skattestyrelsen.
Vi börjar gärna med en GAP-analys mot NIS2, cybersäkerhetslagen och, om ni tillverkar produkter, CRA. Ni får en bild av var plattformen står i dag och en prioriterad lista över vad som behöver göras. Kontakta oss för offert eller ett första tekniskt samtal.
Läs mer på:
- Compliance: NIS2 och CRA
- Kubernetes
- SUSE Rancher
- DevOps och DevSecOps
- Kundcase
- SBOM enligt CRA: format, djup och arkivering i CI
- Kontakta oss
Källor
Alla kontrollerade 2026-10-19.
- Cybersäkerhetslag (2025:1506), utfärdad 2025-12-11, i kraft 2026-01-15. Särskilt 2 kap. 3–4 §§ och 3 kap. 2–8 §§. riksdagen.se
- MCFFS 2026:11, Myndigheten för civilt försvars föreskrifter och allmänna råd om säkerhetsåtgärder och ledningens utbildning för väsentliga och viktiga verksamhetsutövare, beslutade 2026-06-15, i kraft 2026-10-01 (förvaltas av FRA/NCSC sedan 2026-07-01). Särskilt 1 kap. 1 §, 3 kap. 19 § och 4 kap. 9–31 §§. ncsc.se
- NCSC, "Föreskrifter om säkerhetsåtgärder träder i kraft", 2026-10-01. ncsc.se
- Kommissionens genomförandeförordning (EU) 2024/2690. eur-lex.europa.eu
- Direktiv (EU) 2022/2555 (NIS2). eur-lex.europa.eu
- Kubernetes-dokumentationen: Pod Security Admission och Auditing. kubernetes.io
- Center for Internet Security, CIS Kubernetes Benchmark. cisecurity.org
