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

• Glosario IAM
• ¿Qué es el control de accesos basado en roles (RBAC)?

El RBAC aprovecha los roles y privilegios definidos para restringir a los usuarios autorizados el acceso a los sistemas. 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 accesos basado en atributos (ABAC).

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

La idea que hay detrás del control de accesos basado en roles es sencilla: 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 (normalmente abreviado como PoLP).

En un entorno de accesos basado en roles, el rol que tiene el usuario dentro de la organización determina los permisos de red específicos que tiene concedidos. Esto implica prohibir a los empleados de menor nivel acceder a la información y a los recursos altamente confidenciales, pero los niveles de acceso basados en roles son normalmente 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 del desarrollador 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 permisos de solo lectura en ciertos archivos o sistemas, como bases de datos, pero derechos de lectura y escritura en otros casos.

El RBAC frente al ABAC

El control de accesos basado en roles se utiliza a menudo como sinónimo de control de accesos basado en atributos. Aunque el ABAC y el RBAC son diferentes, el RBAC se utiliza frecuentemente junto con el ABAC.

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 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 la 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 sus administradores de TI tengan restringido el acceso remoto a los sistemas de fondo a menos que utilicen una VPN o un gestor de conexión 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.

El RBAC frente a las 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...) 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.

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

Si le parece que esto conlleva mucho trabajo, está en lo cierto. Mantener listas masivas de permitidos y bloqueados es un proceso largo y propenso a errores. Por eso, las ACL (y el modelo 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 individual o IP. Esto hace que el RBAC sea mucho menos laborioso y propenso a errores que las listas de control de acceso 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 accesos 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 comprometa (sin querer o queriendo) 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 atacante externo robe un conjunto de credenciales de inicio de sesión que funcionen, el RBAC y el acceso de mínimo privilegio impedirán que se desplace lateralmente dentro de la red y escale en privilegios.

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

Compatible con iniciativas de conformidad

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) y otros datos sensibles. Esto es especialmente importante en sectores muy regulados, como el sector de la salud y las finanzas, así como en las agencias gubernamentales.

Reducción de costes 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, el RBAC permite 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 accesos basado en roles (RBAC)

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 gestión de incidencias del servicio de asistencia.

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

   Tenga en cuenta que puede que quiera utilizar el RBAC junto con el ABAC u otro modelo, especialmente si está implementando 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 el 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, el solapamiento de roles y las excepciones excesivas para los permisos del 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 RBAC.

   Una organización grande, sobre todo si no tiene un modelo basado en roles, puede querer desplegar 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 desplegar el plan por etapas, podrá abordarlo más fácilmente.

5. Mantenga su modelo RBAC.

   Los usuarios vienen y van. Los negocios necesitan cambios. La tecnología cambia. El mercado cambia. A pesar de todo, los controles de accesos basados en roles no se mantienen solos. Recoja los comentarios de sus usuarios, supervise continuamente su postura de seguridad y realice revisiones periódicas de los roles, las asignaciones de los roles y los registros de acceso para entender qué está funcionando y qué necesita un ajuste.