Säkerhet och datahantering
Kontrollera säkerhetsstatus, dataplats, underbiträden, incidentprocess och DPA-underlag.
Snabbkoll
Region, kryptering, secrets, SSO, audit-loggar, incidentrutiner och avtalsdokumentation.
Cloud-miljön verifieras före release; extern pentest och formell certifiering är inte genomförda.
Status bygger på produktionskonfiguration, leverantörsavtal och dokumenterade operativa rutiner.
Datacenter och kryptering
Plats
Skolkolls Cloud Functions, Hosting, Cloud Storage och Firestore är konfigurerade i Google Clouds region europe-west1 (Belgien, EU). Firebase Authentication omfattas av Google Cloud DPA/SCC/DPF. Region-status i prod verifieras före varje release medgcloud firestore databases describe och gcloud storage buckets describe.
Vissa underbiträden och externa tjänster (Stripe, Anthropic, OpenAI, Google Analytics 4 och sociala inloggningsleverantörer) är USA-baserade och kan behandla data där. För dessa tillämpas EU:s standardavtalsklausuler (SCC) och respektive leverantörs DPA. Zoho PageSense laddas via EU-scriptet cdn-eu.pagesense.io och omfattas av Zoho DPA/SCC vid eventuell tredjelandsöverföring. Zoho Desk används för betalande kunders supportärenden via Zohos EU-hosting (zohohost.eu). Sentry körs i EU-regionen (Tyskland). Se tabellenunderbiträden och externa tjänster nedan för fullständig översikt, och Dataskydd och underbiträden för operativa detaljer.
Kryptering i vila (encryption-at-rest)
Firestore och Cloud Storage krypterar all data i vila med Google-hanterade nycklar (AES-256) som standard. Vi använder inte kundhanterade krypteringsnycklar (CMEK) i dagsläget — det är en funktion vi utvärderar inför framtida Pro-tier-åtaganden.
Kryptering under transport (in-transit)
All trafik till och från Skolkoll sker via TLS 1.2 eller senare. Firebase Hosting aktiverar HSTS (HTTP Strict Transport Security) automatiskt, vilket förhindrar nedgradering till okrypterad HTTP. Certifikat hanteras automatiskt av Google och förnyas utan manuell åtgärd.
Secrets och autentisering
Secrets Management
Alla hemligheter — inklusive ADMIN_TOKEN, STRIPE_SECRET_KEYoch STRIPE_WEBHOOK_SECRET — deklareras somFirebase Secret Manager-bindningar i Cloud Functions-koden (via secrets: […] i functions-options och defineSecret()). Inga hemligheter finns hårdkodade i källkod eller miljöfiler. Cloud Functions v2 läser värdena från Google Cloud Secret Manager vid runtime. Att aktiva secret-versioner finns för varje deklarerad hemlighet i prod verifieras med gcloud secrets versions listföre release.
ID-token revocation
Firebase Authentication-token verifieras med checkRevoked: true på alla skyddade admin-endpoints. Det innebär att inloggning på en annan enhet, lösenordsbyte eller manuell token-revokering omedelbart ogiltigförklarar befintliga sessioner, utan att vänta på token-expiry (standardlivslängd: 1 timme).
Admin-åtkomst
Admin-token roteras manuellt och lagras aldrig i klientkod. Admin-endpoints kräver HTTP-headern X-Admin-Token med korrekt värde, kontrollerat server-side. Inga admin-operationer är tillgängliga från webbläsaren utan explicit autentisering.
Kommunlicens SSO
Kommunlicens använder Firebase Authentication som kontolager. Standardflödet är e-postbaserad inloggning och organisationsinbjudningar. För kommuner som kräver central identitetshantering kan SAML 2.0 eller OIDC aktiveras som Enterprise SSO-tillägg.
- IdP-spår: SAML 2.0 eller OIDC, inklusive Microsoft Entra ID/Azure AD.
- Rollmappning: Kommunens IdP styr identiteten; Skolkoll lagrar roll och organisationstillhörighet för behörighet i tjänsten.
- Avslut: När kommunen tar bort användaren i sin IdP upphör ny inloggning. Befintliga Firebase-sessioner kan revokeras manuellt vid behov.
- Start: Metadata-utbyte, testkonto och domänverifiering krävs före produktionsstart.
Se även SSO-status i upphandlingspaketet.
Audit logging
Känsliga administratörsoperationer loggas i Firestore-kollektionen auditLog. Kollektionen har deny-all Firestore Security Rules — ingen klient kan läsa eller skriva till den. Åtkomst sker uteslutande via Firebase Admin SDK (server-side), vilket eliminerar risken för manipulation via klientkod.
Varje audit-loggpost innehåller: tidsstämpel, operation, utförande identitet och påverkat objekt. Nya poster taggas med expiresAt för 2 års retention och raderas asynkront av Firestores TTL-mekanism när TTL-policyn är aktiv.
AI-chatbottens anrop loggas separat med pseudonymiserade poster (SHA-256-hash av IP, längd på fråga/svar, inte innehåll). Pseudonymisering sker vid skrivning; raderingsrutinen för dessa poster dokumenteras i Dataskydd och underbiträden.
Backup och återställning
Firestore-databasen är konfigurerad för Point-in-Time Recovery (PITR)via Google Cloud. PITR möjliggör tidpunktsåterställning inom det fönster som Firestore PITR tillhandahåller (upp till 7 dagar), vilket täcker oavsiktliga dataändringar och korruption under en incidentperiod. Faktiskt PITR-status och retention-fönster i prod verifieras med gcloud firestore databases describeföre varje release. Återställning har inte testats i ett kontrollerat disaster-recovery-tillfälle — vi avser att genomföra en sådan test inför första kommunlicens-produktionsdriftsättning.
Underbiträden och externa tjänster
Nedanstående lista blandar faktiska personuppgiftsbiträden/underbiträden med externa datakällor och API:er som inte alltid behandlar personuppgifter på Skolkolls uppdrag. Den bindande underbiträdeslistan för PuB/DPA-syfte finns påDataskydd och underbiträden.
| Tjänst | Roll / funktion | Plats | GDPR-roll / grund |
|---|---|---|---|
| Firebase / Google Cloud | Hosting, databas (Firestore), Cloud Functions, Secret Manager, Cloud Storage | Cloud Functions, Hosting, Cloud Storage och Firestore: EU (europe-west1, Belgien). Firebase Authentication omfattas av Google Cloud DPA/SCC/DPF. | Avtal (art. 6.1.b); DPA med Google ingår i Firebase-villkoren |
| Stripe | Betalningshantering för Pro-tjänster; kortuppgifter hanteras aldrig av Skolkoll | Irland (EU) primärt; vissa fraud-detection-funktioner kan involvera Stripe US under SCC | Avtal (art. 6.1.b); Stripes DPA; SCC där det behövs |
| Google Analytics 4 (GA4) | Anonym besöksstatistik; laddas bara efter samtycke | USA | Samtycke (art. 6.1.a); SCC; IP-anonymisering aktiverad |
| Zoho PageSense | Webbanalys, A/B-testning och heatmaps/session recording på publika sidor; laddas bara efter samtycke | EU-script via cdn-eu.pagesense.io; DPA/SCC vid eventuell tredjelandsöverföring | Samtycke (art. 6.1.a); Zohos DPA/SCC |
| Zoho Desk | Supportärenden för betalande kunder via support@skolkoll.se och supportportalen | EU (support.skolkoll.se via Zohos EU-hosting, zohohost.eu); DPA/SCC vid eventuell tredjelandsöverföring | Avtal (art. 6.1.b) och berättigat intresse (art. 6.1.f); Zohos DPA/SCC |
| Sentry | Felövervakning; samlar in stacktraces, webbläsarinfo och IP-adress (anonymiseras kort efter mottagandet) | EU (Tyskland, ingest.de.sentry.io) | Berättigat intresse (art. 6.1.f); SCC vid support från USA-team |
| Anthropic (Claude API) | AI-assistenten Kollen; bearbetar chatmeddelanden i realtid | USA | Samtycke (art. 6.1.a); SCC; Anthropics DPA; data bevaras max 30 dagar hos Anthropic |
| OpenAI | Säkerhets-/innehållsgranskning av skolbilder och chalkboard-stilisering; endast efter uttryckligt samtycke i skolbildsformuläret. Kontaktuppgifter, fotografnamn, rättighetsinnehavare och fritext skickas inte till OpenAI. | EU/USA under SCC | Samtycke (art. 6.1.a); OpenAI DPA; SCC vid tredjelandsöverföring |
| Resend | E-postleverans för skolbevakning och transaktionsmail | USA | Berättigat intresse / samtycke (art. 6.1.f/a); SCC |
| Nominatim (OpenStreetMap) | Geokodning för "Nära mig"-funktionen; ingen persondata lagras | EU/EES | Berättigat intresse (art. 6.1.f); ingen DPIA krävs |
| ResRobot (Trafiklab) | Kollektivtrafikdata för pendlingsflik; koordinater proxas via Skolkolls server | Sverige (EU) | Berättigat intresse (art. 6.1.f) |
| JobTech (JobEd Connect) | Yrkesmatchning för karriärfliken; utbildningstext skickas, ingen persondata | Sverige (EU) | Berättigat intresse (art. 6.1.f) |
| Skolverkets API | Skoldata (öppen data); behandlar inte personuppgifter | Sverige (EU) | Ej tillämpligt (offentlig data) |
Incidentrespons
Vi är ett litet team och vill vara ärliga om vår process: vi har inte ett formellt Security Operations Center (SOC) eller 24/7-beredskap. Vad vi har är en definierad process som vi följer konsekvent.
- Övervakning och detektion: Sentry fångar applikationsfel i realtid. Google Cloud-konsolen har alerting på ovanliga CPU-toppar, quota-överskridanden och auth-fel. Vi granskar Sentry-dashboard dagligen.
- Triage (inom 24 timmar): När en möjlig säkerhetsincident detekteras gör ansvarig utvecklare en initial klassificering: påverkar incidenten personuppgifter? Är tjänsten otillgänglig? Finns tecken på obehörig åtkomst?
- Inneslutning och mitigering: Beroende på incidenttyp vidtas omedelbara åtgärder — revokering av komprometterade tokens, spärr av misstänkta IP-adresser, eller tillfällig nedstängning av berörd funktion.
- Notifiering: Om incidenten bedöms innebära en personuppgiftsincident enligt GDPR art. 33 notifierar vi Integritetsskyddsmyndigheten (IMY) inom 72 timmar. Drabbade registrerade kontaktas om incidenten sannolikt medför hög risk för dem (GDPR art. 34). Notifiering sker via markus@skolkoll.se.
- Återställning: Vid databaspåverkan används Firestores PITR-funktion (upp till 7 dagars historik) för att rulla tillbaka berörda dokument. Statiska sidor byggs om från källdata.
- Post-incident review: Efter varje allvarlig incident dokumenterar vi rotorsak, åtgärder och förebyggande ändringar internt. Väsentliga säkerhetsförbättringar kommuniceras i releaseloggen.
Driftstatus och planerat underhåll publiceras på driftsstatussidan.
Compliance och certifieringar
| Standard / krav | Status | Kommentar |
|---|---|---|
| GDPR | Underlag finns | Integritetspolicy, samtyckesbanner, PuB-mall, ROPA, underbiträdesregister och raderingsrutiner är dokumenterade. Kommunalt signeringspaket kräver juridisk granskning av PuB, säkerhetsbilaga och kontinuitetssvar innan det används som bindande godkännande. |
| SOC 2 Type II | Ej certifierat | Vi följer SOC 2-principerna (säkerhet, tillgänglighet, konfidentialitet) men har inte genomgått en formell Type II-revision. Certifiering utvärderas inför storskalig kommunlansering. |
| ISO 27001 | Ej certifierat | ISO 27001-certifiering är inte genomförd. Vi arbetar strukturerat med informationssäkerhet men utan formell ISMS-implementation. |
| Extern penetrationstest | Ej genomförd | Ingen extern säkerhetsrevision av applikationen har genomförts under 2026. En extern pentest är planerad inför produktionslansering av public free-tier API. |
| PCI DSS | Via Stripe | Skolkoll hanterar inga kortuppgifter direkt. Stripe, som är PCI DSS Level 1-certifierat, hanterar all kortdata. |
Responsible disclosure
Om du upptäcker en säkerhetsbrist i Skolkoll uppskattar vi att du rapporterar den till oss innan du publicerar den offentligt. Vi åtar oss att:
- Bekräfta mottagning av din rapport inom 5 arbetsdagar.
- Hålla dig informerad om utredningens progress.
- Åtgärda bekräftade säkerhetsbrister inom rimlig tid beroende på allvarlighetsgrad.
- Erkänna ditt bidrag i releaseloggen om du önskar det (med ditt samtycke).
Vi erbjuder ingen ekonomisk belöning (bug bounty) i dagsläget, men vi tar alla rapporter på allvar och kommunicerar öppet om utredningens resultat.
Disclosure-policy: Vi tillämpar en 90-dagars koordinerad disclosure-period. Om en brist inte åtgärdats inom 90 dagar från din rapport förbehåller du dig rätten att publicera detaljerna. Vi kommunicerar proaktivt om vi behöver mer tid.
Kontakt: Skicka din rapport tillsecurity@skolkoll.se med ämnesraden "Security disclosure". Inkludera reproduktionssteg och bedömning av påverkan. Kryptera gärna med vår offentliga nyckel om du hanterar känslig information — kontakta oss så delar vi den.
Vänligen rapportera inte via GitHub Issues eller sociala medier.
DPA och avtalsdokumentation
Skolkoll fungerar som personuppgiftsbiträde för kommuner och skolor när vi behandlar personuppgifter för deras räkning inom Enterprise eller andra betalda tjänster. Vi tillhandahåller ett personuppgiftsbiträdesavtal (PuB-avtal / DPA) anpassat för kommunal upphandling.
- Standardmall: Se vår PuB-mall för ett färdigt biträdesavtal.
- Anpassat avtal: Kontakta markus@skolkoll.se om din organisation kräver ett skräddarsytt DPA.
- ROPA (Register of Processing Activities): Tillgänglig på ropa-sidan.
- Dataskyddsdetaljer: Se dataskydds- och underbiträdessidan för operativa GDPR-detaljer.
- Säkerhetsbilaga: En källhänvisad bilaga för kommunal säkerhetsgranskning (release-grind, stage/prod-isolering, byggintegritet, säkerhetsheaders) lämnas som bilaga till upphandlingssvar (utkast under juridisk granskning).
Se även: Integritetspolicy · SLA och driftnivå · Kommersiell separation · Transparens