RBAC DE CONTROL DE ACCESO BASADO EN FUNCIONES: definición, historial y ejemplos

control de acceso basado en roles

Este artículo brinda una explicación completa del control de acceso basado en roles (RBAC), así como también una guía paso a paso para implementar, mantener y extender RBAC para satisfacer las necesidades de su organización. Aprenderá sobre roles, cómo definirlos y cómo usarlos para regular el acceso puede ayudar a proteger su red, reducir los costos administrativos y garantizar el cumplimiento normativo. También veremos algunos ejemplos de control de acceso basado en roles. Empecemos.

¿Qué es el control de acceso basado en roles (RBAC)?

El concepto de otorgar permisos a las personas en función de su rol dentro de una organización se conoce como control de acceso basado en roles (RBAC). Proporciona un enfoque básico y controlado para la administración de acceso que es menos propenso a errores que otorgar permisos individualmente a los usuarios.

Cuando utiliza RBAC para la administración de acceso a roles, examina las demandas de sus usuarios y los agrupa en roles según las tareas compartidas. Luego, para cada usuario, asigna uno o más roles y uno o más permisos a cada rol. Debido a que los usuarios ya no necesitan ser administrados indiscriminadamente, las relaciones usuario-rol y rol-permisos facilitan la realización de asignaciones de usuarios.

Historia del control de acceso basado en roles

Desde al menos la década de 1970, las personas han utilizado roles y responsabilidades para controlar el acceso a los sistemas informáticos comerciales. Sin embargo, estos métodos eran ad hoc y con frecuencia tenían que modificarse caso por caso para cada nuevo sistema.

Los investigadores del American National Standards Institute (NIST) no comenzaron a definir el sistema conocido como control de acceso basado en roles hasta 1992. En ese mismo año, Ferraiolo y Kuhn publicaron un artículo que definía un mecanismo de control de acceso de propósito general adecuado para civiles y uso comercial, sentando las bases para el modelo que usamos hoy.

A lo largo de la década de 1990 y principios de la de 2000, Ferraiolo, Kuhn y otros refinaron RBAC, basándose en trabajos anteriores para investigar los beneficios económicos de RBAC, especificar un modelo unificado y, lo que es más importante, definir los formularios de división de tareas. RBAC fue adoptado oficialmente como estándar industrial por NIST en 2004.

¿Cómo funciona el RBAC de control de acceso basado en roles?

Antes de implementar RBAC en una empresa, la organización debe especificar minuciosamente los permisos para cada función. Esto incluye especificar con precisión los permisos en las categorías enumeradas a continuación:

  • Permisos de modificación de datos (por ejemplo, lectura, escritura, acceso completo)
  • Acceso a utilizar el software de la empresa
  • Permisos dentro de un programa

Para aprovechar al máximo RBAC, primero debe modelar roles y permisos. Asignar todas las responsabilidades del personal a trabajos particulares que establezcan privilegios adecuados es parte de esto. La organización puede entonces asignar puestos en función de las tareas de los empleados.

Las organizaciones pueden usar el control de acceso basado en roles para asignar uno o más roles a cada usuario o para asignar permisos individualmente. La idea es establecer permisos que permitan a los usuarios completar sus tareas sin realizar ajustes adicionales.

Las organizaciones utilizan las tecnologías de administración de acceso e identidad (IAM) para implementar y monitorear RBAC. IAM sirve principalmente a grandes organizaciones mediante el registro, la supervisión y la actualización de todas las identidades y permisos. El proceso de asignación de permisos se conoce como "aprovisionamiento" y el proceso de revocación de permisos se conoce como "desaprovisionamiento". Este tipo de sistema requiere el establecimiento de un conjunto uniforme y estandarizado de funciones.

¿Qué es un rol RBAC de control de acceso basado en roles?

Los roles son semánticas dentro de la arquitectura RBAC que las organizaciones pueden utilizar para crear sus privilegios. La autoridad, la responsabilidad, el centro de costos, la unidad de negocios y otros factores se pueden usar para definir roles.

Un rol es una agrupación de privilegios de usuario. Los grupos tradicionales, que son agregados de usuarios, no son lo mismo que los roles. Los permisos no están directamente relacionados con las identidades en el contexto de RBAC, sino con los roles. Debido a que están organizados en torno a la administración de acceso, los roles son más confiables que los grupos. La identidad cambia con más frecuencia que las funciones y actividades en un negocio normal.

El modelo RBAC de control de acceso basado en roles

El estándar RBAC define tres formas de control de acceso: central, jerárquico y confinado.

#1. RBAC central

El modelo central define los componentes clave de cualquier sistema de control de acceso basado en roles. Si bien el RBAC fundamental se puede utilizar como un enfoque de control de acceso independiente, también sirve como base para modelos jerárquicos y restringidos.

Como resultado, todos los RBAC deben seguir las tres reglas que se describen a continuación:

  • Selección o asignación de roles: Una persona solo puede ejercer un permiso si ha elegido o se le ha asignado un rol.
  • Autorización de funciones: El papel activo de un sujeto debe ser autorizado.
  • Autorización de permisos: Un sujeto solo puede ejercer los permisos que están permitidos para el rol activo del sujeto.

#2. Jerarquía RBAC

Al creer que sus defensas ya han sido vulneradas, puede adoptar una postura de seguridad más fuerte contra posibles ataques, lo que reduce el efecto de una vulneración. Limite el "radio de explosión" de los posibles daños causados ​​por una infracción segmentando el acceso y disminuyendo su superficie de ataque, confirmando el cifrado de extremo a extremo y monitoreando su red en tiempo real.

#3. RBAC restringido

Este tercer estándar RBAC amplía la división de funciones del modelo central. Las relaciones de separación de funciones se clasifican en estáticas o dinámicas.

  • Un solo usuario no puede tener responsabilidades mutuamente excluyentes en las relaciones de separación estática de tareas (SSD) (según lo definido por la organización). Esto garantiza que, por ejemplo, una persona no pueda realizar y aprobar una compra.
  • Un usuario bajo el modelo de separación dinámica de funciones (DSD) puede tener roles contradictorios. Sin embargo, el usuario no puede realizar ambas tareas en la misma sesión. Esta restricción ayuda en el control de los problemas de seguridad interna, por ejemplo, implementando la regla de dos personas, que requiere dos usuarios únicos para autorizar una acción.

Ejemplos de control de acceso basado en roles

RBAC le permite controlar lo que los usuarios finales pueden hacer tanto a nivel amplio como granular. Puede especificar si el usuario es un administrador, un usuario especialista o un usuario final, y puede hacer coincidir las responsabilidades y los permisos de acceso con los puestos organizacionales de sus empleados. Los permisos solo se otorgan con suficiente acceso para que los empleados realicen sus tareas.

¿Qué sucede si cambia la descripción de un usuario final del trabajo? Es posible que deba otorgar su rol a otro usuario manualmente, o puede asignar roles a un grupo de roles o usar una política de asignación de roles para agregar o eliminar miembros del grupo de roles.

Una herramienta RBAC puede incluir las siguientes designaciones:

  • Ámbito de la función de gestión – restringe qué elementos puede manejar el grupo de funciones.
  • Grupo de roles de administración – Puede agregar y eliminar miembros del grupo de roles de administración.
  • Rol de gestión – estos son los tipos de tareas que puede realizar un grupo de roles determinado.
  • Asignación de roles de gestión- Este es el proceso de asignar un rol a un grupo de roles.

Cuando se agrega un usuario a un grupo de roles, el usuario obtiene acceso a todos los roles de ese grupo. Cuando se eliminan, se restringe el acceso. Los usuarios también pueden asignarse a numerosos grupos si requieren acceso temporal a datos o aplicaciones específicos y luego eliminarse una vez que finaliza el proyecto.

Otras posibilidades de acceso del usuario pueden incluir:

  • El contacto clave para una determinada cuenta o función.
  • Facturación: acceso a una cuenta de facturación para un único usuario final.
  • Los usuarios técnicos son aquellos que realizan tareas técnicas.
  • El acceso administrativo se otorga a los usuarios que realizan actividades administrativas.

Alternativas de RBAC: tipos de control de acceso

Se podrían utilizar otros mecanismos de control de acceso en lugar del control de acceso basado en roles.

Lista de control de acceso (ACL)

Una lista de control de acceso (ACL) es una tabla que enumera los permisos asociados con los recursos informáticos. Informa al sistema operativo sobre qué usuarios tienen acceso a un objeto y qué acciones pueden realizar sobre él. Cada usuario tiene una entrada que está vinculada a las propiedades de seguridad de cada elemento. Para los sistemas DAC clásicos, normalmente se emplea ACL.

ACL frente a RBAC

En términos de seguridad y costos administrativos, RBAC supera a ACL para la mayoría de las aplicaciones comerciales. ACL es más adecuado para implementar seguridad a nivel de usuario individual y para datos de bajo nivel, pero RBAC es más adecuado para un sistema de seguridad de toda la empresa supervisado por un administrador. Una ACL, por ejemplo, puede habilitar el acceso de escritura a un determinado archivo, pero no puede definir cómo el usuario cambiará el archivo.

Control de acceso basado en atributos (ABAC)

ABAC evalúa un conjunto de reglas y políticas para controlar los permisos de acceso en función de ciertas cualidades, como la información ambiental, del sistema, del objeto o del usuario. Utiliza lógica booleana para permitir o denegar el acceso a las personas en función de una evaluación complicada de las propiedades atómicas o de valores establecidos y sus relaciones.

En la práctica, esto le permite definir reglas en Lenguaje de marcado de control de acceso extensible (XACML) que utilizan combinaciones de clave-valor como Rol=Administrador y Categoría=Financiero.

ABAC frente a RBAC

RBAC se basa en roles predefinidos, mientras que ABAC es más dinámico y utiliza un control de acceso basado en relaciones. RBAC se puede utilizar para definir controles de acceso a grandes rasgos, mientras que ABAC proporciona más granularidad. Un sistema RBAC, por ejemplo, otorga acceso a todos los gerentes, mientras que una política ABAC solo otorga acceso a los gerentes del departamento financiero. ABAC realiza una búsqueda más complicada, que exige más potencia de procesamiento y tiempo, por lo tanto, utilícelo solo cuando RBAC sea insuficiente.

Ventajas de RBAC

  • La gestión y auditoría del acceso a la red son fundamentales para la seguridad de la información. El acceso puede y debe permitirse en función de la necesidad de saber. La seguridad se administra más fácilmente con cientos o miles de empleados al limitar el acceso innecesario a información crítica según el rol establecido de cada usuario dentro de la empresa. Otros beneficios incluyen:
  • Se reducirá el apoyo administrativo y de TI. Cuando se contrata a un empleado o cambia de rol, puede usar RBAC para disminuir el requisito de papeleo y cambios de contraseña. En su lugar, puede utilizar RBAC para agregar y transferir roles rápidamente entre sistemas operativos, plataformas y aplicaciones. También disminuye la posibilidad de error al otorgar permisos de usuario. Uno de los muchos beneficios económicos de RBAC es la reducción del tiempo dedicado a las actividades administrativas. RBAC también facilita la integración de usuarios de terceros en su red asignándoles roles predefinidos.
  • Aumento de la eficiencia operativa. RBAC proporciona un enfoque simplificado con definiciones lógicas. En lugar de intentar administrar el control de acceso de nivel inferior, todos los roles se pueden alinear con la estructura organizativa de la empresa, lo que permite a los usuarios cumplir con sus funciones de manera más eficiente y autónoma.
  • Aumento del cumplimiento. Se aplican restricciones federales, estatales y municipales a todas las organizaciones. Las empresas pueden cumplir más fácilmente los estándares legales y reglamentarios de privacidad y confidencialidad con un sistema RBAC porque los departamentos y ejecutivos de TI pueden controlar cómo se accede a los datos y cómo se utilizan. Esto es especialmente importante para las organizaciones financieras y de atención médica, que manejan una gran cantidad de datos confidenciales como PHI y PCI.

Mejores prácticas para la implementación de RBAC

La implementación de un RBAC en su organización no debe tomarse a la ligera. Hay una serie de etapas generales a seguir para incorporar al equipo sin producir confusión innecesaria o irritaciones en el lugar de trabajo. Aquí hay algunas ideas para comenzar.

  • Estado actual: Haga una lista de cada pieza de software, hardware y aplicación que tenga seguridad. La mayoría de estos requerirán una contraseña. Sin embargo, es posible que desee incluir salas de servidores que estén bajo llave. La seguridad física puede ser un componente importante de la protección de datos. Asimismo, especifique quién tiene acceso a cada uno de estos programas y lugares. Esto le proporcionará una idea de su situación de datos actual.
  • Funciones actuales: Incluso si no tiene una lista formal y una lista de roles, determinar qué hace cada miembro individual del equipo puede ser tan simple como una charla rápida. Intente organizar el equipo de manera que no impida la creatividad o la cultura actual (si se disfruta).
  • Crear una política: Cualquier modificación debe documentarse para que la vean todos los trabajadores presentes y futuros. Incluso si utiliza una solución RBAC, tener un documento que articule claramente su nuevo sistema lo ayudará a prevenir problemas.
  • Cambios: Una vez que se conocen los roles y el estado de seguridad actual (y se implementa una política), es hora de implementar los cambios.
  • Adaptarse continuamente: Es probable que la primera iteración de RBAC necesite alguna modificación. Desde el principio, debe evaluar con frecuencia sus funciones y el estado de seguridad. Primero evalúe qué tan bien está funcionando su proceso creativo/de producción y luego qué tan seguro es su proceso.

Conclusión

La protección de datos es una función comercial crítica para cualquier corporación. Un sistema RBAC puede garantizar que la información de la empresa cumpla con las leyes de privacidad y confidencialidad. Además, puede asegurar actividades comerciales esenciales, como el acceso a la propiedad intelectual, lo que tiene un impacto competitivo en la organización.

Preguntas frecuentes sobre el control de acceso basado en roles

¿Cuáles son las tres reglas principales para RBAC?

Los componentes de RBAC, como los permisos de función, la función de usuario y las relaciones de función a función, simplifican las asignaciones de usuarios.

¿Por qué se utiliza ACL?

Reducción del tráfico de red para mejorar el rendimiento de la red. Un nivel de seguridad de red que especifica a qué secciones del servidor/red/servicio un usuario puede y no puede acceder. Seguimiento granular del tráfico que ingresa y sale del sistema.

¿Cuál es la diferencia entre el control de acceso basado en roles y el control de acceso basado en reglas?

Los niveles de acceso de los empleados no están determinados por controles de acceso basados ​​en reglas, que son de naturaleza preventiva. En su lugar, trabajan para evitar el acceso no deseado. Los modelos basados ​​en roles son proactivos en el sentido de que presentan a los empleados un conjunto de condiciones bajo las cuales pueden adquirir acceso aprobado.

Referencias

Deje un comentario

Su dirección de correo electrónico no será publicada. Las areas obligatorias están marcadas como requeridas *

También te puede interesar