Eneos stöd för ISO 27001-kontroller

KravBehörighetsmodell som kan separera konfliktande rättigheter (SoD i RBAC/ABAC).

Eneo har en flerskiktad RBAC: globala roller (Admin/User) skiljs från samarbetsyte-roller (Owner/Editor/Viewer) och resursrättigheter. Detta möjliggör separation av arbetsuppgifter mellan administratör och slutanvändare. Notera att plattformen tillhandahåller rollstrukturen för att separera ansvar, men inte automatisk detektering av konfliktande behörighetskombinationer (SoD-konfliktanalys).

KravInbyggd logisk åtkomstkontroll som kan styras med regler.

Inbyggd RBAC på flera nivåer – tenant, samarbetsyta och resurs. Granulär kontroll över assistenter, applikationer och AI-modeller.

KravUnika identiteter och hantering av deras livscykel i systemet.

Unika användaridentiteter via OIDC-federation (Entra ID, Keycloak, Auth0). Tjänstekonton ("service keys") är frikopplade från enskilda personer för automation och fortsätter fungera även om den som skapade nyckeln tas bort. Användarlivscykel kan hanteras via IdP samt genom automatisk provisionering (JIT) via OIDC redan idag. Stöd för SCIM-server kommer i version 2.1.0 (roadmap) för standardiserad automatisk provisionering och deprovisionering från HR- och identitetssystem.

KravSäker lagring/hantering av credentials (hashning, secrets-hantering, ingen klartext).

JWT i httpOnly-cookies med CSRF-skydd. API-nycklar hashas med HMAC-SHA256 (äldre SHA256-nycklar uppgraderas automatiskt vid användning) och lagras aldrig i klartext. Federationshemligheter krypteras med Fernet (AES-128-CBC + HMAC-SHA256). State-JWT:er är HS256-signerade med 10 min TTL.

KravTilldela, ändra, granska och återkalla rättigheter inifrån lösningen.

Behörigheter kan tilldelas, ändras och återkallas via UI och API. API-nycklar har en fullständig livscykel: skapande, rotation (med 24h övergångsperiod), suspendering, revokering och utgångsdatum, samt policyer för automatisk utgång vid inaktivitet och kaskad-revokering av delegerade nycklar. Alla ändringar loggas i revisionsloggen.

KravMöjlighet att särskilja och begränsa administrativa rättigheter.

Admin-roller är tydligt separerade från användare. Server-API-nycklar (sk_) har IP-allowlist och är åtskilda från browser-nycklar (pk_), som aldrig har admin-rättigheter. Service-nycklar med write/admin på tenant-nivå tvingas ha antingen IP-allowlist eller utgångsdatum. Granulär scope-kontroll: tenant, samarbetsyta, assistent eller app.

KravKonfigurerbar, finkornig åtkomststyrning som upprätthåller policyn från 5.15 – på objektnivå, per operationstyp och gärna med kontextbaserade beslut.

Eneo uppfyller flera kärnkrav i 8.3: deny-by-default (inga anonyma användare kan nå känsligt innehåll), styrning på objektnivå (assistent, samarbetsyta, applikation, AI-modell), och separation per operationstyp via roller (Owner/Editor/Viewer motsvarar läs-/skriv-/raderingsrättigheter). Logisk isolering sker genom multi-tenant-arkitektur och samarbetsytor. Dynamiska och kontextbaserade beslut finns delvis: tidbegränsad åtkomst via API-nycklar med utgångsdatum, IP-allowlist för server-nycklar (sk_), origin-allowlist för browser-nycklar (pk_), scope-kontroll på tenant/yta/assistent/app-nivå, rate limiting per scope samt strikt scope-läge. Åtkomstbeslut är direkt kopplade till klassningssystemet (5.12) – information med högre klassning kan inte oavsiktligt nå AI-modeller som saknar behörighet. All åtkomst loggas via auditloggen (8.15).

Det som saknasÅtkomstkontroll på fält-/postnivå inom enskilda dataposter, full ABAC med villkor på enhet och geografisk plats, samt automatisk larmning vid misstänkta missbruksmönster.

KravStöd för MFA och moderna autentiseringsprotokoll (OIDC/SAML m.m.).

Full OIDC-stöd med OAuth 2.0 Authorization Code Flow. MFA kan tvingas via IdP. Testat mot Entra ID, Keycloak, Auth0. JWT-sessioner med correlation_id och CSRF-skydd.

KravStöd för att klassa information i systemet enligt en organisationsdefinierad klassningsmodell.

Eneo har inbyggd funktion för informationsklassning där verksamheten själv definierar sina informationsklasser – ingen tvingad standardmodell. Detta möjliggör att kommunens eller organisationens befintliga klassningsmodell (t.ex. publik, intern, konfidentiell, hemlig) kan implementeras direkt i plattformen. Klassningssystemet utgör grunden som operativiseras genom 5.13: när ett projekt klassas styr klassningen automatiskt vilka AI-modeller och tjänster som får användas. Klassningsmodellen är central för Eneos säkerhetsarkitektur – inte en separat dokumentationsövning – vilket gör att klassningen får verkliga, automatiserade konsekvenser för informationshanteringen.

KravStöd för etiketter/labels enligt ett klassningsschema som möjliggör både kommunikation och automatisering av informationshantering.

Eneo bär klassningsetiketter på projekt-/samarbetsytenivå – en modell som ISO 27002 uttryckligen nämner som acceptabel (system som skyddar all information på systemets högsta möjliga klassningsnivå). Klassningsmetadata kopplad till varje projekt ärvs automatiskt till information som skapas eller bearbetas inom samarbetsytan, vilket uppfyller kravet på automatisk metadatahantering. Den mest värdefulla aspekten – att märkningen ska möjliggöra automatisering av informationsbehandling och underlätta för system att fatta beslut utifrån klassningsetiketterna – är direkt implementerad: Eneo styr automatiskt vilka AI-modeller och tjänster som får användas baserat på projektets klassning. Granularitet på fält-/postnivå inom enskilda dataposter saknas, men detta är enligt standarden ett valfritt önskemål snarare än ett krav.

KravInbyggd kryptering och nyckelhantering (vila + transit, gärna BYOK).

Kryptering i transit är obligatorisk (TLS 1.3). Federationshemligheter krypteras med Fernet.

Det som saknasKryptering i vila är valfri och förutsätter att operatören konfigurerar databas och fillagring. BYOK saknas i nuvarande version.

KravStöd för krypterade kanaler; skickar aldrig känsliga data i klartext.

TLS 1.3 påtvingad för all kommunikation via Traefik. API-nycklar och autentiseringstoken överförs aldrig i klartext.

KravMaskning/pseudonymisering av känsliga fält.

Eneo saknar generell datamaskning eller pseudonymisering av innehåll eller fält i data – sådan logik måste implementeras i de AI-applikationer som byggs ovanpå plattformen. Plattformen har dock log-redaction: Authorization-, Cookie- och Set-Cookie-headers loggas aldrig, och känsliga parametrar (token, secret, code, state) ersätts med [REDACTED] i loggar och span-attribut.

Det som saknasLog-redaction skyddar mot att hemligheter läcker i loggar, men uppfyller inte 8.11:s syfte att maskera data i användning eller visning.

KravSäker radering av data på begäran och vid avveckling.

Konfigurerbar kvarhållning med dagliga purge-jobb. Hierarkisk konversation-retention (assistent → samarbetsyta → tenant). Användardata kan raderas via API/UI.

KravIntegritetsskydd / spårbarhet mot förfalskning och otillåten ändring.

Revisionslogg dokumenterar alla händelser med aktör, åtgärd, utfall och tidpunkt, och åtkomst till loggar kräver en motivering som i sin tur loggas. RBAC begränsar vem som kan ändra information, och PostgreSQL används som lagring.

Det som saknasKryptografisk manipuleringssäkring/oföränderlighet: revisionsloggar hårdraderas av retention-jobb och det finns ingen tamper-evidence som skyddar poster eller loggar mot en aktör med databasåtkomst. Förbättringar via event sourcing finns på roadmap.

KravDataminimering, åtkomstbegränsning och radering av personuppgifter.

Datasuveränitet är en grundpelare i Eneo: data stannar i organisationens infrastruktur. RBAC begränsar åtkomst, retention-policys möjliggör automatisk radering, och revisionslogg spårar all åtkomst. Notera att user_email loggas avsiktligt som ett arv från befintligt audit-beteende – konfigurera loggaggregeringen att inte förindexera det fältet för att begränsa PII-exponering.

KravGenererar och skyddar egna säkerhets-/aktivitetsloggar.

Eneo har inbyggd granskningslogg (auditloggning) där verksamheten själv styr vilken detaljnivå loggningen ska ske på – per kategori och händelsetyp. Gallringsregler (retention) är konfigurerbara med dagliga purge-jobb. Strukturerade JSON-loggar persisteras i PostgreSQL. Åtkomst till loggar kräver motivering, och motiveringen loggas i sin tur. Export i CSV och JSON Lines (sync/async API). Stöd för att strömma loggar till extern logginfrastruktur med stöd för OpenTelemetry kommer i version 2.1.0 (roadmap).

KravExponerar händelser/signaler som gör onormalt beteende upptäckbart.

Eneo loggar säkerhetsrelevanta händelser med metadata och gör dem åtkomliga för analys, och export-API:et möjliggör vidarebefordran till en extern SIEM. I version 2.1.0 (roadmap) tillkommer strömning av loggar till extern logginfrastruktur med stöd för OpenTelemetry, vilket ytterligare stärker integrationen mot externa övervakningsverktyg.

Det som saknasInbyggd anomalidetektering och automatisk larmning – plattformen producerar och exporterar signalerna, men det aktiva övervaknings- och larmsteget förutsätter en extern SIEM-/observerbarhetslösning.

KravSäkra standardinställningar och möjlighet till härdning (secure-by-default).

Docker-baserad distribution med definierade baser. Låsta beroenden via lockfiles. Säkra defaults: TLS 1.3, CSRF-skydd, httpOnly-cookies. Konfiguration via miljövariabler. Notera att kryptering i vila inte är påslagen som standard (se 8.24).

KravBeroendehantering, inga kända sårbara komponenter, patchbarhet.

Publicerad säkerhetspolicy med tydliga svarsmål (Kritisk: 1 arbetsdag, Hög: 1–2 arbetsdagar, Medel: 2–5 arbetsdagar för första svar/triage). Dependency Review-grindar blockerar PR:er med sårbarheter på HIGH-nivå eller högre. Veckovisa Dependabot-uppdateringar. SBOM (CycloneDX + SPDX via Syft, samt separat Python runtime-SBOM) levereras per release.

KravSäkra utvecklingsrutiner tillämpas i kodens framtagning.

CI-pipeline med branch policy, kvalitetskontroll (Ruff lint+format, Pyright), enhetstester och integrationstester samt Docker-bygggrindar. Frozen lockfiles (uv --frozen, bun --frozen-lockfile). Kodgranskning via PR, och branch protection kräver att CI och Dependency Review passerar.

KravSäkerhetskrav är specificerade och inbyggda.

Säkerhetskrav dokumenterade i SECURITY.md och i arkitekturdokumentation, och säkerhetsbeslut är spårbara i Git-historiken. SBOM-arbetet följer OWASP SCVS-kraven för mjukvaruförteckningar.

KravTillämpade härdnings-/arkitekturprinciper i lösningen.

Domain-Driven Design med Repository Pattern och Dependency Injection. Tydlig separation av lager (presentation, applikation, domän, infrastruktur). Defense in depth med TLS, CSRF, JWT-validering och RBAC.

KravSäkra kodningsprinciper följs i utvecklingen.

Statisk analys via Pyright och Ruff. Kodgranskning för alla PR:er.

Det som saknasDedikerad SAST (CodeQL/avancerad kodskanning) är pausad i nuläget enligt den kanoniska säkerhetspolicyn (SECURITY.md), i väntan på intrimmad frågeuppsättning och triage-process, och planeras återupptas.

KravSäkerhetstestning ingår i utvecklingsflödet (t.ex. SAST/DAST).

Enhetstester och integrationstester körs vid varje PR. Dependency Review är aktiv.

Det som saknasDedikerad SAST/DAST är inte komplett: CodeQL är pausad och det finns ingen automatiserad DAST.

KravStyrd åtkomst till kodbas, byggverktyg och bibliotek.

Öppen källkod på GitHub (AGPL-3.0), vilket möjliggör oberoende granskning. Skrivåtkomst är dock kontrollerad via branch protection, kodgranskning och Maintainer-roller. Releases byggs via verifierade CI-pipelines, och SBOM-assets attesteras via GitHub artifact attestations (notera att själva release-artefakterna i övrigt inte signeras separat).