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, Cloudflare Turnstile, 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.
• Rate-limit på 60 requests per minut per IP-adress (sliding window, in-memory). Överskridande returnerar 429 Too Many Requests med Retry-After.
• Inga inputs loggas. Inga IP-adresser, inga user-agent- strängar och inga sessions-id sparas. Frågor och payloads lagras aldrig.
• Ingen state mellan requests. Servern har ingen databas och ingen användardata.
• Anonym usage-counter i minnet räknar tool-namn plus status-kod. Dumpas till stdout var 5:e minut. Inget annat.

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

• Bearer-token endast. Cookie-baserad sessionsauth avvisas explicit.
• Tenant-scopad query på organization_id för varje tool. Update- och delete-tools läser raden först, jämför organization_id mot nyckelns organisation och returnerar not_found om raden inte tillhör den.
• Scope-baserad behörighet med 14 scopes som mappar 1:1 mot tools. En nyckel utan rätt scope för det anropade verktyget får forbidden. Återkallad nyckel får unauthorized.
• Rate-limit på 600 requests per minut per api_key.id (token bucket).
• Audit-logg per skriv-tool i audit_log med actor_type=mcp_client, api_key_prefix, tool_name och request_id. Fältet details är begränsat till max 200 tecken per fält. Hela payloaden loggas inte.
• Plaintext-nyckel visas en gång vid skapandet och kan inte återhämtas. Återkallning sker via revoked_at i api_keys-tabellen.
• Aldrig hela nyckeln i logg. Endast prefix (ck_live_xxxxxxxx) lagras.
• Storage-paths för PDF-resources saneras mot ../ och /-prefix samt valideras segment för segment mot ^[a-zA-Z0-9_-]+$.
• Phase 2 (planerat): OAuth 2.1 plus Dynamic Client Registration. Tills dess är Bearer-modellen den enda vägen in.

6. Backup och återställning

• Dagliga automatiska backups hos Supabase med sju dagars retention. 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 betalad add-on 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 Workload Identity Federation mot Google Cloud, utan långlivade JSON-nycklar.
• 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 Officer-agenten (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 dashboarden (gap-analys-utkast, policy-utkast, riskrekommendationer, BCP-utkast). Modeller: gpt-4o och gpt-4o-mini. 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 CERT-SE 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 retention 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 dashboarden 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. Roadmap 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 roadmap är värd mer än ett vagt “vi siktar på det”:

• Q3 2026. Initiering av SOC 2 Type II observation period med extern revisor. Kontrollurval och policy-baseline 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 på audit-log-rader (kolumnerna prev_hash och entry_hash) samt daglig signering. Spåras i DPA och i intern PRD för AI Act-modulen.
• Q2 2027. PAdES-signerad PDF-export via eIDAS-kvalificerad tjänst (Scrive QES eller motsvarande) med Digidentity-certifikat. Signering blir opt-in för Sprint- och Always-On-kunder 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.

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.