Política de control de acceso: cómo diseñar RBAC empresarial

La mayoría de las implementaciones de RBAC fallan antes de asignar un solo permiso. La causa raíz es casi siempre el diseño de la política. Los equipos compran una herramienta de gestión de identidades y accesos (IAM), mapean algunos roles obvios como admin y usuario, y comienzan a asignar accesos. Dieciocho meses después tienen 400 roles para 250 empleados, nadie recuerda por qué el rol Finance-Temp-2023 todavía tiene acceso de escritura al libro mayor, y la auditoría anual tarda semanas en lugar de días.

Una política de control de acceso empresarial es el documento formal que define qué roles existen en una organización, qué permisos tiene cada rol, quién califica para un rol determinado, y cómo ese acceso se revisa y revoca con el tiempo.

El control de acceso basado en roles (RBAC) es el modelo de autorización. La política de control de acceso es la capa de gobernanza que decide cómo se aplica el modelo en la práctica. Sin un diseño deliberado de la política, RBAC se degrada en explosión de roles, acumulación de privilegios y caos de auditoría, sin importar cuán buena sea la tecnología subyacente.

Este artículo proporciona una metodología repetible, el Canvas de Diseño de Política RBAC, para construir una política de control de acceso empresarial desde cero: ingeniería de roles, mapeo de cumplimiento con NIST SP 800-53 e ISO 27001 Anexo A, y la capa de bóveda de credenciales que convierte la política en algo aplicado en lugar de aspiracional.

Puntos clave

Una política de control de acceso es el documento de gobernanza que define qué roles existen, qué permisos tienen y cómo se revisa y revoca el acceso. RBAC es el modelo de autorización; la política es lo que lo hace aplicable.
La explosión de roles es prevenible. Requiera al menos tres personas realizando la misma función antes de crear un rol como entidad independiente. Maneje las excepciones con permisos suplementarios en lugar de nuevos roles.
El Canvas de Diseño de Política RBAC proporciona una secuencia repetible de seis pasos: mapear el panorama de acceso, definir la granularidad, modelar jerarquías, codificar mínimo privilegio y separación de funciones, documentar la política, y luego construir la aplicación y la cadencia de revisión.
Las políticas RBAC se mapean a controles nombrados, no a lenguaje vago: NIST SP 800-53 (AC-2, AC-5, AC-6), ISO 27001:2022 (5.15, 5.16, 8.2), SOC 2 (CC6.1-CC6.3) y NIS2 Artículo 21(2)(i).
Una política que se detiene en la capa de aplicación ignora donde realmente está el riesgo. Las credenciales comprometidas son la categoría de incidente interno más costosa, con un promedio de $779,000 por evento. La bóveda de credenciales vincula los secretos a roles, no a individuos, cerrando esa brecha.
Las identidades no humanas — cuentas de servicio, claves API y agentes de IA — ahora superan en número a las cuentas humanas en la mayoría de los entornos. Necesitan la misma estructura de roles, reglas de granularidad y cadencia de revisión que los roles humanos, no una exención de la política.
El ciclo de vida de un rol no termina en su creación. La certificación de acceso, el manejo de excepciones y la desactivación vinculada a eventos de alta-traslado-baja son lo que previene que la acumulación de privilegios pase desapercibida.

Qué es una política de control de acceso

Una política de control de acceso es un conjunto documentado de reglas que gobierna quién puede acceder a un recurso, bajo qué condiciones y qué acciones pueden realizar una vez otorgado el acceso. Reemplaza el juicio caso por caso con una lógica fija y auditable que escala a medida que crecen la base de usuarios y la cantidad de recursos de una organización.

Toda política de control de acceso se asienta sobre un modelo de control de acceso, el mecanismo que determina cómo se toma realmente una decisión de acceso. Cuatro modelos cubren la mayoría de las implementaciones empresariales:

DAC (control de acceso discrecional): el propietario del recurso decide quién obtiene acceso, caso por caso, sin paso de aprobación central.
MAC (control de acceso obligatorio): el acceso está fijado por niveles de clasificación impuestos por el sistema, y ningún individuo puede anularlo independientemente de su rol. NIST asocia MAC principalmente con sistemas de alta seguridad que manejan datos clasificados o altamente sensibles.
RBAC (control de acceso basado en roles): el acceso se mapea al rol del usuario dentro de la organización en lugar de su identidad individual.
ABAC (control de acceso basado en atributos): el acceso depende de atributos dinámicos, como departamento, ubicación, hora del día o postura del dispositivo, evaluados en el momento de la solicitud. NIST SP 800-162 define el marco formal que los sistemas federales usan para ABAC.

RBAC se adapta a la mayoría de los entornos empresariales porque las funciones laborales cambian con mucha menos frecuencia que los atributos individuales o los acuerdos de propiedad, y se mapea directamente a cómo las organizaciones ya estructuran el trabajo — por rol, no por persona.

Esa estabilidad es la razón por la cual este artículo construye su metodología de diseño de política específicamente alrededor de RBAC. Los mismos principios de gobernanza — mapear recursos, codificar restricciones, aplicar el acceso en la capa de credenciales — se aplican a cualquiera de los cuatro modelos anteriores, pero RBAC es donde la gestión de credenciales empresariales pasa la mayor parte de su tiempo.

Fundamentos de RBAC: qué gobierna la política de acceso

RBAC organiza el acceso alrededor de tres elementos centrales: usuarios, roles y permisos. La política de control de acceso es el documento que especifica cómo estos elementos se relacionan en una organización específica: qué roles existen, qué permisos tiene cada rol, cómo los roles heredan entre sí, y bajo qué condiciones de sesión el acceso es válido.

Tres elementos componen el modelo base:

Usuarios: se asignan a uno o más roles, nunca se les otorgan permisos directamente.
Roles: agrupan un conjunto de permisos vinculados a una función laboral, no a una persona.
Permisos: son aprobaciones para realizar operaciones específicas, como leer, escribir, eliminar o aprobar, sobre recursos específicos.

La formalización original de RBAC provino de David Ferraiolo y Richard Kuhn en NIST en 1992. Cuatro años después, Ravi Sandhu y colegas extendieron el modelo en cuatro niveles de complejidad creciente: RBAC0 (el modelo base plano anterior), RBAC1 (añade jerarquía de roles), RBAC2 (añade restricciones como separación de funciones) y RBAC3 (combina ambos). La mayoría de las implementaciones empresariales actuales operan en algún punto entre RBAC1 y RBAC2, sin nombrarlo de esa manera.

Nada de esto funciona sin una especificación escrita. El documento de política debe definir:

La convención de nomenclatura para roles.
Quién tiene autoridad para crear un nuevo rol.
Cómo se asignan los permisos a un rol.
Qué restricciones de sesión se aplican a roles sensibles.

Sin esa especificación, la configuración de RBAC se vuelve improvisada, y cada nueva contratación se convierte en una decisión ad hoc en lugar de una aplicación de política.

Lectura relacionada: Para un desglose completo de los componentes centrales de RBAC y dónde encaja en una estrategia más amplia de gestión de acceso, consulte Qué es RBAC y cómo soluciona su problema de acceso.

El Canvas de Diseño de Política RBAC: marco de 6 pasos

El Canvas de Diseño de Política RBAC es una metodología de seis pasos para construir una política RBAC empresarial desde cero: mapear recursos, definir la granularidad de roles, modelar jerarquías, codificar mínimo privilegio y separación de funciones, documentar la política y construir la cadencia de aplicación y revisión. Cada paso produce un artefacto concreto, no solo una discusión.

Esta secuencia importa. Saltar directamente a la creación de roles sin un inventario del panorama de acceso es la razón más común por la cual las organizaciones terminan con roles que no se mapean a funciones laborales reales. Saltarse el paso de aplicación es la razón por la cual las políticas se escriben una vez y nunca se siguen.

Paso 1: mapear el panorama de recursos y acceso de la organización

Antes de definir un solo rol, inventaríe lo que necesita protegerse: aplicaciones, bases de datos, componentes de infraestructura, carpetas compartidas y servicios de terceros. Para cada recurso, registre su sensibilidad de datos, quién tiene acceso actualmente y cómo se otorgó ese acceso.

Este paso revela la brecha entre el acceso asumido y el real casi de inmediato. En una organización mediana con 500 o más empleados y más de 30 aplicaciones, espere que este inventario revele otorgamientos de acceso que nadie puede explicar: antiguos miembros de proyectos con permisos persistentes, cuentas de servicio con acceso de nivel humano y credenciales compartidas que nadie posee. Documente estos como hallazgos, no como correcciones todavía.

Paso 2: definir reglas de granularidad de roles para prevenir la explosión de roles

La explosión de roles ocurre cuando los roles se crean por persona o por excepción en lugar de por función laboral. Establezca una regla estricta antes de crear cualquier rol: un rol debe mapearse a una función realizada por tres o más personas, o no se crea como un rol independiente.

Para la excepción individual rara, use un otorgamiento de permiso suplementario sobre un rol existente en lugar de un rol a medida. Esta única regla, aplicada desde el día uno, es el control más efectivo contra la proliferación de roles. Las organizaciones que la omiten típicamente descubren de 300 a 500 roles para unos pocos cientos de empleados en dos años.

Paso 3: modelar jerarquías de roles y estructuras de herencia

Agrupe roles en una jerarquía que refleje la estructura organizacional y la antigüedad, no la política del organigrama. Un modelo jerárquico (RBAC1 en la taxonomía de Sandhu) permite que los roles superiores hereden automáticamente los permisos de los inferiores, reduciendo las asignaciones de permisos redundantes.

Mantenga la profundidad de la jerarquía baja, generalmente de tres a cuatro niveles. Las jerarquías más profundas se vuelven difíciles de auditar porque un permiso otorgado en la cima puede propagarse a través de cadenas de herencia que nadie rastrea durante una revisión. Los modelos planos son más fáciles de auditar pero requieren más asignaciones de permisos explícitas por rol.

Paso 4: codificar restricciones de mínimo privilegio y separación de funciones

El mínimo privilegio y la separación de funciones son las dos restricciones que convierten una lista de roles en una política gobernada. Según NIST SP 800-53 Revisión 5, el control AC-6 requiere que las organizaciones empleen el principio de mínimo privilegio, permitiendo solo los accesos autorizados necesarios para cumplir las tareas asignadas (NIST SP 800-53 Rev. 5). El control AC-5 requiere separación de funciones, dividiendo las funciones críticas entre diferentes individuos para reducir el riesgo de fraude y error.

En la práctica, esto significa escribir reglas de conflicto explícitas en la política: el rol que aprueba órdenes de compra no puede ser también el rol que crea registros de proveedores. Codifique estas como restricciones documentadas que el proceso de revisión de acceso verifica, no como conocimiento tribal que posee un solo oficial de cumplimiento.

Paso 5: documentar la política en un formato vivo y auditable

Documente el propósito de cada rol, los permisos que tiene, su propietario de aprobación y su última fecha de revisión en un formato estructurado y con control de versiones que los auditores y nuevos administradores puedan leer sin tener que hacer ingeniería inversa del sistema de acceso.

Este documento se convierte en la referencia que un auditor verifica contra el estado real del sistema. Las discrepancias entre el documento y la realidad son exactamente lo que las auditorías de cumplimiento están diseñadas para detectar.

Paso 6: construir la cadencia de aplicación y revisión

Una política sin aplicación es una declaración de intenciones. La aplicación significa que cada otorgamiento de acceso fluye a través de un punto de aplicación de política — un punto de control técnico o procedimental que verifica que una solicitud coincide con la política documentada antes de otorgar acceso — ya sea un sistema IAM, un flujo de trabajo de aprobación o una bóveda de credenciales.

Combine la aplicación con una cadencia de revisión fija: certificación de acceso trimestral para roles estándar, revisión más frecuente para roles privilegiados y administrativos. La certificación de acceso — la re-aprobación periódica de quién tiene qué acceso — es el mecanismo que detecta la acumulación de privilegios antes de que se convierta en un hallazgo de auditoría.

Diseñar estructuras de roles en papel es una cosa. Aplicarlas en la capa de credenciales es otra. Vea cómo el acceso a bóvedas basado en roles de Passwork vincula secretos a roles en lugar de individuos.

Mapeo de cumplimiento: qué controles debe abordar su política RBAC

Las políticas RBAC empresariales se mapean directamente a controles específicos en NIST SP 800-53, ISO 27001 Anexo A, SOC 2 y, para entidades reguladas en la UE, la directiva NIS2 — no a lenguaje vago de «gestión de acceso». Los auditores verifican estos controles por ID, y una política que no los referencia explícitamente hace más lenta la recolección de evidencia y más probables los hallazgos de auditoría.

La familia de Control de Acceso (AC) de NIST SP 800-53 Revisión 5 define la línea base. AC-2 (Gestión de Cuentas) requiere un proceso documentado para crear, habilitar, modificar y deshabilitar cuentas. AC-5 (Separación de Funciones) requiere dividir las funciones entre individuos para reducir el riesgo de colusión. AC-6 (Mínimo Privilegio) requiere restringir el acceso solo a lo que un rol necesita (NIST SP 800-53 Rev. 5).
ISO 27001:2022 reestructuró sus controles del Anexo A en cuatro temas con 93 controles totales, reemplazando los dominios numerados de la versión 2013 (A.9 para control de acceso). Los controles equivalentes de 2022 relevantes para RBAC son 5.15 (Control de acceso), 5.16 (Gestión de identidad), 5.18 (Derechos de acceso) y 8.2 (Derechos de acceso privilegiado), que juntos requieren una política formal de control de acceso, registro controlado de usuarios y gestión de acceso privilegiado (ISO/IEC 27001:2022).
Los Criterios de Servicios de Confianza de SOC 2 abordan el mismo territorio bajo CC6.1 a CC6.3, cubriendo controles de acceso lógico, registro y cancelación de usuarios, y aprovisionamiento basado en roles alineado con el mínimo privilegio.

Para las organizaciones en el alcance de la directiva NIS2 de la UE, el Artículo 21(2)(i) nombra explícitamente las políticas de control de acceso y la gestión de activos entre las medidas requeridas de gestión de riesgos de ciberseguridad, poniendo la documentación RBAC al mismo nivel que el manejo de incidentes y los requisitos de seguridad de la cadena de suministro bajo el mismo artículo (Directiva (UE) 2022/2555, Artículo 21).

Marco de control	ID de control	Requisito	Elemento de política RBAC
NIST SP 800-53 Rev. 5	AC-2	Ciclo de vida de gestión de cuentas	Procedimientos de creación, modificación y desactivación de roles
NIST SP 800-53 Rev. 5	AC-5	Separación de funciones	Reglas documentadas de conflicto de roles
NIST SP 800-53 Rev. 5	AC-6	Mínimo privilegio	Alcance granular de permisos por rol
ISO 27001:2022	5.15	Política de control de acceso	Documento de política RBAC escrito
ISO 27001:2022	5.16	Gestión de identidad	Proceso de asignación usuario-a-rol
ISO 27001:2022	8.2	Derechos de acceso privilegiado	Revisión y aprobación de roles elevados
SOC 2	CC6.1	Controles de acceso lógico	Puntos de aplicación de política
SOC 2	CC6.2	Registro y autorización	Flujo de trabajo de asignación de roles en incorporación
SOC 2	CC6.3	Aprovisionamiento basado en roles	Mínimo privilegio y certificación de acceso
Directiva NIS2	Art. 21(2)(i)	Políticas de control de acceso y gestión de activos	Política RBAC como medida nombrada de gestión de riesgos

La bóveda de credenciales como aplicación de RBAC: la capa que falta

Las definiciones de roles carecen de sentido si las credenciales detrás de ellas están escritas en una hoja de cálculo o son conocidas por personas fuera del rol. Una política RBAC que se detiene en la capa de aplicación — decidiendo quién puede hacer clic en qué dentro de una app — ignora la capa donde ocurre la mayoría del daño real: las credenciales, claves API y secretos que otorgan acceso directo al sistema.

El Informe Global de Costo de Riesgos Internos 2025 del Instituto Ponemon sitúa el costo anual promedio de incidentes de riesgo interno en $17.4 millones por organización, frente a los $16.2 millones de 2023. Dentro de ese total, las credenciales comprometidas son la categoría de incidente más costosa, con un promedio de $779,000 por evento, más alto que los incidentes causados solo por negligencia o intención maliciosa. Una gran parte de estos incidentes se remonta a credenciales compartidas u huérfanas que sobrevivieron al proceso de revisión de acceso porque nadie las poseía a nivel de credencial — solo a nivel de aplicación.

La bóveda de credenciales cierra esta brecha vinculando el acceso a secretos a roles en lugar de individuos — el mismo principio que RBAC aplica a los permisos de aplicación. Cuando al rol de ingeniero DevOps se le otorga acceso a un secreto de pipeline CI/CD a través del gestor de contraseñas y secretos Passwork, la política se aplica en la capa de credenciales, no solo dentro de la aplicación:

Añada a alguien al rol, y heredará exactamente los secretos que ese rol requiere, ni más.
Elimínelo, y el acceso a cada credencial vinculada a ese rol se revoca de una vez.

Esto importa más para la gestión de acceso privilegiado (PAM). Las credenciales de administrador permanentes, las contraseñas root de bases de datos y las claves de proveedores en la nube son los activos que los atacantes apuntan primero, y también son los activos más propensos a terminar en un documento compartido si no existe una capa de bóveda. El registro de auditoría de Passwork registra cada recuperación de credencial por rol y por usuario, dando a los oficiales de cumplimiento el mismo rastro de evidencia para secretos que la certificación de acceso ya proporciona para roles de aplicación.

La gobernanza de cuentas compartidas es el modo de fallo específico que esto aborda: un único inicio de sesión de servicio o admin usado por seis personas porque nadie construyó cuentas individuales para un sistema heredado. Una bóveda con acceso basado en roles permite que esas seis personas retengan la conveniencia de una credencial compartida mientras se preserva la responsabilidad individual, ya que cada recuperación se registra contra la persona, no solo contra la cuenta.

Gobernanza del ciclo de vida de roles: de la creación a la retirada

La política RBAC gobierna un rol desde el momento en que se crea hasta el momento en que se desactiva, siguiendo un ciclo de alta-traslado-baja (JML por sus siglas en inglés) al que la mayoría de los fallos de auditoría se remontan por incorporación incompleta o cambios de rol. Un rol que no se retira cuando su función desaparece se convierte exactamente en el tipo de privilegio de acceso huérfano del que la acumulación de privilegios se alimenta.

El ciclo de vida se divide en cuatro etapas gobernadas:

Creación de rol requiere una justificación de negocio documentada, un propietario de aprobación y un mapeo a las reglas de granularidad establecidas en la fase de diseño de política. Ningún rol se crea sin pasar por este punto de control.
Certificación de acceso es la re-aprobación periódica de cada asignación usuario-a-rol, típicamente trimestral para roles estándar y mensual para los privilegiados. Este es el control que detecta la acumulación de privilegios — la acumulación gradual de derechos de acceso que sobreviven su justificación a medida que los empleados cambian de equipo o proyecto.
Manejo de excepciones cubre los otorgamientos de acceso temporal que caen fuera de los roles estándar, como un contratista que necesita acceso con tiempo limitado a un sistema de producción. Estos deberían expirar automáticamente en lugar de depender de que alguien recuerde revocarlos.
Desactivación de rol retira roles y su acceso asociado cuando la función subyacente ya no existe, siguiendo el mismo proceso de aprobación que la creación, pero a la inversa.

El modelo de alta-traslado-baja vincula este ciclo de vida a eventos de empleo reales: un alta es aprovisionado en un rol, un traslado desencadena la desprovisión del rol anterior y el aprovisionamiento en el nuevo, y una baja desencadena la desprovisión inmediata en todos los sistemas.

Errores comunes en el diseño de política RBAC y cómo evitarlos

La mayoría de los fallos de RBAC empresariales se remontan a cinco errores recurrentes: explosión de roles, asignación de roles por copia, ignorar identidades de máquina, políticas estáticas sin ciclos de revisión y confundir RBAC con inicio de sesión único. Cada uno es prevenible con un control de política específico.

Explosión de roles. Crear un rol único por persona en lugar de por función produce cientos de roles que nadie puede auditar. Solución: aplique la regla del mínimo de tres personas del Paso 2 del canvas de diseño antes de crear cualquier rol.
Asignación de roles por copia. Otorgar a un nuevo empleado «el mismo acceso que [empleado existente]» propaga cualquier error de acceso que ese empleado ya acumuló, incluyendo permisos que debería haber perdido hace meses. Solución: asigne roles basándose en la función laboral documentada, nunca copiando el estado actual de otro usuario.
Ignorar cuentas de servicio e identidades de máquina. Las políticas RBAC frecuentemente definen roles humanos en detalle mientras las cuentas de servicio, claves API y credenciales de automatización se aprovisionan completamente fuera de la política, a menudo con privilegios permanentes excesivos. Solución: incorpore cada identidad no humana en la misma estructura de roles y cadencia de revisión que los roles humanos.
Política estática sin ciclos de revisión periódica. Un documento de política escrito una vez y nunca revisado se desvía de la configuración real del sistema en meses. Solución: vincule cada rol a una fecha de revisión obligatoria, aplicada por el proceso de certificación de acceso, no dejada a discreción.
Confundir RBAC con inicio de sesión único. SSO controla la autenticación — verificar quién es alguien. RBAC controla la autorización — determinar qué puede hacer una vez verificado. Las organizaciones que tratan la implementación de SSO como «resolver el control de acceso» dejan la capa de autorización sin definir. Solución: trate el diseño de política RBAC como un proyecto separado de la implementación de SSO, incluso cuando ambos se implementen juntos.

RBAC para identidades no humanas: cuentas de servicio, APIs y agentes de IA

Las identidades no humanas — cuentas de servicio, claves API y, cada vez más, agentes de IA autónomos — ahora superan en número a las cuentas de usuario humanas en la mayoría de los entornos empresariales, pero los modelos RBAC fueron diseñados alrededor de sesiones humanas y rara vez contemplan patrones de acceso máquina-a-máquina. Extender la política RBAC para cubrirlas ya no es opcional.

Una cuenta de servicio que ejecuta una copia de seguridad de base de datos nocturna no encaja en el modelo de sesión que RBAC asume: sin pantalla de inicio de sesión, sin restricciones de sesión interactiva, a menudo una credencial que nunca rota porque rotarla arriesga romper un trabajo de producción. Las claves API agravan esto: una sola clave filtrada puede otorgar el mismo acceso que un rol administrativo completo, pero la gestión de claves a menudo vive fuera del sistema IAM por completo, rastreada en archivos de configuración o variables de entorno en lugar de en una bóveda gobernada.

Los agentes de IA introducen una variante más nueva: un agente actuando en nombre de un usuario o sistema que necesita permisos limitados y auditables en lugar del acceso amplio conveniente para el desarrollo. Trate las credenciales de agentes de la misma manera que trataría un rol de contratista — con tiempo limitado, alcance reducido y revisados en la misma cadencia que el acceso humano privilegiado, no exentos de la política porque el solicitante no es una persona.

La solución práctica es estructural: incorpore las identidades no humanas en la misma jerarquía de roles, reglas de granularidad y ciclo de certificación de acceso definidos para humanos en el Canvas de Diseño de Política RBAC. Una bóveda de credenciales que soporte acceso basado en roles para claves API y secretos de cuentas de servicio — no solo inicios de sesión humanos — cierra la brecha entre política y práctica aquí.

Construir la política que hace funcionar RBAC

Una implementación de RBAC vive o muere por la calidad de su política. Las organizaciones que evitan la explosión de roles, la acumulación de privilegios y el caos de auditoría son las que mapearon su panorama de acceso, escribieron reglas de granularidad y construyeron una cadencia de revisión antes de asignar un solo permiso.

El Canvas de Diseño de Política RBAC le proporciona esa secuencia. El mapeo de cumplimiento le da los ID de control específicos que un auditor preguntará. Lo que queda es la aplicación: una política bien diseñada especifica qué roles acceden a qué recursos, pero permanece teórica hasta que algo vincule credenciales a esos roles automáticamente.

Comience con un recurso de alto riesgo, ejecútelo a través de los seis pasos del canvas, y úselo como plantilla para el resto de la organización.

Una política RBAC documentada es tan fuerte como su aplicación. Passwork vincula secretos, contraseñas y claves API a roles, no a individuos, para que el acceso permanezca controlado, auditable y revocable por diseño. Vea cómo funciona el acceso basado en roles en Passwork.

Preguntas frecuentes

¿Cuál es la diferencia entre una política de control de acceso y una política RBAC?

Una política de control de acceso es el documento de gobernanza más amplio que cubre todos los modelos de autorización que usa una organización. Una política RBAC es una implementación específica de esa política más amplia, definiendo roles, permisos y reglas de asignación de roles. Toda política RBAC es una política de control de acceso, pero no toda política de control de acceso usa RBAC exclusivamente.

¿Cómo se diseña RBAC desde cero en una organización sin roles existentes?

Comience con el Paso 1 del Canvas de Diseño de Política RBAC: inventaríe cada recurso, aplicación y repositorio de datos en toda la organización. Luego aplique minería de roles para mapear los patrones de acceso reales de los usuarios a funciones laborales, defina reglas de granularidad antes de crear cualquier rol y documente la política con una cadencia de revisión fija.

¿Quién debería ser propietario de la política RBAC: TI, seguridad o RRHH?

Seguridad o TI típicamente poseen la implementación técnica y la aplicación, mientras que RRHH proporciona los disparadores de alta-traslado-baja que impulsan la asignación de roles. Ninguno debería poseerla solo. Las políticas efectivas asignan un propietario de política nombrado en seguridad o cumplimiento, con RRHH y líderes de unidades de negocio como aprobadores requeridos para la creación de roles.

¿Cómo se maneja el acceso de contratistas y terceros en RBAC?

Cree roles separados con tiempo limitado para contratistas en lugar de otorgarles roles estándar de empleados. Establezca una fecha de expiración automática vinculada a la fecha de fin del contrato, restrinja las restricciones de sesión a horarios de oficina cuando sea factible y requiera certificación de acceso más frecuente para roles de contratista que para roles de empleados a tiempo completo.

¿Cómo se previene la explosión de roles?

Aplique un umbral mínimo, como tres o más personas realizando la misma función, antes de crear un rol independiente. Maneje las excepciones individuales con otorgamientos de permisos suplementarios sobre un rol existente en lugar de crear nuevos roles, y revise el conteo total de roles contra la cantidad de empleados en cada ciclo de certificación.