ROLGEBASEERDE TOEGANGSCONTROLE RBAC: definitie, geschiedenis en voorbeelden

op rollen gebaseerde toegangscontrole

Dit artikel geeft een volledige uitleg van op rollen gebaseerd toegangsbeheer (RBAC) en een stapsgewijze handleiding voor het implementeren, onderhouden en uitbreiden van RBAC om aan de behoeften van uw organisatie te voldoen. U leert over rollen, hoe u ze definieert en hoe u ze kunt gebruiken om de toegang te reguleren om uw netwerk te beveiligen, administratieve kosten te verlagen en naleving van de regelgeving te garanderen. We zullen ook enkele voorbeelden zien van op rollen gebaseerd toegangsbeheer. Laten we beginnen.

Wat is op rollen gebaseerde toegangscontrole (RBAC)?

Het concept van het verlenen van machtigingen aan mensen op basis van hun rol binnen een organisatie wordt op rollen gebaseerd toegangsbeheer (RBAC) genoemd. Het biedt een eenvoudige, gecontroleerde benadering van toegangsbeheer die minder foutgevoelig is dan het individueel verlenen van machtigingen aan gebruikers.

Wanneer u RBAC gebruikt voor Roltoegangsbeheer, onderzoekt u de eisen van uw gebruikers en groepeert u ze in rollen op basis van gedeelde taken. Vervolgens wijst u voor elke gebruiker een of meer rollen en een of meer machtigingen toe aan elke rol. Omdat gebruikers niet langer willekeurig beheerd hoeven te worden, maken de relatie tussen gebruiker en rol en rolmachtigingen het eenvoudig om gebruikerstoewijzingen uit te voeren.

Geschiedenis van op rollen gebaseerde toegangscontrole

Sinds minstens de jaren zeventig hebben mensen rollen en verantwoordelijkheden gebruikt om de toegang tot commerciële computersystemen te controleren. Deze methoden waren echter ad hoc en moesten vaak per nieuw systeem worden aangepast.

Onderzoekers van het American National Standards Institute (NIST) begonnen pas in 1992 met het definiëren van het systeem dat bekend staat als op rollen gebaseerde toegangscontrole. In datzelfde jaar publiceerden Ferraiolo en Kuhn een paper waarin een algemeen toegangscontrolemechanisme werd gedefinieerd dat geschikt is voor civiele en commercieel gebruik, de basis leggen voor het model dat we vandaag gebruiken.

Gedurende de jaren negentig en het begin van de jaren 1990 verfijnden Ferraiolo, Kuhn en anderen RBAC, voortbouwend op eerder werk om de economische voordelen van RBAC te onderzoeken, een uniform model te specificeren en, belangrijker nog, de verdeling van taakvormen te definiëren. RBAC werd in 2000 officieel door NIST aangenomen als industriestandaard.

Hoe werkt op rollen gebaseerde toegangscontrole RBAC?

Voordat RBAC in een bedrijf wordt geïmplementeerd, moet de organisatie de machtigingen voor elke rol grondig specificeren. Dit omvat het nauwkeurig specificeren van machtigingen in de onderstaande categorieën:

  • Permissies voor het wijzigen van gegevens (bijv. lezen, schrijven, volledige toegang)
  • Toegang om bedrijfssoftware te gebruiken
  • Machtigingen binnen een programma

Om het meeste uit RBAC te halen, moet u eerst rollen en machtigingen modelleren. Het toewijzen van alle verantwoordelijkheden van het personeel aan bepaalde functies die passende privileges opleveren, maakt hier deel van uit. De organisatie kan dan posities toewijzen op basis van de taken van de medewerkers.

Organisaties kunnen op rollen gebaseerd toegangsbeheer gebruiken om een ​​of meer rollen toe te wijzen aan elke gebruiker of om afzonderlijk machtigingen toe te wijzen. Het idee is om machtigingen in te stellen waarmee gebruikers hun taken kunnen uitvoeren zonder aanvullende aanpassingen aan te brengen.

Identity and Access Management (IAM)-technologieën worden door organisaties gebruikt om RBAC te implementeren en te bewaken. IAM bedient voornamelijk grote organisaties door alle identiteiten en machtigingen te loggen, te bewaken en bij te werken. Het proces van het toewijzen van toestemming staat bekend als 'provisioning' en het proces van het intrekken van toestemming staat bekend als 'deprovisioning'. Een dergelijk systeem vereist het opzetten van een uniform en gestandaardiseerd rollenpakket.

Wat is een op rollen gebaseerde RBAC-rol voor toegangscontrole?

Rollen zijn semantiek binnen de RBAC-architectuur die organisaties kunnen gebruiken om hun privileges op te bouwen. Autoriteit, verantwoordelijkheid, kostenplaats, business unit en andere factoren kunnen worden gebruikt om rollen te definiëren.

Een rol is een groepering van gebruikersrechten. Traditionele groepen, die verzamelingen van gebruikers zijn, zijn niet hetzelfde als rollen. Machtigingen zijn niet direct gerelateerd aan identiteiten in de context van RBAC, maar eerder aan rollen. Omdat ze zijn georganiseerd rond toegangsbeheer, zijn rollen betrouwbaarder dan groepen. Identiteit verandert vaker dan kenmerken en activiteiten in een normaal bedrijf.

Het op rollen gebaseerde toegangscontrole RBAC-model

De RBAC-standaard definieert drie vormen van toegangscontrole: kern, hiërarchisch en beperkt.

#1. Kern-RBAC

Het kernmodel definieert de belangrijkste componenten van elk op rollen gebaseerd toegangscontrolesysteem. Hoewel fundamentele RBAC kan worden gebruikt als een op zichzelf staande benadering voor toegangscontrole, dient het ook als de basis voor zowel hiërarchische als beperkte modellen.

Als gevolg hiervan moeten alle RBAC's de drie onderstaande regels volgen:

  • Rolselectie of opdracht: Een persoon kan een vergunning alleen uitoefenen als hij of zij een rol heeft gekozen of is toegewezen.
  • Rol autorisatie: De actieve rol van een proefpersoon moet worden geautoriseerd.
  • Autorisatie van machtigingen: Een proefpersoon kan alleen machtigingen uitoefenen die zijn toegestaan ​​voor de actieve rol van de proefpersoon.

#2. Hiërarchie RBAC

Door te geloven dat uw verdediging al is geschonden, kunt u een sterkere beveiligingshouding aannemen tegen mogelijke aanvallen, waardoor het effect van een inbreuk wordt verminderd. Beperk de "explosiestraal" van mogelijke schade veroorzaakt door een inbreuk door de toegang te segmenteren en uw aanvalsoppervlak te verkleinen, end-to-end-codering te bevestigen en uw netwerk in realtime te bewaken.

#3. Beperkte RBAC

Deze derde RBAC-standaard breidt de rolverdeling van het kernmodel uit. Functiescheidingsrelaties worden geclassificeerd als statisch of dynamisch.

  • Een enkele gebruiker kan geen wederzijds uitsluitende verantwoordelijkheden hebben in relaties met statische scheiding van taken (SSD) (zoals gedefinieerd door de organisatie). Dit zorgt ervoor dat bijvoorbeeld één persoon een aankoop niet zowel kan doen als goedkeuren.
  • Een gebruiker volgens het Dynamic Separation of Duty (DSD)-model kan tegenstrijdige rollen hebben. De gebruiker mag echter niet beide taken in dezelfde sessie uitvoeren. Deze beperking helpt bij het beheersen van interne beveiligingsproblemen door bijvoorbeeld de tweepersoonsregel te implementeren, die twee unieke gebruikers vereist om een ​​actie te autoriseren.

Voorbeelden van op rollen gebaseerde toegangscontrole

Met RBAC kunt u bepalen wat eindgebruikers kunnen doen op zowel het brede als het gedetailleerde niveau. U kunt specificeren of de gebruiker een beheerder, een gespecialiseerde gebruiker of een eindgebruiker is, en u kunt verantwoordelijkheden en toegangsrechten afstemmen op de organisatorische functies van uw medewerkers. Machtigingen worden alleen verleend met voldoende toegang voor medewerkers om hun taken uit te voeren.

Wat als de beschrijving van een eindgebruiker van een eindgebruiker verandert? Mogelijk moet u hun rol handmatig aan een andere gebruiker toewijzen, of u kunt rollen toewijzen aan een rollengroep of een roltoewijzingsbeleid gebruiken om rolgroepleden toe te voegen of te verwijderen.

Een RBAC-tool kan de volgende aanduidingen bevatten:

  • Bereik van beheerrol – het beperkt welke items de rollengroep aankan.
  • Beheerrolgroep – U kunt leden toevoegen aan en verwijderen uit de beheerrolgroep.
  • Management rol – dit zijn de soorten taken die een bepaalde rolgroep kan volbrengen.
  • Toewijzing van managementrollen- Dit is het proces van het toewijzen van een rol aan een rollengroep.

Wanneer een gebruiker wordt toegevoegd aan een rollengroep, krijgt de gebruiker toegang tot alle rollen in die groep. Wanneer ze worden verwijderd, is de toegang beperkt. Gebruikers kunnen ook aan meerdere groepen worden toegewezen als ze tijdelijke toegang tot specifieke gegevens of applicaties nodig hebben en vervolgens worden verwijderd nadat het project is voltooid.

Andere mogelijkheden voor gebruikerstoegang kunnen zijn:

  • De belangrijkste contactpersoon voor een bepaalde account of rol.
  • Facturering – toegang tot een factureringsaccount voor één eindgebruiker.
  • Technische gebruikers zijn degenen die technische taken uitvoeren.
  • Administratieve toegang wordt verleend aan gebruikers die administratieve activiteiten uitvoeren.

RBAC-alternatieven: typen toegangscontrole

Andere toegangscontrolemechanismen zouden kunnen worden gebruikt in plaats van op rollen gebaseerde toegangscontrole.

Toegangscontrolelijst (ACL)

Een toegangsbeheerlijst (ACL) is een tabel met de machtigingen die zijn gekoppeld aan computerbronnen. Het informeert het besturingssysteem welke gebruikers toegang hebben tot een object en welke acties ze erop kunnen ondernemen. Elke gebruiker heeft een item dat is gekoppeld aan de beveiligingseigenschappen van elk item. Voor klassieke DAC-systemen wordt meestal ACL gebruikt.

ACL versus RBAC

In termen van beveiliging en administratieve kosten presteert RBAC beter dan ACL voor de meeste zakelijke toepassingen. ACL is geschikter voor het implementeren van beveiliging op individueel gebruikersniveau en voor gegevens op laag niveau, maar RBAC is beter geschikt voor een bedrijfsbreed beveiligingssysteem onder toezicht van een beheerder. Een ACL kan bijvoorbeeld schrijftoegang tot een bepaald bestand inschakelen, maar kan niet definiëren hoe het bestand door de gebruiker wordt gewijzigd.

Op attributen gebaseerde toegangscontrole (ABAC)

ABAC beoordeelt een reeks regels en beleidsregels om toegangsrechten te controleren op basis van bepaalde kwaliteiten, zoals omgevings-, systeem-, object- of gebruikersinformatie. Het gebruikt booleaanse logica om mensen toegang toe te staan ​​of te weigeren op basis van een gecompliceerde evaluatie van atomaire of vaste waarden en hun relaties.

In de praktijk stelt dit u in staat om in eXtensible Access Control Markup Language (XACML) regels te definiëren die gebruik maken van sleutel-waardecombinaties zoals Role=Manager en Category=Financial.

ABAC versus RBAC

RBAC is gebaseerd op vooraf gedefinieerde rollen, terwijl ABAC dynamischer is en op relatie gebaseerde toegangscontrole gebruikt. RBAC kan worden gebruikt om toegangscontrole in grote lijnen te definiëren, terwijl ABAC meer granulariteit biedt. Een RBAC-systeem geeft bijvoorbeeld toegang aan alle managers, terwijl een ABAC-beleid alleen toegang geeft aan managers op de financiële afdeling. ABAC doet een meer gecompliceerde zoekopdracht, die meer verwerkingskracht en tijd vereist, dus gebruik het alleen wanneer RBAC onvoldoende is.

RBAC-voordelen:

  • Het beheer en de controle van netwerktoegang zijn van cruciaal belang voor informatiebeveiliging. Toegang kan en moet worden toegestaan ​​op basis van 'need-to-know'. Beveiliging kan gemakkelijker worden beheerd met honderden of duizenden werknemers door onnodige toegang tot kritieke informatie te beperken op basis van de aangegeven rol van elke gebruiker binnen het bedrijf. Andere voordelen zijn onder meer:
  • De administratieve en IT-ondersteuning wordt verminderd. Wanneer een werknemer wordt aangenomen of van rol verandert, kunt u RBAC gebruiken om de vereiste voor papierwerk en wachtwoordwijzigingen te verminderen. In plaats daarvan kunt u RBAC gebruiken om snel rollen toe te voegen en over te dragen tussen besturingssystemen, platforms en toepassingen. Het verkleint ook de kans op fouten bij het verlenen van gebruikersrechten. Een van de vele economische voordelen van RBAC is de vermindering van de tijd die aan administratieve activiteiten wordt besteed. RBAC vergemakkelijkt ook de integratie van externe gebruikers in uw netwerk door hen vooraf gedefinieerde rollen toe te wijzen.
  • Verhogen van de operationele efficiëntie. RBAC biedt een gestroomlijnde aanpak met logische definities. In plaats van te proberen toegangscontrole op een lager niveau te beheren, kunnen alle rollen worden afgestemd op de organisatiestructuur van het bedrijf, zodat gebruikers hun taken efficiënter en autonoom kunnen uitvoeren.
  • Toenemende naleving. Federale, staats- en gemeentelijke beperkingen zijn van toepassing op alle organisaties. Bedrijven kunnen gemakkelijker voldoen aan wettelijke en regelgevende normen voor privacy en vertrouwelijkheid met een RBAC-systeem, omdat IT-afdelingen en leidinggevenden kunnen bepalen hoe gegevens worden geopend en gebruikt. Dit is vooral belangrijk voor zorg- en financiële organisaties, die een grote hoeveelheid gevoelige gegevens verwerken, zoals PHI en PCI.

Best practices voor RBAC-implementatie

Het implementeren van een RBAC in uw organisatie moet niet lichtvaardig gebeuren. Er zijn een aantal algemene stappen die moeten worden genomen om het team aan boord te krijgen zonder onnodige verwarring of irritaties op de werkplek te veroorzaken. Hier zijn een paar ideeën om mee te beginnen.

  • Huidige status: Maak een lijst van elk stukje software, hardware en app dat beveiligd is. De meeste hiervan hebben een wachtwoord nodig. U kunt echter ook serverruimtes opnemen die achter slot en grendel zitten. Fysieke beveiliging kan een belangrijk onderdeel zijn van gegevensbescherming. Geef ook op wie toegang heeft tot elk van deze programma's en plaatsen. Dit geeft u een glimp van uw huidige gegevenssituatie.
  • Huidige taken: Zelfs als je geen formeel rooster en een lijst met rollen hebt, kan het bepalen van wat elk individueel teamlid doet zo simpel zijn als een kort gesprek. Probeer het team zo in te richten dat het de creativiteit of de huidige cultuur niet in de weg staat (indien genoten).
  • Maak een beleid: Alle wijzigingen moeten worden gedocumenteerd zodat alle huidige en toekomstige werknemers ze kunnen bekijken. Zelfs als u een RBAC-oplossing gebruikt, kunt u problemen voorkomen als u een document heeft dat uw nieuwe systeem duidelijk verwoordt.
  • Wijzigingen: Zodra de huidige beveiligingsstatus en -rollen bekend zijn (en er een beleid is), is het tijd om de wijzigingen door te voeren.
  • Voortdurend aanpassen: Het is waarschijnlijk dat de eerste RBAC-iteratie enige aanpassing nodig heeft. In het begin moet u regelmatig uw taken en beveiligingsstatus beoordelen. Beoordeel eerst hoe goed uw creatieve/productieproces werkt en vervolgens hoe veilig uw proces is.

Conclusie

Gegevensbescherming is een essentiële zakelijke functie voor elk bedrijf. Een RBAC-systeem kan ervoor zorgen dat de bedrijfsinformatie voldoet aan de privacy- en vertrouwelijkheidswetten. Bovendien kan het essentiële bedrijfsactiviteiten beveiligen, zoals toegang tot intellectueel eigendom, wat een concurrentie-impact heeft op de organisatie.

Veelgestelde vragen over op rollen gebaseerde toegangscontrole

Wat zijn de drie primaire regels voor RBAC?

RBAC-componenten zoals rolmachtigingen, gebruikersrol- en rol-rolrelaties maken gebruikerstoewijzingen eenvoudig.

Waarom wordt ACL gebruikt?

Minder netwerkverkeer voor verbeterde netwerkprestaties. Een netwerkbeveiligingsniveau dat aangeeft tot welke delen van de server/het netwerk/de dienst een gebruiker wel en niet toegang heeft. Gedetailleerd volgen van verkeer dat het systeem binnenkomt en verlaat.

Wat is het verschil tussen op rollen gebaseerde toegangscontrole en op regels gebaseerde toegangscontrole?

Toegangsniveaus voor werknemers worden niet bepaald door op regels gebaseerde toegangscontroles, die preventief van aard zijn. Ze werken in plaats daarvan om ongewenste toegang te voorkomen. Op rollen gebaseerde modellen zijn proactief omdat ze werknemers een reeks voorwaarden bieden waaronder ze goedgekeurde toegang kunnen krijgen.

Referenties

Laat een reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd *

Dit vind je misschien ook leuk