MAC vs DAC vs RBAC

DAC es el camino a seguir para que las personas administren el contenido que poseen. Puede parecer obvio, pero, por ejemplo, DAC es muy bueno para permitir que los usuarios de una red social en línea elijan quién accede a sus datos. Permite a las personas revocar o reenviar privilegios de forma fácil e inmediata. Control de acceso reactivo , Viendo más adelante y Intercambio de archivos en Laissez-faire proporcionar buenos ejemplos de investigación sobre DAC con usuarios.

RBAC es una forma de control de acceso que, como usted dijo, es adecuada para separar responsabilidades en un sistema donde se cumplen múltiples roles. Esto es obviamente cierto en las corporaciones (a menudo junto con la compartimentación, por ejemplo, Brewer and Nash o MCS ) pero también se puede usar en un sistema operativo de un solo usuario para implementar el principio de privilegio mínimo . RBAC está diseñado para la separación de funciones al permitir que los usuarios seleccionen los roles que necesitan para una tarea específica. La pregunta clave es si utiliza roles para representar tareas realizadas en su sistema y asigna roles en una autoridad central (en cuyo caso RBAC es una forma de MAC); o si usa roles para permitir que los usuarios controlen los permisos en sus propios objetos (lo que lleva a múltiples roles por objeto y absolutamente ninguna semántica en los roles, aunque sea teóricamente posible ).

MAC en sí mismo es vago, hay muchas formas de implementarlo para muchos sistemas. En la práctica, a menudo usarás una combinación de diferentes paradigmas. Por ejemplo, un sistema UNIX en su mayoría usa DAC, pero la cuenta raíz pasa por alto los privilegios de DAC. En una corporación, más allá de separar sus diferentes departamentos y equipos con MAC / RBAC, puede permitir que algunos DAC compartan información sobre su sistema de archivos corporativo.

Sería mejor hacer su pregunta específica y decir qué sistema (s) desea proteger, si corresponde. El control de acceso que se utilice siempre depende de la situación y el contexto específicos que esté considerando.

Cada sistema se utiliza para un requisito de seguridad de reemplazo diferente. Los tres requisitos principales de seguridad son la confidencialidad, la integridad y la disponibilidad.

MAC admite un requisito de seguridad de confidencialidad más que los otros. DAC admite el requisito de seguridad de disponibilidad más que los otros. RBAC respalda el requisito de seguridad de integridad más que los otros. hay otro ...

MAC toma decisiones basadas en el etiquetado y luego en los permisos. DAC toma decisiones basadas solo en permisos. RBAC toma decisiones basadas en funciones / roles.

Cuando el sistema o la implementación toman decisiones (si están programadas correctamente) aplicarán los requisitos de seguridad. Si usa el sistema incorrecto, puede hacerlo para hacer lo que quiera. Esto sucede con bastante frecuencia.

No se excluyen mutuamente excepto para DAC vs MAC. Hay implementaciones de combinación DAC / RBAC, el mejor ejemplo de los roles y permisos de Active Directory.

RBAC: tiende a las bases de datos: un ejemplo clásico de donde no puede usar uno de los otros sistemas y RBAC debe usarse para el servicio al cliente y la facturación. Cuando llame a la compañía de cable para obtener su pago por evento, el representante de servicio al cliente le dirá que lo siento, permítame transferirlo a Facturación para que pueda pagar su factura vencida. Saben que tiene una factura vencida pero su función lo impide. de tomar directamente la información de su tarjeta de crédito. Cuando te transfieren a la facturación, pagas tu factura y dices que puedo tener mi servicio. Dicen: "Permítame devolverle la llamada. Veo que desea este servicio, pero esa no es mi función". Por lo tanto, ambos roles pueden ver todos los datos (sin confidencialidad) pero solo pueden manipular los campos para los que tienen un conjunto particular de responsabilidades (integridad). -Puedes argumentar DAC: pero se ajusta a la regla de "más aún".

MAC: tiende a sistemas militares o implementaciones de requisitos de seguridad altamente definidas de forma muy limitada. 2 que se utilizan con bastante frecuencia TRusted-Solaris y LINUX-MAC kernel module (esto solía ser SELinux) hay otros pero no te importa. Uno de los elementos clave que solo aparece en MAC es una construcción de dominancia. Si tiene un nivel de autorización secreto, ninguna cantidad de permisos lo hará ver un documento de alto secreto. En las entidades comerciales es raro que se necesite esta construcción. Pero muestra el segundo punto que es exclusivo de MAC: si una actividad no está específicamente permitida, entonces no puede hacerlo. (Esto rompe muchos usos comerciales principalmente debido a un cambio rápido en la misión o los requisitos del sistema) Un excelente uso de MAC sería en un servidor web, donde escribiría una política personalizada (y esto se define de manera muy restringida para esa implementación) que indica que los procesos Core solo pueden ser ejecutados por la cuenta del sistema. Todos los procesos generados a partir de eso se requerirían con permisos específicos.

DAC: todos lo usan y la persona que tengo ante mí responde lo suficientemente bien.