Identity and policy

Executive thesis

Dataheart bör inte bli en ny identitetsleverantör eller lova att ett enda policyspråk kan exekveras identiskt i API:er, databaser, Power BI/Fabric, sökindex och agentverktyg. Det hållbara målet är i stället en vendor-neutral authorization consistency layer:

• Kunden äger identitetsanknytning, tenantgränser, policys, nycklar och besluts-/åtgärdsbevis.
• Varje begäran bär en verifierbar kedja av subjekt, aktuell aktör, arbetslast/agent, aktiv tenant, resurs, åtgärd och kontext.
• Samma kanoniska beslutskontrakt används av alla policy enforcement points, även om den lokala enforcement-mekanismen varierar.
• Tillstånd kontrolleras igen vid faktisk exekvering. En rekommendation, UI-knapp eller LLM-plan är aldrig en auktorisation.
• Avsaknad av tenant, okänd policyversion, oförstådd obligation, timeout eller stale high-risk-beslut ger deny.
• De två profilerna—Microsoft-native och self-hosted/open—måste passera samma conformance suite. Produktens invarians ligger i semantik och evidens, inte i samma komponenter.

Detta ligger nära NIST:s resursorienterade Zero Trust-modell, men går längre genom att göra tenant-noninterference, delegationskedjan och tvärkanalig beslutsekvivalens till explicit produktkontrakt.

Den viktigaste produktinsikten är:

Dataheart bör vara referensplanet för “vem eller vad agerade, för vems räkning, i vilken kundkontext, mot vilken resurs, enligt vilken policyversion, med vilket resultat”—inte den universella exekveringsmotorn för varje underliggande system.

State of the art 2024-2026

Statusetiketter:

• Etablerad: väl standardiserad eller brett beprövad.
• Framväxande: standard eller produktmönster finns, men interoperabilitet och driftserfarenhet är ännu ojämn.
• Hypotes: rimlig Dataheart-riktning som måste bevisas experimentellt.
• Leverantörspåstående: stöds av leverantörsdokumentation men ska inte antas gälla utanför den dokumenterade ytan.

Område	Lägesbild 2026-08-23	Bedömning
Zero Trust	Identitet, resurs, enhets-/riskkontext och policy utvärderas per åtkomst, inte utifrån nätverksposition.	Etablerad
Human federation	OIDC/OAuth/SAML är norm. NIST SP 800-63-4 formaliserar assurance, federation trust agreements och audience-/replay-skydd.	Etablerad
OAuth-säkerhet	RFC 9700 gör audience restriction, sender-constrained tokens, refresh-token rotation och avveckling av password grant till best current practice.	Etablerad, men ojämnt implementerad
Delegering	RFC 8693 skiljer delegation från impersonation och definierar act-kedjan. Tidigare aktörer är revisionshistorik; aktuell aktör och toppnivåclaims styr accesskontrollen.	Etablerad standard, varierande downstream-stöd
Workload identity	Kortlivade, attesterade arbetslastidentiteter ersätter statiska hemligheter. SPIFFE är plattformsneutral; Entra erbjuder managed identity och workload federation.	Etablerad i moderna plattformar
RBAC + ABAC + ReBAC	RBAC används för grova organisationsrättigheter, ReBAC för delning/hierarkier och ABAC för risk, syfte, tid och dataklassning. Ingen av modellerna räcker ensam.	Etablerat hybridmönster
PDP–PEP-interoperabilitet	OpenID AuthZEN Authorization API 1.0 blev final i januari 2026 och standardiserar subject/action/resource/context och evaluerings-/sök-API:er.	Framväxande
Kontinuerlig access	OpenID CAEP 1.0 blev final 2025 och omfattar exempelvis session revocation, credential change och token-claim changes.	Framväxande; mottagarstöd och leverans-SLO varierar
Agentidentitet	Microsoft har 2026 introducerat separata agentidentiteter, blueprints, sponsorer och attended/unattended-flöden.	Framväxande leverantörspåstående
Dataplanspolicy	RLS/CLS/OLS är etablerat i databaser och analytiska motorer. Semantik, bypass-regler och adminprivilegier skiljer sig kraftigt.	Etablerad mekanism, inte enhetlig säkerhetsmodell
Tvärkanalig konsistens	Ingen standard säkerställer i dag att API, BI, SQL, sök, agent och faktisk action ger samma utfall.	Hypotes och produktdifferentiering

Tre 2024–2026-förskjutningar är särskilt viktiga:

1. Från inloggning till kontinuerliga säkerhetssignaler. Kortlivade tokens kompletteras med CAEP-liknande revokations- och riskhändelser.
2. Från inbyggd applikationslogik till PDP/PEP-kontrakt. AuthZEN minskar leverantörskopplingen för beslutstid, men standardiserar inte policyspråk, policyadministration eller PDP:ns egen autentisering.
3. Från generiska service principals till särskiljbara agentidentiteter. Detta förbättrar attribution men löser inte prompt injection, verktygsmissbruk eller felaktig affärspolicy.

Load-bearing concepts

1. Identitet är en typad kedja, inte ett användarnamn

Ett säkert Dataheart-kontrakt behöver minst:

{
  "subject": {
    "kind": "human",
    "issuer": "customer-trust-domain",
    "subject_id": "opaque-stable-id",
    "home_tenant": "customer-tenant"
  },
  "actor_chain": [
    {
      "kind": "agent",
      "actor_id": "opaque-agent-id"
    },
    {
      "kind": "workload",
      "actor_id": "opaque-workload-id"
    }
  ],
  "active_tenant": "customer-tenant",
  "resource": {
    "tenant": "customer-tenant",
    "type": "business-object",
    "id": "opaque-resource-id",
    "classification": "confidential"
  },
  "action": "approve",
  "context": {
    "purpose": "declared-purpose",
    "authentication_assurance": "assurance-level",
    "risk_state": "current",
    "request_id": "opaque-request-id"
  }
}

Identitetsnyckeln ska vara minst {issuer, subject_id}. E-postadress, display name eller ett ensamt sub får inte vara global identifierare. Följande tenantbegrepp måste hållas isär:

• identity/home tenant,
• resource tenant,
• aktiv affärstenant,
• drift-/plattformstenant,
• eventuell fakturerings- eller avtalskund.

active_tenant får härledas endast från verifierad identitet plus server-side medlemskap/policy—aldrig från en URL-, prompt- eller JSON-parameter ensam.

2. Delegerad behörighet är en skärning

För attended agent- eller OBO-flöden bör effektiv rättighet vara:

användarens rättighet
∩ agentens tillåtna roll
∩ arbetslastens rättighet
∩ explicit delegerat scope/capability
∩ kundens tenantpolicy
∩ aktuell risk- och ändamålskontext

Token exchange och act-claims bevarar attribution, men ger inte automatiskt denna skärning. Varje resursserver måste tolka användare och aktör separat. Om ett downstream-system bara förstår sub, måste Dataheart lägga ett kontrollerat adapter- eller action-broker-lager framför det.

3. RBAC, ReBAC och ABAC har olika jobb

• RBAC: stabila basroller som tenant-admin, steward, analyst och operator.
• ReBAC: “medlem av kund”, “äger resurs”, “delad via projekt”, arv i dokument-/mapp-/kunskapshierarkier.
• ABAC: dataklass, syfte, region, tid, enhetsrisk, autentiseringsnivå och transaktionsvärde.
• Task capability: kortlivad rätt att utföra exakt en avgränsad agentåtgärd med parameterhash, audience, expiry och replay-skydd.

Tenantgränsen ska vara en negativ säkerhetsinvariant, inte en roll som råkar tilldelas korrekt.

4. Ett kanoniskt PDP/PEP-kontrakt—inte nödvändigtvis ett policyspråk

AuthZEN är en bra vendor-neutral sydgående gränsyta. Dataheart behöver dock profilera den med obligatoriska fält som standarden lämnar öppna:

• tenant och resource-tenant,
• subject/actor/workload chain,
• policy-ID, version och digest,
• entitlement-/relationship-revision,
• decision freshness och max TTL,
• reason codes och obligations,
• required step-up/human approval,
• decision/evidence ID och trace ID.

Internt bör beslut vara allow | deny | indeterminate. AuthZEN:s framgångsrika svar är booleska; transportfel och okänd obligation måste därför normaliseras till indeterminate, vilket enforcement normalt behandlar som deny.

5. Dataplanet måste bära ett eget skydd

API-filtrering är inte tillräckligt. Dataheart behöver defense in depth:

• API- och verktygs-PEP före åtkomst,
• tenantnyckel på varje tenantbunden resurs,
• RLS på basdata där motorn stöder det,
• CLS/OLS eller separata vyer för känsliga attribut,
• policy-aware sök-/vektorfilter före ranking,
• cache- och materialiseringsnycklar som inkluderar tenant, principal-policy-scope och policyrevision,
• BI-modeller som inte kan återanvända ett bredare resultat i en snävare användarkontext.

PostgreSQLs officiella dokumentation visar både styrkan och begränsningen: aktiverad RLS utan policy är default-deny, men superusers, BYPASSRLS och normalt tabellägaren kringgår RLS; referensintegritet kan dessutom skapa covert channels. Se PostgreSQL Row Security Policies.

6. Konsistens och revokation är distribuerade systemproblem

En allow-cache är säkerhetskritisk data. Den behöver:

• explicit policy- och entitlement-revision,
• separat maxstaleness per action class,
• strong/higher-consistency check efter grant/revoke och före kritiska actions,
• invalidation från säkerhetssignaler,
• kortare TTL än själva affärsrisken tillåter,
• mätning av faktisk revoke-to-deny-latens.

OpenFGA:s dokumenterade consistency modes illustrerar avvägningen: standardläget kan svara från cache och missa en omedelbar tupleändring; higher consistency hoppar över cache till priset av prestanda. Det är ett leverantörsexempel, inte ett bevis på Zanzibar-ekvivalent extern konsistens.

7. Evidenskedjan måste koppla beslut till effekt

Minsta auditpost:

• verifierat subject, aktuell actor, workload/agent och delegationshistorik,
• aktiv tenant och resursens tenant,
• resource/action/parameterhash,
• autentiserings- och risksignalernas tider,
• policy-ID/version/digest och relationship revision,
• beslut, reason codes och fullföljda obligations,
• approval/step-up-evidence,
• exekverande workload,
• idempotency key,
• exekveringsresultat och effect hash,
• trace/decision/action IDs.

Logga inte råa tokens eller fler personattribut än vad revisionen kräver.

Reference patterns

Vendor-neutral invariants vs deployment-profile choices

Lager	Vendor-neutral invariant	Microsoft-native profil	Self-hosted/open profil
Human identity	Kundens IdP är authority; stabil {iss, sub}; explicit tenantbindning	Microsoft Entra ID, Conditional Access, PIM, access reviews	Kundvalt OIDC/SAML-system; lokalt driftad trust/configuration
Workload identity	Unik kortlivad identitet per workload; inga delade statiska secrets	Managed identities och Entra workload identity federation	SPIFFE/SPIRE och mTLS/JWT-SVID
Agent identity	Agent skild från människa och generell app; sponsor/ägare/livscykel	Entra Agent ID där moget, annars separat managed/app identity	Separat SPIFFE/OIDC-workload/agent-principal plus kundägt register
Delegation	Subject och current actor bevaras; downscoped audience-bound token	OBO/token exchange där resursen stöder det	RFC 8693-kompatibel token exchange eller intern capability service
PDP-kontrakt	AuthZEN-profilerad evaluation/search-yta	Kundägd PDP-tjänst på Azure; Entra/Azure RBAC som coarse signals	OPA/Cedar-liknande ABAC-motor och/eller OpenFGA-liknande ReBAC bakom samma API
API enforcement	Varje request kontrolleras lokalt eller via PDP; default deny	API Management, gateway, Functions/containers och tjänste-PEP	Envoy/gateway/sidecar/library PEP
Data enforcement	Tenantfilter och CLS/RLS/OLS nära data	Azure SQL/Fabric/OneLake/semantic-model-adaptrar	PostgreSQL FORCE ROW LEVEL SECURITY, query gateway och BI-adaptrar
Evidence	Policy- och actionevidence i kundägd append-only lagring	Event Hubs/Monitor plus immutable Azure Storage i kundens subscription	OpenTelemetry/event stream plus kundägd WORM/object storage
Portabilitet	Export av identitetsmappning, relationsdata, policy-IR och evidens	Adapter för Entra/Fabric-specifika ID:n och regler	Adapter för Rego/Cedar/FGA-specifika modeller

Microsoft-native är inte samma sak som “Entra fattar alla affärsbeslut”. Entra och Azure RBAC är främst identitets-, sessions- och plattformsauktorisation. Datahearts affärsobjekt behöver fortfarande ett PDP-kontrakt och lokala PEP:er.

Tenant-isoleringsmönster

1. Delad databas med logisk isolering

   Tenantkolumn, RLS, tenantbundna resurs-ID:n, policycheck och separata cache-/sök-namespace. Lägst kostnad, störst blast radius vid modell- eller anslutningsfel.

2. Cell/stamp per kundgrupp

   Separat compute, policy store, sökindex och data plane per cell; gemensam produkt-control-plane. Begränsar blast radius och ger bättre data residency, men kräver routing, fleet management och dubblerad kapacitet.

3. Full kundinstans

   Kundens tenant/subscription eller self-hostade miljö äger IdP-anknytning, workloads, PDP, data, nycklar och evidence store. Starkast kundägande och enklast regulatorisk separation; högst uppgraderings-, support- och observabilitykostnad.

Riskklass, inte kundstorlek, bör avgöra mönster. Samma kund kan använda delad read-only knowledge retrieval men separat action cell för finansiella eller säkerhetskritiska writes.

Kontrollerad action flow

Intent/rekommendation
→ bind subject + actor + tenant + exact parameters
→ policy evaluation
→ eventuell step-up eller mänskligt godkännande
→ kortlivad task capability
→ executor verifierar audience, expiry, replay och parameterhash
→ ny policykontroll vid commit
→ idempotent effekt
→ evidence record för beslut och faktiskt resultat

Agenten bör aldrig själv kunna ändra tenant, policyversion, approvalstatus eller capability-parametrar.

Failure modes and counter-evidence

Failure mode	Counter-evidence/begränsning	Rekommenderad kontroll
Tenant från request eller prompt accepteras som authority	En autentiserad principal kan tillhöra flera kunder; autentisering väljer inte aktiv tenant.	Server-side membership resolution; bind tenant till token/capability och resurs.
E-post eller namn används som principal-ID	Identiteter kan återanvändas, byta namn eller kollidera mellan issuers.	{issuer, immutable subject} plus separat lokal principal-ID.
Shared service principal för alla kunder	Ett credential- eller rollfel får full plattformsblast radius.	Unik workload/agent-identitet per cell eller tenant; separata profiler får inte betraktas som egna kryptografiska identiteter om de inte är det.
OBO övergår tyst till app-only	Downstream ser workloadens privilegier men tappar användarens begränsning och attribution.	Avvisa semantic downgrade eller gå via action broker som uttryckligen utvärderar båda.
Bearer-token replay/audience confusion	RFC 9700 beskriver stulna access tokens och sammanblandning mellan klient- och användaridentitet.	Audience restriction, sender constraint där möjligt, asymmetrisk klientauth, kort TTL och strikt token-typning.
Revokerad användare behåller access	JWT, cache och replikerade attribut är stale tills token eller cache uppdateras.	CAEP/invalidation plus kort TTL och strong check för kritiska actions.
Central PDP blir single point of failure	Nätverksfel kan antingen stoppa verksamheten eller fresta till fail-open.	Lokala verifierade policybundles för tillåtna read paths; writes/actions deny vid indeterminate.
Policybundles eller relationer kommer i olika ordning	OPA dokumenterar att flera överlappande bundle sources saknar ordering guarantees; stale external data är en uttrycklig risk. Se OPA external data.	Signerade atomiska releaser, en ägare per namespace, revision pinning och health gates.
ReBAC-marknadsföring tolkas som hård tenantisolering	Ett gemensamt store och en felaktig parent/public tuple kan vidga access globalt.	Tenant som obligatorisk rot, schema-/tuple-lint, noninterference-test och fysisk cell för högriskdata.
Databas-RLS antas skydda administratörer	PostgreSQL har dokumenterade owner/superuser-bypass och covert channels.	Separat runtime-roll, FORCE RLS, inga owneranslutningar, negativ testning och separat krypterings-/cellgräns.
BI-säkerhet antas motsvara API-säkerhet	Motorer har olika rollkombination, metadata- och adminsemantik. Microsoft anger exempelvis att OneLake RLS/CLS använder grantmodell och inte begränsar workspace Admin/Member/Contributor. Se OneLake security.	Power BI/Fabric som egen PEP-klass; minst privilegierade workspace-roller; export-, cache- och admin-bypasstester.
Förberäknade rapporter, embeddings eller cacheposter läcker	En korrekt runtimecheck hjälper inte om artefakten skapades under bredare principal.	Märk artefakten med tenant, policyrevision och effective scope; återanvänd aldrig över en bredare säkerhetsgräns.
Agentidentitet anses lösa agentsäkerhet	Microsoft Entra Agent ID förbättrar identitet, sponsor och audit men agenthosten och verktyget måste fortfarande enforca policy.	Tool broker, parameterpolicy, approval, task capability, budget/rate limits och commit-time check.
“Google gjorde det” används som skalbarhetsbevis	Zanzibar-pappret visar extrem skala och extern konsistens i Googles egen miljö; det bevisar inte samma egenskaper hos efterföljare.	Benchmarka vald implementation, datastore, modell och konsekvensläge med Datahearts egna grafer.
Fail-closed införs utan riskdifferentiering	Full deny vid varje read-partition kan slå ut verksamheten och skapa manuella bypasser.	Fördeklarerade degradation classes: aldrig fail-open för writes/actions; bounded last-known-good endast för lågklassad read.
Human approval blir “rubber stamp”	UI-godkännande utan exakt parameterbindning kan godkänna en annan effekt än den som exekveras.	Approval signerar resource/action/parameterhash, tenant, expiry och policyversion.
Agentåtgärder loggas bara som användaren	Delegation och systembeteende kan inte särskiljas.	Logga subject, current actor, workload och hela audit-only-kedjan separat.

Operativt kostar detta:

• extra latency och availability engineering för PDP,
• bundle-/relationreplikering och revokationssignaler,
• policy schema, lint, simulering och rollback,
• identity onboarding per kund och nationell cloud-partition,
• tenantceller, separata BI-workspaces/modeller och refreshkapacitet,
• långsiktig evidence retention och privacy controls,
• testmatrisen principals × tenants × resources × actions × channels × policy versions.

Open/self-hosted minskar inte automatiskt lock-in. Rego-, Cedar- och FGA-modeller är semantiskt olika. AuthZEN standardiserar beslutstids-API:t men ännu inte policyadministration eller ett portabelt policyspråk.

Implications for Dataheart

1. Definiera Dataheart Authorization Profile. Profilera AuthZEN med tenant, actor chain, policyrevision, obligations, freshness och evidence IDs.

2. Gör tenant till en typad säkerhetsgräns. Alla tenantbundna objekt, relationer, indexposter, cacheposter, rapportartefakter och actions ska bära tenant explicit.

3. Separera policy authoring från runtime enforcement. Kunden äger kanonisk policy-IR och relationsdata. Dataheart kompilerar endast en verifierad säker delmängd till RLS/BI/gateway-regler; övriga beslut går via PDP.

4. Inför ett enforcement capability registry. Varje kanal deklarerar vilka actions, attribut, obligations, consistency modes och deny semantics den faktiskt kan upprätthålla. Okänd capability får inte antas.

5. Bygg en action broker. Alla muterande agentverktyg går via task-scoped capability, step-up/approval vid behov, commit-time reevaluation och idempotent execution.

6. Behandla rekommendation och action olika. En agent får använda bredare läsunderlag för att rekommendera än den får använda för att exekvera. Resultatet måste sanitiseras till mottagarens egen policykontext.

7. Äg inte kundens root of trust. Kundens IdP, nycklar, policyrepo, relationship export, audit sink och revokationskontroll ska kunna fortsätta fungera eller återtas utan Kugghuset.

8. Gör profilerna semantiskt symmetriska. Microsoft-native och open behöver samma principal/resource/action-taxonomi, reason codes, policy fixtures och evidence format.

9. Var explicit om Microsoft-gapet. Entra/Fabric ger starka byggblock men ingen generell förstapartstjänst garanterar identisk affärsauktorisation över Power BI, egna API:er, SQL och agentverktyg. Datahearts adapter- och conformance-lager är därför load-bearing.

10. Skydda kundägandet mot framtida lock-in. Exportera policy-IR, tuples, principal mappings och evidence i dokumenterade versionerade format; håll Microsoft-ID:n och enginespecifika uttryck i adapters.

Connections to other domains

• Distribuerade databaser: grant/revoke är konsistensoperationer; causal/read-after-write-semantik påverkar säkerhet.
• Kompilatorteknik: canonical policy → kanalpolicy behöver typkontroll, semantisk diff och bevis att översättningen inte vidgar access.
• Safety engineering: deny, indeterminate, step-up och two-person approval motsvarar interlocks och safe states.
• Capability security: en task capability begränsar confused-deputy-risken bättre än en generell agentroll.
• Supply-chain security: policybundles och modeller bör signeras, attesteras, versioneras och kunna reproduceras.
• Event sourcing: decision- och actionrecords bildar en revisionsbar följd, men måste kompletteras med faktisk external effect.
• Privacy engineering: korrekta accesslogs kan själva bli en känslig beteendedatabas; minimera attribut och separera operativ observability från compliance retention.
• AI governance: För high-risk AI kräver den konsoliderade EU AI Act bland annat logging, human oversight, robusthet och cybersäkerhet. Samma kontroller är användbara även när en Dataheart-agent inte rättsligt klassas som high-risk.

Recommended experiments and conformance tests

Prioriterad ordning:

1. Cross-surface golden corpus

   Kör minst samma subject/actor/tenant/resource/action/context mot API, SQL/RLS, BI, sök och agentverktyg. Pass: ingen kanal får returnera allow eller data när den kanoniska förväntningen är deny.

2. Tenant noninterference property test

   Generera resurser och relationer för flera tenants, inklusive kolliderande lokala ID:n, felaktiga route-tenants, public relations och cacheträffar. Pass: noll cross-tenant-data, metadata, counts, felmeddelandeidentifierare eller actions.

3. Delegation downgrade test

   Ta bort eller manipulera actor, workload, audience, tenant och delegation scope i varje downstream-hopp. Pass: deny; aldrig fallback till app-only eller subject-only.

4. Token validation fuzzing

   Testa fel issuer, audience, token type, azp/client_id, duplicerade claims, key rotation, clock skew, expired/not-before och user/client namespace collision. Pass: strikt deny med stabil reason code.

5. Revocation SLA

   Mät från disable/group removal/risk event/tuple revoke till deny i varje kanal. Provisoriskt mål: high-impact action använder strong check och deny under partition; read-cache har dokumenterad maximal staleness, initialt högst 60 sekunder.

6. PDP- och signalpartition

   Stoppa PDP, bundle server, CAEP receiver och relationship store separat. Pass: writes/actions deny; endast fördeklarerade lågklassade reads får använda signerad last-known-good policy.

7. Grant/revoke causal test

   Skriv relationship och affärsobjekt i olika ordning och läs omedelbart från flera regioner. Pass: inget objekt exponeras före grant; revoke för kritiska actions kräver strong/higher-consistency path.

8. RLS/CLS/OLS-bypass suite

   Testa owner, superuser, workspace admin/member/contributor, connection pool context reuse, exports, refreshjobs, DirectQuery, materialiserade vyer och tredjepartsmotorer. Pass: varje dokumenterad bypass är antingen blockerad eller klassad som trusted admin plane med separat audit.

9. Action TOCTOU

   Ändra tenantmembership, resource state, approval eller parameter efter rekommendation men före commit. Pass: capability-/parameterhash eller commit-time reevaluation stoppar effekten.

10. Policy rollout safety

    Kör old/new revision samtidigt, saknad bundle, ogiltig signatur och rollback. Pass: ingen osignerad eller okänd revision aktiveras; beslutet anger exakt policy digest.

11. Profile equivalence

    Kör samma fixtures i Microsoft-native och self-hosted/open. Pass: identiskt allow/deny och obligations för den portabla kärnan; avvikelser dokumenteras som explicit profile capability, inte dold semantik.

12. Scale and cost benchmark

    Mät P50/P95/P99 för local PDP, remote PDP, ReBAC depth, batch/list/search, BI-query och action commit. Provisoriska mål att verifiera: lokal enkelcheck ≤20 ms P99 och remote check ≤100 ms P99 utan att sänka säkerhetskonsistensen.

13. Evidence reconstruction

    Välj en action och återskapa efteråt vem/vad/för-vem/tenant/policy/approval/parameter/result. Pass: full rekonstruktion utan rå access token eller ovidkommande persondata.

14. Break-glass

    Testa tidsbegränsad tvåpersonersaktivering, separat identitet, notifiering, eftergranskning och automatisk revokation. Pass: break-glass kan aldrig ske tyst eller bli permanent genom cache.

Sources

1. NIST SP 800-207 — Zero Trust Architecture, 10 augusti 2020; uppdaterad 23 mars 2021.
2. NIST SP 800-63-4 — Digital Identity Guidelines, 1 augusti 2025.
3. IETF RFC 9700 — Best Current Practice for OAuth 2.0 Security, januari 2025.
4. IETF RFC 8693 — OAuth 2.0 Token Exchange, januari 2020.
5. OpenID AuthZEN Authorization API 1.0 Final, 11 januari 2026.
6. OpenID Continuous Access Evaluation Profile 1.0 Final, 29 augusti 2025.
7. SPIFFE Standard, version 1.15.2, aktuell version kontrollerad 23 augusti 2026.
8. Google/USENIX — Zanzibar: Google’s Consistent, Global Authorization System, juli 2019.
9. Open Policy Agent — External Data, dokumentation kontrollerad 23 augusti 2026.
10. OpenFGA — Query Consistency Modes, dokumentation kontrollerad 23 augusti 2026.
11. PostgreSQL 18 — Row Security Policies, aktuell dokumentation kontrollerad 23 augusti 2026.
12. Microsoft Entra — Workload Identity Federation, dokumentation kontrollerad 23 augusti 2026.
13. Microsoft Fabric — OneLake table, column and row-level security, uppdaterad 27 juli 2026.
14. Microsoft Entra Agent ID — What are agent identities?, uppdaterad 15 juni 2026.
15. Regulation (EU) 2024/1689 — Artificial Intelligence Act, consolidated text, ursprungligen publicerad 12 juli 2024; konsoliderad 27 juli 2026.