Diseño de Estrategias de Grupo para Acceso a Recursos Recorreremos, en detalle, la estrategia de grupos para los siguientes escenarios: Single Domain Forest. Estrategias de Grupo para Escenarios Single Domain Forest de Active Directory Estrategia Elegida En Escenarios Single Domain Forest, la asignación de permisos es un tanto distinta a la anterior. Para estos escenarios, se puede utilizar el acrónimo “IGDLA” para la asignación de permisos. IGDLA es el acrónimno de: • Identities -> Cuentas de usuario o de computadora…
• Global Group -> van dentro de grupos “Global Group”, que representan roles o funciones… • Domain Local -> los cuales deben estar en grupos “Domain Local”, que representan reglas de negocio… • Access -> y éstos últimos sirven para dar “Access” (acceso) a los recursos. IGDLA también es conocido como AGDLP, que es el acrónimo de:
• Accounts -> Las cuentas de usuario… • Global Group -> van dentro de grupos “Global Groups”… • Domain Local -> los cuales deben estar en grupos “Domain Local”… • Permissions -> y estos últimos sirven para asignar “Permissions” a los recursos. El cambio de AGDLP a IGDLA se corresponde a la definición más general del alcance de la aplicación de esta estrategia, dado que no solo se aplica a cuentas de usuario (Accounts) sino a Identidades. La estrategia IGDLA resume la recomendación de Microsoft para la implementación de RBAC en ambientes de “Single Domain Forest” y, también (como veremos más adelante) en relaciones de confianza Cross-Forest. Esta recomendación se corresponde con el uso de los diferentes alcances explicados anteriormente, esto sería: Los Grupos Globales (Global Groups) deberían representar roles, porque los roles son generalmente colecciones de objetos del mismo directorio. Por ejemplo, grupos globales llamados “Contabilidad”, “Administración” y “Gerencia” pueden representar quiénes forman parte del área Contabilidad, Administración y Gerencia respectivamente. Los Grupos de Dominio Local (Domain Local Groups) son usados principalmente para administrar permisos a recursos. Básicamente, se utilizan para administrar reglas de negocio, como por ejemplo reglas de acceso a recursos. Por ejemplo: “ACL_Contabilidad_Write” ó “ACL_Administracion_Read” puede ser usado para administrar permisos de escritura y lectura a carpetas de contabilidad y administración respectivamente. Nomenclatura Para este escenario, indicar el nombre del dominio sería “malgastar” caracteres que podemos utilizar para otra función. La nomenclatura de los grupos elegida para este escenario podría ser la siguiente: Para los Grupos Globales (Global Groups): o Una parte del nombre podría indicar su alcance. Por ejemplo, se podría utilizar la nomenclatura “GG” para los “Global Groups”. o Otra parte del nombre podría indicar su nombre, propiamente dicho. Por ejemplo, “Administracion” ó “Gerencia”. o Ejemplos de esta nomenclatura: GG_Administracion, GG_Gerencia. Para los Grupos Locales de Dominio (Domain Local Groups): o Una parte del nombre podría indicar la función para la cual es creado. Por ejemplo, se podría utilizar la nomenclatura “FILES” indicando que son grupos “Domain Local Groups” que definirán accesos a recursos de fileserver. Si, en cambio, los grupos definirán permisos de Administración (por ejemplo de servidores), se podría utilizar la nomenclatura “ADMIN”. o Otra parte del nombre podría indicar el nombre del recurso al cual se dará acceso. Por ejemplo, “Balances”, “Sueldos”, “RRHH” ó “Gerencia” en el caso de estar hablando de carpetas. Si hablaramos de servidores o ambientes, podríamos utilizar “PRODUCCION”, “SERVER1″, etc. o Otra parte podría indicar el nivel de acceso: “Read”, “Write”, “Full”, etc. o Ejemplos de estas nomenclaturas: “FILES_Sueldos_Read” y “FILES_RRHH_Write” para nomenclaturas de acceso a files. “ADMIN_PRODUCCION_FULL” y “ADMIN_SERVER1″ para el acceso a administrar equipos o ambientes. La convención elegida se sugiere respetar en toda la implementación y muchas convenciones (depende su aplicación) pueden ser utilizadas a la vez J. Como vemos, los nombres deberían ser lo más simples y representativos del área / sector /unidad de negocio y, también, del recurso y tipo de acceso que querramos dar acceso. Vamos a realizar, en el siguiente ítem, un escenario práctico. Ejemplo de Aplicación Vamos a ejemplificar esto que acabamos de ver en una aplicación para acceso a archivos. Supongamos que existe el siguiente escenario: Single Domain: llamado “weasel.org”. Las siguientes Áreas y Usuarios: o Administración: Juan. Pedro. o Recursos Humanos: Mariana. o Gerencia: