For full text search please use the '?' prefix. e.g. ? Onboarding

Role Based Access Control (RBAC)

Présentation 1

  • C'est une bonne pratique pour implementer un Acces Control (AC)
  • Le principe «à base de rôles» est ce qui le distingue des autres concepts de sécurité, par exemple du Mandatory Access Control (MAC)
  • les droits d'accès sont attribués à l'aide d'un modèle de rôles défini. Les rôles d'utilisateur établis séparent les processus de travail dans une organisation et varient donc. Les repères possibles pour une répartition adéquate sont les services, les sites, les centres de coûts ou les fonctions d'un collaborateur.
  • In RBAC, an access system determines who can access a resource rather than an owner.
  • Commonly, RBAC is used to restrict access based on business functions, e.g. engineers, human resources and marketing have access to different SaaS products
  • Dans des formes extrèmes (it's not because something is possible that it is a good idea), il peux être une forme de
  • 3 key entities
    • User or Subject
      • The actors of the system who perform operations. It can represent a physical person, an automated account, or even another application.
    • Role
      • Authority level defined by A job Title, Department or functional hierarchy.
    • Privilege
      • An approval or permission to perform operations

Présentation 2

If you work in a large organization, you can easily understand that the permissions if awarded user wise, could become a herculean task. Why not adopt a simple way then? The RBAC does exactly that. RBAC simplifies the process by allowing the security administrators to provide the same level of access permissions to a particular group. If you have 3 people who have joined your organization, one in the R&D, another in the HR department and the third one in the sales role. As a security administrator, using RBAC, all access permissions will be awarded to them in a jiffy. How? Just by adding each one of them into their respective groups.

The moment the person is added to the HR group, the RBAC model, extends all privileges in this group to the new person who has been added.

In a similar manner, if a person leaves the role, the security administrator just needs to remove this person from the group and all privileges would be revoked immediately.

Présentation 3

RBAC is a form of access control which as you said is suitable to separate responsibilities in a system where multiple roles are fulfilled. This is obviously true in corporations (often along with compartmentalization e.g. Brewer and Nash or Multi categories security (MCS)) but can also be used on a single user operating system to implement the Principle of least privilege (POLP). RBAC is designed for Separation of duties (SOD) by letting users select the roles they need for a specific task. The key question is whether you use roles to represent tasks performed on your system and assign roles in a central authority (in which case RBAC is a form of Mandatory Access Control (MAC)); or if you use roles to let users control permissions on their own objects (leading to multiple roles per object and absolutely no semantics in roles, even though it's theoretically possible).

Concept USER-ROLE-PERMISSION/PRIVILEGE

graph LR User Role Operation Privilege User -- has one or more --> Role Role -- hierarchy --> Role Role -- is a collection of --> Privilege Operation -- requieres ---> Privilege

Concept implementation of USER-ROLE-PERMISSION/PRIVILEGE

graph LR AM[Account manager] SC[Sales consultant] SITSA[Senior IT systems admin] ITOA[IT operations admin] SD[Software developer] USER[User] CD[Customer database] M[Mainframe] S[Salesforce] Email SAP Unix Directory CN[Corporate network] AM --> S AM --> Email AM --> SAP SC --> CD SC --> S SC --> Email SITSA --> CD SITSA --> M SITSA --> S SITSA --> SAP SITSA --> Unix SITSA --> Directory SITSA --> CN ITOA --> M ITOA --> Email ITOA --> Unix ITOA --> CN SD --> M SD --> Email SD --> Unix SD --> CN USER --> Email USER --> CN Roger --> AM Uber --> AM Uber --> SC Laurent --> SITSA Laurent --> ITOA Max --> SD Max --> USER Tonio --> USER Sonia --> USER

Fonctionnement

  • Avant de pouvoir appliquer le concept, il faut spécifier les droits d'un rôle de manière aussi détaillée que possible. Cela inclut l'établissement précis des autorisations dans les domaines suivants :

    • Droits de modification des données (lecture, lecture et écriture, accès complet)
    • Droits d'accès aux applications de l'entreprise
    • Autorisations dans les applications

  • L'organisation transfère toutes les fonctions des collaborateurs aux rôles qui définissent les droits d'accès correspondants. Puis les rôles sont attribués aux collaborateurs selon les tâches.

    • permet d'attribuer un ou plusieurs rôles par utilisateur.
    • possible d'attribuer individuellement des autorisations d'accès dans le modèle de rôles. Ainsi un utilisateur peut obtenir un accès pour effectuer ses tâches sans engendrer d'autres modifications.

  • La mise en place et la surveillance s'effectuent via un Identity Access Management System (IAM) (système de gestion des identités)

    • utile pour un nombre élevé de collaborateurs lors de l'attribution, du contrôle et de l'actualisation de toutes les identités et droits d'accès.
    • L'attribution d'autorisations est appelée «Provisioning», le retrait «De-Provisioning».
    • La condition requise à l'utilisation d'un tel système est l'établissement d'un concept de rôles uniforme et standardisé.

Elaboration

  • Afin de définir et d'attribuer les rôles

    • besoin de données complètes et actuelles sur les collaborateurs.
    • recommandé de tenir compte également des rôles qui éventuellement ne sont pas actuellement occupés (stagiaires, postes vacants).

  • se base sur:

    • utilisateurs
    • rôles
    • groupes

  • Les étapes

    • 0/ les resources
      • Determine the resources for which companies need to control access, if they're not already listed -- for instance, customer databases, email systems and contact management systems.
    • 1/ les autorisations
      • sont définies les autorisations dont tous les collaborateurs de l'organisation ont besoin, comme l'accès à l'Intranet, la suite Office, l'e-mail client, l'ensemble du registre du réseau ou l'inscription dans Active Directory.
    • 2/ les domaines
      • Au sein d'une organisation, les collaborateurs d'un service se chargent d'activités d'un même domaine. Ainsi le service financier a besoin d'accéder au système ERP et au disque dur du service, le service des RH en revanche a besoin d'accéder à toutes les données des collaborateurs. Les autorisations correspondantes sont attribuées à tous les collaborateurs d'un service.
    • 3/ les fonctions
      • Selon la fonction des collaborateurs et les tâches qui leur incombent, d'autres autorisations sont définies.
    • 4/ les rôles
      • Dans de nombreux cas, les collaborateurs s'occupent d'activités qui jusqu'à présent n'étaient pas prises en charge par la requête du domaine (2) et de la fonction (3). L'organisation attribue donc à chaque collaborateur les rôles complémentaires dont il a besoin en fonction de ses activités réelles.
    • 5/ Write a policy
      • Any changes made need to be outlined for current and future employees to see. Even with the use of an RBAC tool, documentation can help avoid potential issues.

Avantages et inconvénients

avantages

  • Flexibilité
    • l'entreprise attribue seulement un ou plusieurs rôles à un collaborateur selon les besoins. Les modifications au sein de la structure de l'organisation ou des autorisations sont rapidement transmises à tous les collaborateurs tandis que l'entreprise adapte les rôles correspondants.
  • Faible charge administrative
    • ce modèle rend obsolète l'attribution coûteuse d'autorisations individuelles.
  • Risque d'erreurs réduit
    • les autorisations individuelles sont plus coûteuses et aussi plus sujettes aux erreurs que l'attribution d'autorisations d'accès à base de rôles.
  • Augmentation de l'efficacité
    • en réduisant la charge et le risque d'erreurs, l'efficacité du système informatique et des autres collaborateurs augmente. Les modifications manuelles, le traitement des erreurs, les délais d'attente ainsi que les demandes individuelles de droits disparaissent.
  • Sécurité
    • les droits d'accès sont définis exclusivement selon le concept de rôles, ce qui évite la sur-autorisation de collaborateurs individuels. Ceci correspond au principe du Principle of least privilege (POLP)
  • Transparence
    • la désignation des rôles est le plus souvent aisément compréhensible, ce qui renforce la transparence et la compréhension par les utilisateurs.

inconvénients

  • Élaboration complexe
    • le transfert des structures de l'organisation dans ce modèle requiert beaucoup de travail.
  • Attribution temporaire
    • si un utilisateur a besoin temporairement de droits d'accès étendus, il est plus facile d'oublier l'attribution qu'avec une attribution individuelle de droits.
  • Utilisation
    • pour les petites entreprises, l'élaboration et la maintenance des rôles nécessitent davantage de travail que la répartition des droits individuels. Par conséquent, ce modèle est utilisé seulement à partir d'un certain nombre de rôles et de collaborateurs. Et pourtant, même pour les grandes entreprises, le Role Based Access Control a pour inconvénient de multiplier les rôles. Si une entreprise a dix services et dix rôles, il en résulte déjà 100 groupes différents.

Implémentation

Backlinks