Säkerhetsarkitektur
Axiom är designat så att ett intrång i ett enskilt lager inte exponerar reglerad data. Här återges en kortfattad teknisk översikt.
Skydd i skal
Varje lager är en separat mekanism med en separat felmod. En angripare som tar sig förbi ett lager möts av nästa. Applikationen behandlas som en potentiellt fientlig klient; databasen är sanningskällan och efterlevnadspunkten.
Triggers upprätthåller reglerna och inaktivering kräver tabellägarrollen axiom_owner, reserverad för migrationer och aldrig används live. Applikationen ansluter till databas-poolen via andvändarrollen axiom_user och är begränsad till att använda funktioner ägda av runtime-rollen axiom_definer. De "triggerförstärkta" garantierna i detta dokument går alltså inte att kringgå från någon väg som applikationen eller dess användare når.
Execute-only-roll för applikationen
Förhindrar: Applikationen kan inte läsa eller skriva i tabeller direkt. Om applikationen kompromotteras kan angriparen fortfarande inte efterfråga eller modifiera data utanför den auditerade funktionsytan.
Implementering: Den PostgreSQL-roll som Node.js-API:et använder (axiom_user) har EXECUTE på funktioner och inget annat. Ingen SELECT, INSERT, UPDATE eller DELETE på någon tabell.
Behörighet på funktionslagret
Förhindrar: Buggar i en endpoint kan inte läcka data via en annan. Varje operation kontrolleras vid SQL-funktionsgränsen, inte i applikationskoden.
Implementering: All dataåtkomst går genom plpgsql-funktioner som kontrollerar anroparens behörigheter mot den begärda operationen, domänen och anläggningen. Applikationen förmedlar användaridentiteten; databasen avgör vad som är tillåtet.
Row-level security
Förhindrar: Ett glömt filter i en funktion (eller direkt åtkomst från privilegierade roller som analytics) kan inte returnera rader som anroparen inte har rätt att se.
Implementering: PostgreSQL RLS-policyer på varje reglerad tabell upprätthåller synlighet per rad som ett extra skyddslager under funktionsbehörigheterna.
Append-only
Förhindrar: En kompromottering av applikationen eller funktionslagret kan inte manipulera eller radera auditposter. Att kringgå skyddet kräver DDL-behörighet, inte applikationsbehörighet. Även en illasinnad databasadministratör möts av den kryptografiska kedjan för transaktionsloggen.
Implementering: Audittabeller (session_events och relaterade) är INSERT-only: applikationens roll saknar UPDATE- och DELETE-behörighet, och BEFORE UPDATE / BEFORE DELETE-triggers avvisar alla försök som extra skyddslager.
SCD Type 2-versionering
Förhindrar: Reglerad data skrivs aldrig över på plats. Ersatta poster bevaras i databasen, länkad till sin efterträdare. Förändringshistorik är förstaklassig data, inte en logg vid sidan om.
Implementering: Reglerade tabeller bär record_id, id, version, previous_record_id, previous_record_hash. Datakolumner är oföränderliga: applikationens roll saknar UPDATE-behörighet på dem, och BEFORE UPDATE-triggers avvisar otillåtna kolumnändringar som extra skyddslager. Uppdateringar går via lifecycle-övergångar och nya versionsposter.
Kryptografisk postkedja
Förhindrar: Manipulering av historisk data är upptäckbar: bytes som ändras i efterhand bryter hashkedjan, och brottet kan bevisas.
Implementering: Varje postversion lagrar record_hash = SHA-256 av sitt innehåll, och previous_record_hash länkar bakåt genom kedjan. Kedjeverifiering är en deterministisk SQL-fråga.
Delegeringsmodell
Delegering är en förstaklassig funktion. Behörigheter kan överlämnas tillfälligt — men endast enligt regler som förhindrar behörighetsupptrappning. Båda typerna kräver utgångsdatum, motivering och fullständig spårningslogg.
Horisontell delegering
Omfattning: Samma domän, samma eller högre behörighetsnivå, OLIKA anläggning
Användningsfall: En granskare på plats A är borta; en granskare på plats B täcker tillfälligt deras uppgifter.
Vertikal delegering
Omfattning: Samma anläggning, samma domän, behörighetsnivå exakt ett steg lägre
Användningsfall: En chef delegerar datainmatning till en tekniker men behåller sin egen roll som författare och granskare.
Varje delegering registrerar: den delegerande användaren, delegeringstyp, målomfattning (anläggning + domän + behörighetsnivå), utgångstidpunkt, motivering och en referens till ursprungsbehörigheten. Delegeringar ärver spårningsloggen för den underliggande behörigheten — det finns ingen separat, svagare kanal.
E-signaturautentisering
21 CFR Part 11 kräver återautentisering vid signering. Axiom har ett register över autentiseringsfaktortyper som signeringspolicyer kan kräva — enbart lösenord för åtgärder med låg risk, hårdvarunyckel eller SSO-återautentisering för åtgärder med högre risk.
Kontolösenord
Återinmata lösenord vid signering. Grundfaktorn som krävs enligt 21 CFR Part 11.
Hårdvarunyckel / plattformsautentisering
YubiKey, Touch ID, Windows Hello. Phishing-resistent, per användare.
Återautentisering via identitetsleverantör
För SSO-kopplade konton — tvingar fram en ny inloggning hos identitetsleverantören via OIDC prompt=login.
Ändringshantering
Reglerade förändringar — av specifikationer, testmetoder, anläggningskonfiguration och annan kontrollerad data — går genom ett inbyggt ändringshanteringsflöde. Föreslagna ändringar författas, granskas och godkänns (eller avslås) med explicit spårning. Ingenting ändras direkt på produktionsposter utan att passera ett granskningssteg där processen kräver det.
Vad som inte täcks i detta dokument
Denna sida är en sammanfattande översikt. En fullständig teknisk rapport — som täcker hotmodell, driftstopologi, nyckelhantering, backup och DR, hemlighetsrotation och SCD2-uppgraderingsproceduren — finns tillgänglig på begäran.
- Driftstopologi och nätverksisolering
- Hemlighetshantering och nyckelrotation
- Backup, katastrofåterhämtning och integritetsverifiering
- Sammanfattningar av penetrationstester (under NDA)
- Fullständigt auditloggschema och retentionspolicy
Begär den fullständiga tekniska rapporten
Vi skickar den kompletta säkerhetsdokumentationen till kvalificerade kunder — driftstopologi, nyckelhantering, auditloggschema och mer.
hello@axiom.bi