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

El control de acceso basado en roles (RBAC) utiliza los roles y privilegios definidos para restringir el acceso al sistema a los usuarios autorizados. El RBAC es la base del acceso de mínimo privilegio y también puede utilizarse para implementar otros modelos de acceso, como el control de acceso basado en atributos (ABAC).

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

El objetivo del control de acceso basado en roles (RBAC) es simple: limitar el acceso de los usuarios a los sistemas y datos a lo mínimo que necesiten para desempeñar su trabajo y nada más. Es un concepto conocido como el principio de mínimo privilegio (a veces abreviado como PoLP).

En un entorno de acceso basado en roles, el rol que tiene el usuario dentro de la organización determina los permisos de red específicos que se le conceden. Esto implica prohibir a los empleados de menor nivel acceder a la información y a los recursos de gran confidencialidad, pero los niveles de acceso basado en roles suelen ser más granulares. Cuando el RBAC se implementa adecuadamente, los usuarios no deberían poder acceder a ningún recurso fuera de sus áreas de trabajo asignadas. Por ejemplo, los empleados de marketing no deberían tener acceso a los entornos de desarrolladores y viceversa.

Además, el acceso basado en roles se utiliza para restringir lo que los usuarios pueden hacer con un sistema o archivo al que se les ha concedido acceso. Un usuario puede tener acceso de solo lectura a ciertos archivos o sistemas, como bases de datos, pero acceso de lectura y escritura en otros casos.

RBAC frente a ABAC

El control de acceso basado en roles (RBAC) se utiliza a menudo como sinónimo de control de acceso basado en atributos (ABAC). Si bien son diferentes, frecuentemente se utilizan en conjunto.

El ABAC es más detallado que el RBAC y puede considerarse como una extensión o mejora del acceso basado en roles. Mientras que el RBAC depende del rol de un usuario dentro de la organización, en un modelo de ABAC los derechos de acceso del usuario dependen de una combinación de atributos, no solo de los roles del usuario. Estos incluyen, entre otros, el rol del usuario en la organización, el lugar desde el que intenta acceder a los recursos, el dispositivo que utiliza y los atributos asociados con el sistema o la aplicación a los que intenta acceder. Esto permite a las organizaciones conceder acceso y aplicar restricciones según el perfil de riesgo de un usuario individual.

Por ejemplo, puede querer que los administradores de TI tengan restringido el acceso remoto a los sistemas back-end a menos que utilicen una VPN o un Connection Manager de escritorio remoto, o puede querer prohibir a todos los empleados el acceso a los recursos de la empresa a menos que utilicen un dispositivo proporcionado por la propia empresa.

RBAC frente a listas de control de acceso (ACL)

Una lista de control de acceso (ACL) es una lista de usuarios que tienen acceso a un recurso concreto, junto con los privilegios que cada usuario tiene para ese recurso (solo lectura; lectura y escritura, etc.). Las ACL son la base del modelo de control de acceso discrecional (DAC).

El ejemplo más común de una ACL y un DAC en acción es el sistema de archivos de Windows, el cual permite a los usuarios y administradores definir ACL individuales para cada objeto, como un documento de texto o una carpeta de archivos.

Los administradores de red también utilizan las ACL, que normalmente están compuestas por direcciones IP, para filtrar el tráfico a las VPN, los firewalls de aplicaciones web (WAF) y los enrutadores y conmutadores de red. La ACL puede contener una "lista de IP permitidas" o una "lista de IP bloqueadas" (no permitidas).

Si le parece que esto conlleva mucho trabajo, está en lo cierto. Mantener listas masivas de IP permitidas y bloqueadas es un proceso lento y propenso a errores. Por eso, las ACL (y el modelo de DAC) son útiles únicamente en casos concretos con un número reducido de usuarios.

Conclusión: mientras que el RBAC define los privilegios de acceso a nivel de grupo, una ACL los define a nivel de usuario o IP individual. Esto hace que el RBAC sea mucho menos laborioso y propenso a errores que las ACL y, por lo tanto, mucho más factible en un entorno empresarial con docenas, cientos o incluso miles de usuarios.

¿Cuáles son los beneficios del RBAC?

Implementar el control de acceso basado en roles tiene muchos beneficios, como los siguientes:

Mejora de la seguridad

Limitar el acceso de los empleados a los recursos que necesitan para llevar a cabo su trabajo evita que el personal interno elimine, filtre o vulnere (sin querer o adrede) la integridad de los archivos y otros activos digitales, como las bases de datos o el código fuente.

Además, en caso de que un actor de amenazas externo robe un conjunto de credenciales de inicio de sesión activas, el RBAC y el acceso de privilegio mínimo impedirán que se desplace lateralmente dentro de la red y escale en privilegios.

Los RBAC y el acceso de privilegio mínimo son también componentes clave de los modernos modelos de acceso a la red de confianza cero.

Compatible con iniciativas de cumplimiento

El acceso basado en roles permite a las empresas cumplir con los requisitos normativos y del sector, como la HIPPA, el RGPD y otros marcos de protección de datos y privacidad que exigen controles de confidencialidad y privacidad para la información personal identificable (PII, por sus siglas en inglés) y otros datos sensibles. Esto es especialmente importante en sectores con muchas reglamentaciones, como el sector de la salud y las finanzas, así como en las agencias gubernamentales.

Reducción de costos y gastos administrativos

Los roles de los usuarios predefinidos de un modelo RBAC minimizan los gastos administrativos a la hora de incorporar y dar de baja a los empleados cuando estos asumen nuevos roles o responsabilidades dentro de la empresa o cuando la empresa tiene que conceder acceso a un proveedor o contratista externo. Otorgar acceso a un usuario nuevo, o cambiar el acceso de un usuario existente, consiste simplemente en asignarles el rol o los roles adecuados. De la misma forma, cuando los usuarios dejan la empresa, los administradores de TI y seguridad pueden revocar rápidamente su acceso a los sistemas.

Al dar a los administradores visibilidad sobre el acceso y la actividad de los usuarios, los RBAC permiten a las organizaciones identificar las áreas en las que pueden utilizar los recursos de red de forma más rentable, como el ancho de banda y el almacenamiento.

Cómo implementar el control de acceso basado en roles (RBAC, por sus siglas en inglés)

1. Desarrolle una estrategia que cumpla con las necesidades de su empresa.

Antes de empezar a definir los roles, haga un inventario de sus sistemas para determinar a qué recursos necesita controlar el acceso. Identifique los sistemas que procesan o almacenan información sensible, como las bases de datos de clientes y los entornos de desarrollo, así como los sistemas a los que todo el mundo necesita acceder, como el correo electrónico de la empresa y los sistemas de tickets del servicio de asistencia.

Examine también los procesos empresariales, las tecnologías, los requisitos de cumplimiento normativo y la postura de seguridad actual de su empresa. Identifique cualquier brecha existente, como la aplicación no coherente de las políticas en toda la organización.

Tenga en cuenta que puede que quiera utilizar los RBAC junto con los controles de acceso basados en atributos (ABAC, por sus siglas en inglés) u otro modelo, especialmente si desea implementar el acceso a la red de confianza cero.

2. Defina los roles de los usuarios.

Ahora es el momento de analizar su plantilla y agrupar a los usuarios en roles que tengan necesidades de acceso similares. Empiece con pinceladas generales (como examinar a los usuarios por departamento) y luego afine los roles de los usuarios a partir de ahí.

Asegúrese de no definir demasiados roles, ya que ello anularía el propósito de utilizar los RBAC. Considere utilizar la asignación de equipos a roles, en la que los usuarios se asignan directamente a los equipos a los que luego se pueden asignar roles personalizados. Esto ahorrará tiempo, mejorará la coherencia de las políticas, reducirá los errores y facilitará a los administradores las políticas de acceso basadas en roles.

También hay que tener cuidado con otros problemas comunes, como la granularidad insuficiente, la superposición de roles y las excepciones excesivas para los permisos de los RBAC.

3. Establezca una estructura de gobernanza apropiada.

Tras definir su estrategia de RBAC y los roles de los usuarios, necesita una forma de hacer cumplir sus nuevas políticas, así como un proceso de gestión de cambios para modificarlas a medida que cambian las necesidades de su empresa.

Desarrolle una política escrita sobre el control de los accesos que contenga normas y directrices para su modelo de RBAC e incluya indicadores de rendimiento, estrategias de gestión del riesgo, procedimientos de reevaluación de roles y mecanismos de aplicación. Un conjunto de normas claro ayuda a evitar la "propagación de roles" y los conflictos internos entre departamentos y usuarios individuales.

4. Implemente su modelo de RBAC.

Una organización grande, sobre todo si no tiene un modelo basado en roles, puede querer implementar el nuevo plan por etapas para evitar la confusión de los usuarios y la interrupción de las operaciones diarias. Prevea que habrá problemas a lo largo del camino, incluyendo cuestiones que requieran que modifique su plan original. Esto es algo normal y, al implementar el plan por etapas, podrá abordarlo más fácilmente.

5. Mantenga su modelo de RBAC.

Los usuarios van y vienen. Las empresas necesitan cambios. La tecnología cambia. El mercado cambia. A pesar de todo, los controles de accesos basados en roles no se mantienen solos. Recopile comentarios de sus usuarios, monitoree continuamente su postura de seguridad y realice revisiones periódicas de los roles, la asignación de roles y los registros de acceso para comprender qué funciona y qué debe ajustarse.

Español (LAT) Llámenos