MAC contre DAC contre RBAC
Quelqu'un peut me suggérer une situation réelle dans laquelle est préférable d'utiliser MAC (contrôle d'accès obligatoire) au lieu de DAC (contrôle d'accès discrétionnaire) ou RBAC (contrôle d'accès basé sur les rôles)? Et dans quel DAC est meilleur que les autres? Et dans quel RBAC est le meilleur?
Je connais les notions théoriques et je sais que le RBAC est meilleur dans une situation où nous voulons attribuer les droits non pas aux personnes, mais au travail spécifique. Je sais également que MAC et RBAC sont meilleurs dans une situation où nous voulons éviter qu'un utilisateur puisse gérer les droits.
[~ # ~] dac [~ # ~] est la voie à suivre pour permettre aux gens de gérer le contenu qu'ils possèdent. Cela peut sembler évident, mais par exemple, le CAD est très bon pour permettre aux utilisateurs d'un réseau social en ligne de choisir qui accède à leurs données. Il permet aux gens de révoquer ou de transférer des privilèges facilement et immédiatement. Contrôle d'accès réactif , Voir plus loin et Partage de fichiers laissez-faire fournir de beaux exemples de recherche sur DAC avec les utilisateurs.
[~ # ~] rbac [~ # ~] est une forme de contrôle d'accès qui, comme vous l'avez dit, convient pour séparer les responsabilités dans un système où plusieurs rôles sont remplies. Cela est évidemment vrai dans les entreprises (souvent avec compartimentage par exemple Brewer et Nash ou MCS ) mais peut également être utilisé sur un seul système d'exploitation utilisateur pour implémenter le principe du moindre privilège . RBAC est conçu pour séparation des tâches en permettant aux utilisateurs de sélectionner les rôles dont ils ont besoin pour une tâche spécifique. La question clé est de savoir si vous utilisez des rôles pour représenter les tâches effectuées sur votre système et attribuez des rôles dans une autorité centrale (auquel cas RBAC est une forme de MAC); ou si vous utilisez des rôles pour permettre aux utilisateurs de contrôler les autorisations sur leurs propres objets (conduisant à plusieurs rôles par objet et absolument aucune sémantique dans les rôles, même si c'est théoriquement possible ).
[~ # ~] mac [~ # ~] en soi est vague, il existe de nombreuses façons de l'implémenter pour de nombreux systèmes. En pratique, vous utiliserez souvent une combinaison de différents paradigmes. Par exemple, un système UNIX utilise principalement DAC mais le compte root contourne les privilèges DAC. Dans une entreprise, au-delà de la séparation de vos différents départements et équipes avec MAC/RBAC, vous pouvez autoriser certains DAC pour vos collègues à partager des informations sur votre système de fichiers d'entreprise.
Il serait préférable de préciser votre question et d'indiquer le ou les systèmes que vous souhaitez protéger, le cas échéant. Le contrôle d'accès à utiliser dépend toujours de la situation et du contexte spécifiques que vous envisagez.
Chaque système est utilisé pour une exigence de sécurité primordiale différente. Les trois principales exigences de sécurité sont la confidentialité, l'intégrité et la disponibilité.
MAC prend en charge une exigence de sécurité de confidentialité plus que les autres. DAC prend en charge les exigences de sécurité de disponibilité plus que les autres. RBAC prend davantage en charge les exigences de sécurité d'intégrité que les autres. il y en a un autre ...
MAC prend des décisions basées sur l'étiquetage puis les autorisations. DAC prend des décisions basées uniquement sur les autorisations. Le RBAC prend des décisions basées sur la fonction/les rôles.
Lorsque le système ou l'implémentation prend des décisions (s'il est correctement programmé), il applique les exigences de sécurité. Si vous utilisez le mauvais système, vous pouvez lui demander de faire ce que vous voulez. Cela arrive assez souvent.
Ils ne s'excluent pas mutuellement, sauf pour DAC vs MAC. Il existe des implémentations combinées DAC/RBAC, le meilleur exemple de ces rôles et autorisations Active Directory.
RBAC - tend vers les bases de données - un exemple classique où vous ne pouvez pas utiliser l'un des autres systèmes et devez utiliser RBAC pour le service client et la facturation. Lorsque vous appelez le câblodistributeur pour obtenir votre pay-per-view, le représentant du service clientèle dira que je suis désolé, permettez-moi de vous transférer vers la facturation afin que vous puissiez payer votre facture en souffrance - ils savent que vous avez une facture en retard mais leur rôle empêche de prendre directement les informations de votre carte de crédit. Lorsque vous êtes transféré à la facturation, vous payez votre facture et dites que je peux avoir mon service. Ils disent: laissez-moi vous transférer - je vois que vous voulez ce service mais ce n'est pas ma fonction. Ainsi, les deux rôles peuvent voir toutes les données (pas de confidentialité) mais ne peuvent manipuler que les champs pour lesquels ils ont un ensemble particulier de responsabilités (intégrité). -vous pouvez argumenter DAC: mais correspond à la règle du "plus".
MAC - tend vers des systèmes militaires ou des implémentations de sécurité très définies. 2 qui sont utilisés assez souvent les modules de noyau TRusted-Solaris et LINUX-MAC (anciennement SELinux), il y en a d'autres mais peu vous importe. L'un des éléments clés qui n'apparaît que dans MAC est une construction de domination. Si vous disposez d'une autorisation de niveau secret, aucune quantité d'autorisations ne vous permettra de voir un document Top secret. Dans les entités commerciales, il est rare que vous ayez besoin de cette construction. Mais cela soulève le deuxième point qui est unique à MAC - si une activité n'est pas spécifiquement autorisée, vous ne pouvez pas le faire. (Cela brise beaucoup d'utilisations commerciales principalement en raison d'un changement rapide de la mission ou des exigences du système) Une excellente utilisation de MAC serait sur un serveur Web - où vous écririez une politique personnalisée (et cela est très étroitement défini pour cette implémentation) qui indique que les processus principaux ne peuvent être exécutés que par le compte système. Tous les processus générés à partir de cela devraient répondre à des autorisations spécifiques.
CAD - tout le monde l'utilise et la personne avant moi répond assez bien.