Hispanopedia WikiAGDLP ( abreviatura de "cuenta, global, dominio local, permiso") resume brevemente las recomendaciones de Microsoft para implementar controles de acceso basados en roles (RBAC) mediante grupos anidados en un dominio de Active Directory (AD) en modo nativo : Las cuentas de usuario y de equipo son miembros de grupos globales que representan roles empresariales, que son miembros de grupos locales de dominio que describen permisos de recursos o asignaciones de derechos de usuario. AGUDLP (abreviatura de "cuenta, global, universal, dominio local, permiso") y AGLP (abreviatura de "cuenta, global, local, permiso") resumen esquemas de implementación de RBAC similares en bosques de Active Directory y en dominios de Windows NT , respectivamente.
Detalles
Los controles de acceso basados en roles (RBAC) simplifican las operaciones rutinarias de administración de cuentas y facilitan las auditorías de seguridad . [1] Los administradores de sistemas no asignan permisos directamente a cuentas de usuario individuales . En cambio, las personas adquieren acceso a través de sus roles dentro de una organización, lo que elimina la necesidad de editar una cantidad potencialmente grande (y que cambia con frecuencia) de permisos de recursos y asignaciones de derechos de usuario al crear, modificar o eliminar cuentas de usuario. A diferencia de las listas de control de acceso tradicionales , los permisos en RBAC describen operaciones significativas dentro de una aplicación o sistema en particular en lugar de los métodos de acceso a objetos de datos de bajo nivel subyacentes. Almacenar roles y permisos en una base de datos centralizada o un servicio de directorio simplifica el proceso de determinar y controlar las membresías de roles y los permisos de roles. [2] Los auditores pueden analizar las asignaciones de permisos desde una única ubicación sin tener que comprender los detalles de implementación específicos de los recursos de un control de acceso en particular.
RBAC en un solo dominio AD
La implementación de RBAC por parte de Microsoft aprovecha los diferentes ámbitos de grupos de seguridad que aparecen en Active Directory: [3] [4]
- Grupos de seguridad global
- Los grupos de seguridad de dominio con alcance global representan funciones empresariales o laborales dentro del dominio. Estos grupos pueden contener cuentas y otros grupos globales del mismo dominio, y pueden ser utilizados por recursos de cualquier dominio del bosque. Se pueden modificar con frecuencia sin provocar una replicación del catálogo global.
- Grupos de seguridad locales de dominio
- Los grupos de seguridad de dominio con ámbito local de dominio describen los permisos de bajo nivel o los derechos de usuario a los que están asignados. Estos grupos solo pueden ser utilizados por sistemas del mismo dominio. Los grupos locales de dominio pueden contener cuentas, grupos globales y grupos universales de cualquier dominio, así como grupos locales de dominio del mismo dominio.
Los grupos globales que representan roles empresariales deben contener únicamente cuentas de usuario o de equipo. Del mismo modo, los grupos locales de dominio que describen permisos de recursos o derechos de usuario deben contener únicamente grupos globales que representen roles empresariales. Nunca se deben otorgar permisos o derechos directamente a las cuentas o roles empresariales, ya que esto complica el análisis posterior de los derechos.
RBAC en bosques AD
En entornos multidominio, los diferentes dominios dentro de un bosque de AD solo pueden estar conectados por enlaces WAN o conexiones VPN , por lo que los controladores de dominio especiales llamados servidores de catálogo global almacenan en caché ciertas clases de objetos de directorio y tipos de atributos para reducir las costosas o lentas búsquedas de directorios entre dominios. [5] Los objetos almacenados en caché por los servidores de catálogo global incluyen grupos universales pero no grupos globales, lo que hace que las búsquedas de membresía de grupos universales sean mucho más rápidas que las consultas similares de grupos globales. Sin embargo, cualquier cambio en un grupo universal desencadena la replicación del catálogo global (potencialmente costosa), y los cambios en los grupos universales requieren derechos de seguridad para todo el bosque, lo que no es apropiado en la mayoría de las grandes empresas. Estas dos limitaciones impiden que los grupos de seguridad universales reemplacen por completo a los grupos de seguridad globales como los únicos representantes de los roles comerciales de una empresa. En cambio, las implementaciones de RBAC en estos entornos utilizan grupos de seguridad universales para representar roles en toda la empresa al tiempo que conservan grupos de seguridad globales específicos del dominio, como lo ilustra la abreviatura AGUDLP .
RBAC en dominios que no son AD
Los dominios en Windows NT 4.0 y anteriores sólo tienen grupos globales (a nivel de dominio) y locales (no de dominio) y no admiten la anidación de grupos a nivel de dominio. [6] La abreviatura AGLP se refiere a estas limitaciones tal como se aplican a las implementaciones de RBAC en dominios más antiguos: los grupos globales representan roles comerciales, mientras que los grupos locales (creados en los propios servidores miembros del dominio) representan permisos o derechos de usuario.
Ejemplo
Dada una carpeta compartida, \\nyc-ex-svr-01\groups\bizdev ; un grupo de desarrollo comercial dentro del departamento de marketing de la organización, representado en Active Directory como el grupo de seguridad global (existente) "Miembro del equipo de desarrollo comercial"; y un requisito de que todo el grupo tenga acceso de lectura y escritura a la carpeta compartida, un administrador que siga AGDLP podría implementar el control de acceso de la siguiente manera:
- Cree un nuevo grupo de seguridad local de dominio en Active Directory llamado "Modificar permiso en \\nyc-ex-svr-01\groups\bizdev".
- Otorgue a ese grupo local de dominio el conjunto de permisos NTFS "Modificar" (leer, escribir, ejecutar/modificar, eliminar) en la carpeta "bizdev". (Tenga en cuenta que los permisos NTFS son diferentes a los permisos de uso compartido ).
- Convierta al grupo global “Miembro del equipo de desarrollo de negocios” en miembro del grupo local del dominio “Cambiar permiso en \\nyc-ex-svr-01\groups\bizdev”.
Para resaltar las ventajas de RBAC usando este ejemplo, si el Equipo de Desarrollo de Negocios requiriera permisos adicionales en la carpeta "bizdev", un administrador del sistema solo necesitaría editar una única entrada de control de acceso (ACE) en lugar de, en el peor de los casos, editar tantas ACE como usuarios con acceso a la carpeta.
Referencias
- ^ Ferraiolo, DF; Kuhn, DR (octubre de 1992). "Control de acceso basado en roles" (PDF) . 15.ª Conferencia Nacional de Seguridad Informática . págs. 554–563.
- ^ Sandhu, R.; Coyne, EJ; Feinstein, HL; Youman, CE (agosto de 1996). "Modelos de control de acceso basados en roles" (PDF) . IEEE Computer . 29 (2): 38–47. CiteSeerX 10.1.1.50.7649 . doi :10.1109/2.485845. S2CID 1958270.
- ^ Microsoft Corporation (16 de marzo de 2007). «Ámbitos de grupo: Active Directory». Microsoft Technet . Archivado desde el original el 14 de marzo de 2009. Consultado el 28 de abril de 2009 .
- ^ Melber, Derek (18 de mayo de 2006). "Cómo anidar usuarios y grupos para permisos". WindowsSecurity.com . Consultado el 28 de abril de 2009 .
- ^ Microsoft Corporation (21 de enero de 2005). "Descripción del catálogo global: Active Directory". Microsoft Technet . Consultado el 21 de octubre de 2005 .
- ^ Stanek, William R. "Understanding User and Group Accounts" (Descripción de las cuentas de usuario y grupo). Microsoft Technet . Archivado desde el original el 27 de abril de 2009. Consultado el 28 de abril de 2009 .