Attributbaserad åtkomstkontroll

Attributbaserad åtkomstkontroll ( ABAC ), även känd som policybaserad åtkomstkontroll för IAM , definierar ett åtkomstkontrollparadigm där en subjekts behörighet att utföra en uppsättning operationer bestäms genom att utvärdera attribut associerade med ämnet, objektet, begärda operationer, och, i vissa fall, miljöattribut.

ABAC är en metod för att implementera åtkomstkontrollpolicyer som är mycket anpassningsbar och kan anpassas med ett brett utbud av attribut, vilket gör den lämplig för användning i distribuerade eller snabbt föränderliga miljöer. De enda begränsningarna för policyerna som kan implementeras med ABAC är beräkningsspråkets möjligheter och tillgången på relevanta attribut. ABAC-policyregler genereras som booleska funktioner av subjektets attribut, objektets attribut och miljöattribut.

Till skillnad från rollbaserad åtkomstkontroll (RBAC) , som definierar roller som har en specifik uppsättning privilegier som är kopplade till dem och till vilka ämnen är tilldelade, kan ABAC uttrycka komplexa regeluppsättningar som kan utvärdera många olika attribut. Genom att definiera konsekventa ämnes- och objektattribut i säkerhetspolicyer eliminerar ABAC behovet av explicita auktoriseringar till individers ämnen som behövs i en icke-ABAC-åtkomstmetod, vilket minskar komplexiteten i att hantera åtkomstlistor och grupper.

Attributvärden kan vara inställda eller atomvärda. Uppsättningsvärdeattribut innehåller mer än ett atomvärde. Exempel är roll och projekt . Attribut med atomvärde innehåller bara ett atomvärde. Exempel är clearance och känslighet . Attribut kan jämföras med statiska värden eller med varandra, vilket möjliggör relationsbaserad åtkomstkontroll.

Även om själva konceptet har funnits i många år, anses ABAC vara en "nästa generations" auktoriseringsmodell eftersom det ger dynamisk, kontextmedveten och riskintelligent åtkomstkontroll till resurser som gör det möjligt för åtkomstkontrollpolicyer som inkluderar specifika attribut från många olika informationssystem. definieras för att lösa en auktorisation och uppnå en effektiv regelefterlevnad, vilket ger företag flexibilitet i sina implementeringar baserat på deras befintliga infrastruktur.

Attributbaserad åtkomstkontroll kallas ibland för policybaserad åtkomstkontroll ( PBAC ) eller anspråksbaserad åtkomstkontroll ( CBAC ), vilket är en Microsoft-specifik term. De viktigaste standarderna som implementerar ABAC är XACML och ALFA (XACML) .

Dimensioner för attributbaserad åtkomstkontroll

ABAC kan ses som:

Externiserad behörighetshantering
Dynamisk behörighetshantering
Policybaserad åtkomstkontroll
Finkornig auktorisation

Komponenter

Arkitektur

ABAC kommer med en rekommenderad arkitektur som är följande:

PEP eller Policy Enforcement Point: det är ansvarigt för att skydda de appar och data som du vill använda ABAC till. PEP inspekterar begäran och genererar en auktorisationsbegäran från vilken den skickar till PDP.
PDP eller Policy Decision Point är hjärnan i arkitekturen. Detta är delen som utvärderar inkommande förfrågningar mot policyer som den har konfigurerats med. PDP returnerar ett Permit/Ny-beslut. PDP kan också använda PIP:er för att hämta saknade metadata
PIP eller Policy Information Point överbryggar PDP till externa källor för attribut, t.ex. LDAP eller databaser.

Attribut

Attribut kan handla om vad som helst och vem som helst. De tenderar att delas in i fyra olika kategorier:

Ämnesattribut: attribut som beskriver användaren som försöker få åtkomst, t.ex. ålder, tillstånd, avdelning, roll, befattning
Åtgärdsattribut: attribut som beskriver den åtgärd som utförs, t.ex. läsa, ta bort, visa, godkänna
Objektattribut: attribut som beskriver objektet (eller resursen) som nås, t.ex. objekttypen (journal, bankkonto), avdelningen, klassificeringen eller känsligheten, platsen
Kontextuella (miljö)attribut: attribut som behandlar tid, plats eller dynamiska aspekter av åtkomstkontrollscenariot

Policyer

Policyer är uttalanden som sammanför attribut för att uttrycka vad som kan hända och inte är tillåtet. Policyer i ABAC kan vara att bevilja eller neka policyer. Policyer kan också vara lokala eller globala och kan skrivas på ett sätt så att de åsidosätter andra policyer. Exempel inkluderar:

En användare kan se ett dokument om dokumentet finns på samma avdelning som användaren
En användare kan redigera ett dokument om de är ägare och om dokumentet är i utkastläge
Neka åtkomst före kl. 9.00

Med ABAC kan du ha så många policyer som du vill som tillgodoser många olika scenarier och tekniker.

Andra modeller

Historiskt sett har åtkomstkontrollmodeller inkluderat obligatorisk åtkomstkontroll (MAC), diskretionär åtkomstkontroll (DAC) och på senare tid rollbaserad åtkomstkontroll (RBAC). Dessa åtkomstkontrollmodeller är användarcentrerade och tar inte hänsyn till ytterligare parametrar såsom resursinformation, förhållandet mellan användaren (den begärande enheten) och resursen, och dynamisk information, t.ex. tid på dagen eller användarens IP.

ABAC försöker åtgärda detta genom att definiera åtkomstkontroll baserat på attribut som beskriver den begärande enheten (användaren), målobjektet eller resursen, den önskade åtgärden (visa, redigera, ta bort) och miljö- eller kontextuell information. Det är därför åtkomstkontroll sägs vara attributbaserad.

Genomföranden

En standard som implementerar attribut- och policybaserad åtkomstkontroll är XACML , eXtensible Access Control Markup Language. XACML definierar en arkitektur, ett policyspråk och ett förfrågnings-/svarsschema. Den hanterar inte attributhantering (tilldelning av användarattribut, tilldelning av objektattribut, tilldelning av miljöattribut) som överlåts till traditionella IAM -verktyg, databaser och kataloger.

Företag, inklusive alla grenar i den amerikanska militären, har börjat använda ABAC. På en grundläggande nivå skyddar ABAC data med 'OM/DÅ/OCH'-regler snarare än att tilldela data till användare. Det amerikanska handelsdepartementet har gjort detta till en obligatorisk praxis och antagandet sprider sig till flera statliga och militära organ.

Ansökningar

Konceptet ABAC kan tillämpas på alla nivåer av teknikstacken och en företagsinfrastruktur. Till exempel kan ABAC användas på brandväggen, servern, applikationen, databasen och datalagret. Användningen av attribut ger ytterligare sammanhang för att utvärdera legitimiteten av varje begäran om tillgång och informera beslutet att bevilja eller neka tillgång.

En viktig faktor när man utvärderar ABAC-lösningar är att förstå dess potentiella overhead på prestanda och dess inverkan på användarupplevelsen. Det förväntas att ju mer granulär kontrollerna är, desto högre blir overheaden.

API och mikrotjänster säkerhet

ABAC kan användas för att tillämpa attributbaserad, finkornig auktorisering på API-metoderna eller funktionerna. Till exempel kan ett bank-API exponera en approveTransaction(transId)-metod. ABAC kan användas för att säkra samtalet. Med ABAC kan en policyförfattare skriva följande:

Policy : chefer kan godkänna transaktioner upp till deras godkännandegräns
Använda attribut : roll, åtgärds-ID, objekttyp, belopp, godkännandegräns.

Flödet skulle se ut som följer:

Användaren, Alice, anropar API-metoden approveTransaction(123)
API:et tar emot anropet och autentiserar användaren.
En interceptor i API:t ropar till auktoriseringsmotorn (kallas vanligtvis en Policy Decision Point eller PDP) och frågar: Kan Alice godkänna transaktion 123?
PDP hämtar ABAC-policyn och nödvändiga attribut.
PDP:n når ett beslut, t.ex. Permit eller Deny, och returnerar det till API-interceptorn
Om beslutet är Permit, anropas den underliggande API-affärslogiken. Annars returnerar API:et ett fel eller nekad åtkomst.

Applikationssäkerhet

En av de viktigaste fördelarna med ABAC är att auktorisationspolicyerna och attributen kan definieras på ett teknikneutralt sätt. Detta innebär att policyer som definierats för API:er eller databaser kan återanvändas i applikationsutrymmet. Vanliga applikationer som kan dra nytta av ABAC är:

Content Management System
ERP:er
Hemodlade applikationer
Webbapplikationer

Samma process och flöde som den som beskrivs i API-avsnittet gäller även här.

Databassäkerhet

Säkerhet för databaser har länge varit specifik för databasleverantörerna: Oracle VPD, IBM FGAC och Microsoft RLS är alla sätt att uppnå finkornig ABAC-liknande säkerhet.

Ett exempel skulle vara:

Policy: chefer kan se transaktioner i sin region
Omarbetad policy på ett datacentrerat sätt: användare med roll == manager kan göra åtgärden SELECT på tabellen == TRANSACTIONS om user.region == transaktion.region

Datasäkerhet

Datasäkerhet går vanligtvis ett steg längre än databassäkerhet och tillämpar kontroll direkt på dataelementet. Detta kallas ofta för datacentrerad säkerhet. På traditionella relationsdatabaser kan ABAC-policyer kontrollera åtkomst till data i tabellen, kolumnen, fältet, cellen och undercellen med hjälp av logiska kontroller med filtreringsvillkor och maskering baserad på attribut. Attribut kan vara data, användare, session eller verktyg baserade för att ge största möjliga flexibilitet när det gäller att dynamiskt bevilja/neka åtkomst till ett specifikt dataelement. På big data och distribuerade filsystem som Hadoop, tillämpas ABAC på datalagret för åtkomst till mapp, undermapp, fil, underfil och annat detaljerat.

Stor datasäkerhet

Attributbaserad åtkomstkontroll kan också tillämpas på Big Data-system som Hadoop. Policyer liknande de som användes tidigare kan tillämpas vid hämtning av data från datasjöar.

Filserversäkerhet

Från och med Windows Server 2012 har Microsoft implementerat en ABAC-metod för att kontrollera åtkomst till filer och mappar. Detta uppnås genom dynamisk åtkomstkontroll (DAC) och Security Descriptor Definition Language (SDDL). SDDL kan ses som ett ABAC-språk eftersom det använder metadata från användaren (påståenden) och filen/mappen för att kontrollera åtkomsten.

Se även

externa länkar