{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://atlas.maintz.dev/)"},"id":"cs/access-control","url":{"en":"https://atlas.maintz.dev/en/terms/cs/access-control/","da":"https://atlas.maintz.dev/da/terms/cs/access-control/"},"term":{"en":"Access control","da":"Adgangskontrol"},"aka":{"en":[],"da":[]},"domain":["cs","security"],"cluster":"identity","layer":"identity","status":"current","era":1971,"summary":{"en":"The rules and mechanisms that decide who may use which systems, data or rooms, and in what way.","da":"De regler og mekanismer, der afgør, hvem der må bruge hvilke systemer, data eller lokaler, og på hvilken måde."},"body":{"formal":{"en":"The enforcement of a policy on every request to use a resource, combining authentication (who is asking) with authorization (what they may do) to allow or refuse it. It covers digital resources and physical ones such as doors and server rooms.","da":"Håndhævelsen af en politik ved hver anmodning om at bruge en ressource, hvor autentificering (hvem spørger) og autorisation (hvad må vedkommende) tilsammen afgør, om den tillades eller afvises. Det gælder både digitale ressourcer og fysiske som døre og serverrum."},"plain":{"en":"Like the whole door system of an office building - the key-card readers, the list of who may enter which floor, and the lock that actually holds the door shut.","da":"Som hele dørsystemet i en kontorbygning - kortlæserne, listen over, hvem der må komme på hvilken etage, og låsen, der faktisk holder døren lukket."},"inPractice":{"en":"At a Danish regional hospital, nurses can open records only for patients on their own ward; the patient record system checks every lookup against that rule and logs each refused attempt.","da":"På et regionshospital kan sygeplejersker kun åbne journaler for patienter på deres eget afsnit; journalsystemet tjekker hvert opslag mod den regel og logger alle afviste forsøg."},"whyItMatters":{"en":"It is where the confidentiality and integrity of data are actually enforced; without it, every security policy is just words on paper.","da":"Det er her, dataenes fortrolighed og integritet rent faktisk håndhæves; uden den er enhver sikkerhedspolitik blot ord på papir."}},"deepDive":{"en":"The theoretical baseline is Lampson's access matrix (1971): subjects as rows, objects as columns, and a set of rights in each cell. Real systems never store the matrix; they slice it either by column, giving access control lists attached to objects (Unix mode bits, POSIX ACLs, NTFS DACLs, S3 bucket policies), or by row, giving capabilities held by subjects (file descriptors, object-capability references, bearer tokens). The 1972 Anderson report added the reference monitor concept: the enforcing component must be invoked on every access (complete mediation), be tamper-proof, and be small enough to verify. Those three properties are still the right yardstick for any enforcement point.\n\nPolicy models sit on top. Discretionary access control (DAC) lets the owner of an object grant rights, as with chmod. Mandatory access control (MAC) enforces system-wide labels the owner cannot override; Bell-LaPadula (\"no read up, no write down\") protects confidentiality and Biba protects integrity, and SELinux and AppArmor bring MAC to Linux. Role-based access control (ANSI INCITS 359-2004) routes permissions through roles, attribute-based access control (NIST SP 800-162) evaluates rules over subject, object, action and environment attributes, and relationship-based access control, popularised by Google's Zanzibar paper (2019), derives rights from a graph of relations such as owner, member and parent folder. Production systems usually combine several.\n\nArchitecturally, the XACML vocabulary is standard: a policy enforcement point (PEP) intercepts the request, a policy decision point (PDP) evaluates it, a policy information point (PIP) supplies attributes, and a policy administration point (PAP) manages rules. NIST SP 800-207 reuses the PEP/PDP split for Zero Trust. Externalised engines such as Open Policy Agent (Rego) or Cedar keep policy out of application code. Sound defaults are deny-by-default, enforcement on the server for every request and every object, fail-closed when the PDP is unreachable, and logging of both allow and deny decisions.\n\nFailures are common: Broken Access Control is A01 in both OWASP Top 10:2021 and Top 10:2025, covering insecure direct object references, missing function-level checks, forced browsing, tampered tokens and, from 2025, SSRF. The confused deputy problem (Hardy, 1988) shows how a privileged program can be tricked into spending its authority on behalf of a caller; time-of-check-to-time-of-use gaps and cached decisions that survive revocation are other classic faults. Access control is the per-request mechanism; access management is the lifecycle of granting, recertifying and removing rights. ISO/IEC 27001:2022 covers both in Annex A 5.15-5.18, with 7.2 for physical entry and 8.3 for information access restriction.","da":"Det teoretiske udgangspunkt er Lampsons adgangsmatrix (1971): subjekter som rækker, objekter som kolonner og et sæt rettigheder i hver celle. Ingen systemer gemmer selve matricen; de skærer den enten pr. kolonne, så man får adgangskontrollister knyttet til objekterne (Unix-tilladelsesbits, POSIX-ACL'er, NTFS-DACL'er, S3-bucketpolitikker), eller pr. række, så man får capabilities, som subjekterne holder (filbeskrivere, objekt-capabilities, bearer-tokens). Anderson-rapporten fra 1972 tilføjede begrebet reference monitor: Den håndhævende komponent skal kaldes ved hver eneste adgang (complete mediation), være beskyttet mod manipulation og være lille nok til at kunne verificeres. De tre egenskaber er stadig den rette målestok for ethvert håndhævelsespunkt.\n\nOven på det ligger politikmodellerne. Ved skønsmæssig adgangskontrol (DAC) kan ejeren af et objekt selv tildele rettigheder, som med chmod. Ved obligatorisk adgangskontrol (MAC) håndhæver systemet klassifikationsmærker, som ejeren ikke kan tilsidesætte; Bell-LaPadula (\"ingen læsning opad, ingen skrivning nedad\") beskytter fortrolighed, Biba beskytter integritet, og SELinux og AppArmor bringer MAC til Linux. Rollebaseret adgangskontrol (ANSI INCITS 359-2004) sender rettighederne gennem roller, attributbaseret adgangskontrol (NIST SP 800-162) evaluerer regler over attributter for subjekt, objekt, handling og omgivelser, og relationsbaseret adgangskontrol, kendt fra Googles Zanzibar-artikel (2019), udleder rettigheder fra en graf af relationer som ejer, medlem og overordnet mappe. Systemer i drift kombinerer som regel flere modeller.\n\nArkitekturen beskrives typisk med XACML's begreber: Et policy enforcement point (PEP) opfanger forespørgslen, et policy decision point (PDP) træffer afgørelsen, et policy information point (PIP) leverer attributter, og et policy administration point (PAP) forvalter reglerne. NIST SP 800-207 genbruger opdelingen i PEP og PDP til Zero Trust. Eksterne regelmotorer som Open Policy Agent (Rego) eller Cedar holder politikken ude af applikationskoden. Fornuftige standardvalg er afvisning som udgangspunkt, kontrol på serveren ved hver forespørgsel og for hvert objekt, afvisning hvis PDP'en ikke kan nås (fail closed), og logning af både tilladte og afviste afgørelser.\n\nFejlene er udbredte: Broken Access Control er A01 i både OWASP Top 10:2021 og Top 10:2025 og dækker usikre direkte objektreferencer (IDOR), manglende kontrol på funktionsniveau, forced browsing, manipulerede tokens og fra 2025 også SSRF. Confused deputy-problemet (Hardy, 1988) viser, hvordan et privilegeret program kan narres til at bruge sin egen myndighed på en kalders vegne; huller mellem kontrol og brug (TOCTOU) og cachede afgørelser, der overlever en tilbagekaldelse, er andre klassiske fejl. Adgangskontrol er mekanismen ved hver forespørgsel; adgangsstyring er livscyklussen med at tildele, recertificere og fjerne rettigheder. ISO/IEC 27001:2022 dækker begge i bilag A 5.15-5.18, med 7.2 for fysisk adgang og 8.3 for begrænsning af adgang til information."},"howTo":{"steps":{"en":["For each system, have the system owner write down the access rules in plain words - which roles or attributes may read, change or delete which data - and get them approved before anything is built.","Choose the model that fits the rules, such as roles for simple job-based access and attributes or relationships for rules like \"only patients on my own ward\", and write the choice into the design.","Put the check in one central enforcement point on the server, such as a middleware, API gateway or policy engine, instead of scattering if-statements through the code or relying on hiding buttons in the user interface.","Deny by default, so any request, page, file or API call without an explicit rule is refused, and make the system refuse access if the policy engine or directory cannot be reached.","Check the rights on every request and on every single record, not only at login, so a user cannot open another person's case by changing an ID in the URL.","Log both refused and allowed access to sensitive data with user, object and time, and alert on repeated refusals from the same account.","Write automated tests for the access rules, including attempts to reach other users' records and admin functions, and run them in the build pipeline on every change.","Test access control in every penetration test or code review, and review the rules with the system owner at least yearly and whenever the system changes."],"da":["Lad systemejeren skrive adgangsreglerne ned i klart sprog for hvert system - hvilke roller eller attributter der må læse, ændre eller slette hvilke data - og få dem godkendt, før der bygges noget.","Vælg den model, der passer til reglerne, fx roller til simpel jobbaseret adgang og attributter eller relationer til regler som \"kun patienter på mit eget afsnit\", og skriv valget ind i designet.","Placér kontrollen i ét centralt håndhævelsespunkt på serveren, fx en middleware, en API-gateway eller en policy engine, i stedet for at sprede if-sætninger ud i koden eller nøjes med at skjule knapper i brugerfladen.","Afvis som udgangspunkt, så enhver anmodning, side, fil eller API-kald uden en udtrykkelig regel bliver afvist, og lad systemet nægte adgang, hvis policy engine eller katalog ikke kan nås.","Tjek rettighederne ved hver anmodning og for hver enkelt post, ikke kun ved login, så en bruger ikke kan åbne en andens sag ved at ændre et ID i URL'en.","Log både afviste og tilladte opslag i følsomme data med bruger, objekt og tidspunkt, og alarmér ved gentagne afvisninger fra samme konto.","Skriv automatiske tests af adgangsreglerne, også forsøg på at nå andre brugeres data og administratorfunktioner, og kør dem i build-pipelinen ved hver ændring.","Test adgangskontrollen ved hver penetrationstest eller kodegennemgang, og gennemgå reglerne med systemejeren mindst en gang om året og hver gang systemet ændres."]},"pitfalls":{"en":["Hiding a menu item or button in the user interface but leaving the API behind it open to anyone who calls it directly.","Checking that a user is logged in without checking that the record they ask for is one they may see, which gives insecure direct object references.","Failing open, so everyone is let in when the policy engine, directory or permission lookup times out."],"da":["At skjule et menupunkt eller en knap i brugerfladen, men lade API'et bag den stå åbent for alle, der kalder det direkte.","At tjekke, at brugeren er logget ind, uden at tjekke, at den post, der bedes om, er en, brugeren må se, hvilket giver insecure direct object references.","At fejle åbent, så alle bliver lukket ind, når policy engine, katalog eller rettighedsopslag ikke svarer."]},"guides":[{"title":"Authorization Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html","publisher":"OWASP","tier":"reference"},{"title":"A01 Broken Access Control - OWASP Top 10:2025","url":"https://top10.owasp.org/2025/A01_2025-Broken_Access_Control","publisher":"OWASP","tier":"reference"},{"title":"NIST SP 800-162 - Guide to Attribute Based Access Control (ABAC) Definition and Considerations","url":"https://csrc.nist.gov/pubs/sp/800/162/upd2/final","publisher":"NIST","tier":"standard"},{"title":"Rettighedsstyring","url":"https://www.datatilsynet.dk/regler-og-vejledning/behandlingssikkerhed/rettighedsstyring","publisher":"Datatilsynet","tier":"official-doc","lang":"da"}]},"edges":[{"type":"requires","to":"cs/authentication","confidence":"high","strength":"normal"},{"type":"kind-of","to":"security/control","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"security/access-management","why":{"en":"Access control is the mechanism that allows or refuses each request; access management is the ongoing process of granting, reviewing and removing that access.","da":"Adgangskontrol er mekanismen, der tillader eller afviser hver anmodning; adgangsstyring er den løbende proces med at tildele, gennemgå og fjerne adgangen."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"cs/least-privilege","confidence":"high","strength":"normal"},{"type":"used-with","to":"ai/ai-agent","confidence":"high","strength":"normal"},{"type":"used-with","to":"ai/vector-database","why":{"en":"Retrieval must respect who may see which document: a vector database often holds copies of private files, so each lookup has to be filtered by the asking user's rights.","da":"Søgningen skal respektere, hvem der må se hvilket dokument: en vektordatabase rummer ofte kopier af fortrolige filer, så hvert opslag skal filtreres efter den spørgende brugers rettigheder."},"confidence":"medium","strength":"normal"}],"depth":3,"sources":[{"title":"NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations","url":"https://doi.org/10.6028/NIST.SP.800-162","tier":"standard","publisher":"NIST"}],"draft":true}