Säkerhet

1. Övergripande principer

CyberKlar är byggd enligt principerna secure-by-default, least privilege och defence-in-depth. Vi driver en av de mindre komplexa plattformarna på marknaden med avsikt, för att hålla nere antalet tjänster, integrationer och säkerhetshål som behöver underhållas. Om ni köper av oss ska ni inte behöva oroa er för att vi själva blir attackvektorn.

2. Datalagring och kryptering

• At rest. All persistent data är krypterad med AES-256. Databasen hos Supabase ligger i Irland (eu-west-1, EU) och backupperna är krypterade.
• In transit. TLS 1.2 och 1.3 accepteras på alla publika endpoints (Google Frontend-policy). HSTS är aktivt med preload (max-age=63072000; includeSubDomains; preload).
• Secrets. API-nycklar och autentiseringstokens lagras i Google Secret Manager och monteras som miljövariabler i Cloud Run vid körning. Inga hemligheter checkas in i git och ingen mänsklig operatör har direkt databasåtkomst i produktion.

3. Drift och infrastruktur

• Hosting. Google Cloud Run i region europe-north1 (Finland). All kundtrafik termineras på Google Frontend som dessutom agerar DDoS-skydd.
• Databas. Supabase managed PostgreSQL, region eu-west-1 (Irland). Row Level Security är aktiverat på alla tabeller. Säkerhetskritiska operationer går via service-role-nyckel som enbart används server-side.
• Nätverk. Content Security Policy med explicit tredjeparts-allowlist (Stripe, Clerk, Google Fonts) och Permissions-Policy som stänger kamera, mikrofon och geolocation. Hela listan går att inspektera via curl -I https://cyberklar.se.
• MCP-tjänster. Två separata Cloud Run- tjänster i samma region (europe-north1, Finland): mcp.cyberklar.se (publik, anonym, read-only) och mcp-app.cyberklar.se (autentiserad, tenant-scopad). Båda är CyberKlars egna tjänster, inte tredjepart, men en separat infrastruktur-yta med egen attackmodell. Auth- och rate-limit-detaljer finns i avsnitt 5.

4. Autentisering och åtkomstkontroll

• Användaridentitet. Clerk är vår identitetspartner. Clerk tillhandahåller MFA, SSO (Google OAuth idag, SAML för Enterprise), sessionshantering och lösenordsåterställning. Clerk-inloggningssessioner signeras med JWKS-nycklar som roteras regelbundet.
• Plattformsbehörigheter. Roller (administratör, användare, revisor) kontrolleras i databasen via RLS. Kundens data är logiskt separerad per organisation.
• Administrativ åtkomst. CyberKlar-personal har inte tillgång till kunddata i produktion. När support behöver felsöka sker det med kundens skriftliga medgivande och spåras i revisionsloggen.

5. AI-assistent-åtkomst (MCP)

CyberKlar exponerar två separata MCP-servrar (Model Context Protocol) för AI-klienter som Claude Desktop, ChatGPT, Cursor och egen agent. De har olika auth-modeller och olika attackytor. Läs mer om hur ni ansluter en AI-assistent.

5.1 Publik MCP-server (mcp.cyberklar.se)

• Anonym. Ingen autentisering, ingen inloggning.
• Anropstakten är begränsad per IP-adress, så att servern förblir öppen för alla. Överskridande besvaras med 429 Too Many Requests och Retry-After.
• Inga anrop loggas. Varken frågor, innehåll, IP-adresser, klientidentitet eller sessioner sparas.
• Inget sparas mellan anrop. Servern har ingen databas och ingen användardata.
• En anonym räknare över verktygsnamn och statuskod används för kapacitetsplanering. Inget annat.

5.2 Autentiserad MCP-server (mcp-app.cyberklar.se)

• Endast API-nyckel accepteras. En inloggad sessionskaka avvisas.
• Varje anrop är låst till nyckelns organisation. Ett anrop som pekar på en post hos någon annan besvaras med not_found, oavsett om posten finns.
• Behörigheten sätts per område och riktning, och prövas vid varje anrop. En nyckel utan rätt behörighet får forbidden. En återkallad nyckel får unauthorized.
• Anropstakten är begränsad per nyckel. Gällande gräns och återstående kvot returneras i svarshuvudena, så att er integration kan anpassa sig utan att gissa.
• Revisionsloggen registrerar varje skrivande anrop: vad som gjordes, när och av vilken nyckel. Innehållet i anropet loggas inte i sin helhet.
• Nyckelns hemliga del visas en gång när den skapas och kan inte hämtas fram i efterhand. Återkallning gäller direkt vid nästa anrop, och nyckeln försvinner inte ur revisionsloggen.
• Hela nyckeln hamnar aldrig i någon logg.
• Sökvägar till dokument valideras innan de används, så att ett anrop inte kan ta sig utanför den egna organisationens filer.
• Planerat: OAuth 2.1 med Dynamic Client Registration. Tills dess är API-nyckel den enda vägen in.

6. Backup och återställning

• Dagliga automatiska backups hos Supabase med sju dagars lagringstid. Backupperna är krypterade och lagras inom EU.
• RTO (recovery time objective) på fyra timmar för applikationen, tolv timmar för en full databasåterställning.
• RPO (recovery point objective): maximalt 24 timmar mellan backup-cykler. Point-in-Time Recovery (PITR) för fem- minuters-RPO finns som betalt tillägg och aktiveras vid kundbehov.

7. Utveckling och leveranskedja

• All kod versionshanteras i GitHub med obligatorisk code-review innan merge till main.
• Alla produktionsbyggen körs via GitHub Actions med federerad identitet mot Google Cloud. Inga långlivade nyckelfiler finns i byggkedjan.
• Beroenden skannas automatiskt för kända sårbarheter via GitHub Dependabot och npm audit i CI.
• Varje release är taggad med commit SHA och är reversibel via gcloud run services update-traffic.

8. Vår egen NIS2-posture

Vi använder CyberKlar själva för att hantera vårt compliance-arbete. Plattformen är Mindverk AB:s enda produkt och vi är en väsentlig leverantör till flera av våra kunder. Därför tar vi kedjesäkerhet på allvar och har implementerat de kontroller i Art. 21(2) a, j som gäller för oss trots vår storlek.

9. Incidenthantering

Vid säkerhetsincidenter som kan påverka kunddata följer vi GDPR art. 33 (72 h) och Cybersäkerhetslagens rapporteringstidslinje. Berörda kunder informeras via e-post till kontoadministratörer och status-uppdateringar publiceras löpande. Rapportera misstänkta sårbarheter till security@cyberklar.se. Vi svarar inom 24 timmar.

10. Sub-processors

Primär datalagring sker inom EU. Viss databehandling av underbiträden (autentisering, AI-analys, e-post) kan ske utanför EU med stöd av EU-kommissionens beslut om adekvat skyddsnivå eller standardavtalsklausuler. En uppdaterad lista över sub-processors med geografisk placering finns i vår DPA. Ändringar kommuniceras till administratörer minst 30 dagar i förväg.

11. Användning av stora språkmodeller (LLM)

Plattformen använder externa språkmodeller för specifika, avgränsade arbetsmoment. Vi är medvetna om att frågan “vad skickas till OpenAI och Anthropic?” är en av de första som ställs i RFP från banker, energi och vård. Här är hur det fungerar i praktiken:

För en CISO-djupdykning: en separat sida /ai-transparens svarar strukturerat på vad agenten gör, vad människan alltid beslutar, hur fel-output upptäcks, hur prompten revideras och vem som bär ansvaret vid fel AI-förslag. Den här sektionen täcker de tekniska detaljerna.

11.1 Vilka leverantörer

• Anthropic. Används för NIS2-samordnaren (nattlig analys av regelförändringar och förslagsgenerering), den interaktiva produktdemon på /demo och regelbevakning. Modeller: Claude Sonnet och Claude Haiku. Anthropic är amerikansk leverantör med EU-residency för Bedrock-via-AWS-rutten; vi använder direkta Anthropic-API:et med standardavtalsklausuler (SCC) som rättslig grund för överföring till tredjeland.
• OpenAI. Används idag för enstaka förslagsfunktioner i plattformen (gap-analys-utkast, policy-utkast, riskrekommendationer, BCP-utkast). Modell: gpt-4o. OpenAI är amerikansk leverantör med SCC som rättslig grund. Vi planerar att flytta dessa flöden till Anthropic under 2026 för att minska antalet tredjelandsbiträden.

Den fullständiga och alltid aktuella listan över alla underbiträden finns i vårt Personuppgiftsbiträdesavtal.

11.2 Var i flödet LLM används, och var det är deterministisk logik

LLM används endast för förslag och formulering. Allt som påverkar Kundens riskregister, policyer, åtgärdskö eller incidentrapporter går via en deterministisk verifieringskod och kräver att en namngiven användare aktivt godkänner förslaget.

• Deterministisk logik. Klassificering av incidenttyp, mappning av Cybersäkerhetslagens artiklar (Art. 21 a till j och motsvarande), AI-systemklassning (Annex III), kontroll av deadlines, schemaläggning av nattliga jobb, tidsstämpling och hash-beräkning på audit-log-snapshots samt PDF-generering.
• LLM-genererat (utkast som kräver godkännande). Förslag på åtgärder, utkast till policytext, styrelsebrev, gap-analys-formulering och förslag på incidenttext.

Inga ändringar mot tillsynsmyndighet, mot NCSC eller i Kundens dokumenterade ledningsbeslut görs av en LLM. En människa måste alltid trycka godkänn, och det godkännandet loggas append-only.

11.3 Vad får skickas, och vad får inte skickas

• Råa personuppgifter skickas inte till LLM utan föregående pseudonymisering. Namn, personnummer, kontaktuppgifter och fritextfält där sådant kan förekomma ersätts med deterministiska tokens (till exempel [PERSON_1]) innan de når modellen.
• Strukturerad metadata (artikelreferenser, kontrollkoder, statusfält, tidsstämplar) får skickas i klartext eftersom det inte utgör personuppgifter eller affärshemligheter.
• Säkerhetsrelaterad fritext från Kundens incidentbeskrivningar pseudonymiseras innan utkast genereras. Ursprungstexten ligger kvar i Supabase i Irland och skickas inte vidare.

11.4 Träning och datalagring hos leverantören

Vi har avtalat att Kundens prompts och svar inte används för att träna leverantörens modeller. Det följer av Anthropics och OpenAI:s standardvillkor för API-användning (i motsats till konsumentprodukten ChatGPT) och är kontraktuellt bekräftat i bägge avtal.

Anthropic och OpenAI behåller API-trafik i upp till 30 dagar för missbrukshantering, varefter den raderas. Inga kunddata pseudonymiserade eller ej skickas till någon tredje part bortom den anlitade modellleverantören.

11.5 Loggning hos oss

Varje LLM-anrop loggas i Kundens organisation med tidsstämpel, modell-id, input- och output-tokens samt kostnad i euro. Loggen är synlig för administratörer i plattformen under Inställningar → AI-användning och utgör en deterministisk grund för att svara på CISO-frågan “vad har skickats till en LLM?”.

12. Färdplan för säkerhetscertifieringar

CyberKlar är ett ungt bolag och har ännu inte genomgått en extern revision. Vår arkitektur följer ISO 27001:2022 Annex A-kontrollerna och vi har en publik plan för att verifiera det externt. Vi är ärliga om att en publicerad färdplan är värd mer än ett vagt “vi siktar på det”:

• Q3 2026. Initiering av SOC 2 Type II observationsperiod med extern revisor. Kontrollurval och policy-grundnivå färdigställs under perioden.
• Q1 2027. Estimerad SOC 2 Type II-rapport tillgänglig under NDA. Rapporten omfattar Security, Availability och Confidentiality.
• Q3 2027. ISO 27001-evaluering inleds med ackrediterad certifieringsorgan. Mål: certifikat under 2028.

12.1 Kryptografisk PDF-signering (PAdES / eIDAS QES)

Idag är granskningsloggen append-only på databasnivå (trigger blockerar UPDATE och DELETE) och PDF-export förses med tidsstämpel och en kryptografisk hash av den underliggande snapshot-raden. PDF-filen i sig är inte digitalt signerad med X.509-certifikat eller PAdES idag, bevisvärdet kommer från databasens append-only-rad och hash-referensen i PDF:en.

• Q4 2026. Hash-kedja över granskningsloggens rader, där varje rad bär en hash av den föregående, samt daglig signering. Spåras i DPA och i intern PRD för modulen för AI-förordningen (AI Act).
• Q2 2027. PAdES-signerad PDF-export via eIDAS-kvalificerad tjänst (Scrive QES eller motsvarande) med Digidentity-certifikat. Signering blir ett frivilligt val för Sprint-kunder och kunder med NIS2-samordnaren utan extra avgift.

Tills PAdES-signering är på plats är det kombinerade bevisvärdet av: (1) trigger-skyddad append-only-logg på databasnivå, (2) tidsstämpel i PDF-metadata och sidfot, (3) kryptografisk hash av snapshot-raden i PDF:en, vad som presenteras vid en tillsynsbegäran. Domstolsbevis i högre krav-nivå (eIDAS QES) tillkommer enligt tidsplanen ovan.

12.2 Asymmetrisk signering av kontrollbevisen (Cloud KMS)

Bevisobjekten från CyberKlar Controls nattliga tekniska kontroller kedjas per organisation (SHA-256, varje rad bär en hash av föregående) och kedjans huvud signeras varje natt med en asymmetrisk nyckel i Google Cloud KMS: EC P-256, algoritm EC_SIGN_P256_SHA256, giltig från 2026-07-20. Den privata nyckeln kan inte läsas ut ur driftmiljön, som endast kan begära signaturer. Exporterade bevispaket (zip med manifest, kedjerader, bevisobjekt och signaturer) verifieras därför av tredje part helt utan CyberKlar, offline med openssl eller med det öppna verifieringsverktyget verify-evidence-package.mjs.

Publicerad verifieringsnyckel: /.well-known/cyberklar-signing-key.pem. Vid nyckelrotation läggs nya nycklar till i filen och historiska nycklar behålls, så att äldre bevispaket förblir verifierbara. Garantin är att manipulation efter signering är upptäckbar av utomstående, inte att den är tekniskt omöjlig.

Tidsplanen kan förskjutas av kund- eller resursskäl. Vi uppdaterar denna sida och kommunicerar förändringar till befintliga Kunder via mejl. Ni som överväger upphandling kan hämta en uppdaterad statusrapport via support@cyberklar.se.

Tills certifikaten är på plats är denna sida, tillsammans med vårt DPA och vår SLA, vår ärliga trust-karta.

13. Vidare läsning

Den här sidan beskriver hur vi skyddar er data. Hur systemet är byggt, vilka underbiträden som anlitas och hur säkerheten granskas står samlat på förtroendesidan, som är den att skicka vidare till inköp eller CISO.

Ska ni koppla ett eget system mot plattformen, till exempel skicka in incidenter från ert SIEM eller läsa ut status till er egen rapportering, ligger det tekniska underlaget i utvecklardokumentationen. Där genereras den maskinläsbara specen ur den kod som körs, så den kan inte hamna ur fas med plattformen.