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:
Jorge. Rodrigo.
Vamos a diseñar la estrategia de grupos para estas áreas y usuarios. Cuando hablamos de áreas o “roles” hablamos de “Global Groups”. Por eso primero comencemos con los Grupos Globales que debemos crear. Vamos a respetar la nomenclatura sugerida en el punto anterior, por lo cual tendremos los siguientes 3 grupos globales que representan a nuestras áreas y sus integrantes: • GG_Administracion: o Juan. o Pedro. • GG_RRHH: o Mariana. • GG_Gerencia: o Jorge. o Rodrigo. Ahora, supongamos que existen los siguientes recursos compartidos (carpetas): Los siguientes recursos compartidos: o Administración: Debería tener acceso de lectura y escritura “Juan”, “Pedro” y “Gerencia”. o RRHH: Debería tener acceso de lectura y escritura “Mariana” y “Gerencia”. Debería tener acceso de solo lectura “Administracion”. o Gerencia: Sólo deberían poder ingresar con acceso de lectura y escritura “Jorge” y “Rodrigo”. Ahora vamos a definir los Grupos de Dominio Local que, recordemos, deberían representar permisos de bajo nivel o los derechos de usuario correspondientes a los recursos compartidos. Siguiendo con esta lógica, obtendríamos los siguientes Grupos de Dominio Local (Domain Local): • FILES_AdminCobros_Write.
• FILES_RRHH_Write. • FILES_RRHH_Read. • FILES_Gerencia_Write. En base a los requerimientos, hemos creado los grupos que representan nuestros permisos de bajo nivel. Ahora bien: ¿quién formará parte de cada uno de los Grupos de Dominio Local? Los siguientes: • FILES_AdminCobros_Write: o GG_Administracion. o GG_Gerencia. • FILES_RRHH_Write: o GG_RRHH. o GG_Gerencia. • FILES_RRHH_Read: o GG_Administracion. • FILES_Gerencia_Write: o GG_Gerencia. Como último paso, debemos ingresar los grupos Domain Local (FILES) en las carpetas correspondientes (recursos compartidos) y asignarles los permisos que corresponden. Cuando hablamos de “asignar permisos” nos estamos refiriendo a indicar si tendrán un acceso de lectura o lectura y escritura a nivel NTFS (es decir generar los “Access Control Entires” ó ACE). Realizada esta acción, ya tenemos asignados nuestros permisos de acceso tal cual nos fue solicitado J. Ahora bien, podemos ver rápidamente como se simplifica la administración de los permisos en base a la estrategia elegida: Si ingresara una nueva persona a Recursos Humanos, solo deberíamos agregarla al grupo “GG_RRHH”, y por anidamiento obtendría los permisos a los cuales dicho sector está asignado. Si, en cambio, algún Gerente deja su cargo pero sigue perteneciendo a la empresa, solo deberíamos quitarlo del grupo “GG_Gerencia” y automáticamente dicho usuario ya no tendría más acceso a dicha información sensible.
Lo primero de todo, creamos los usuarios
Ahora los Grupos Globales
Incluimos los usuarios correspondientes en cada grupo global
Ahora pasamos a crear nuestros grupos de dominio local, donde incluiremos los grupos globales
En cada grupo de dominio local, los grupos globales correspondientes
Creamos los recursos compartidos en nuestro servidor (Tres carpetas)
Pasamos a dar los permisos tanto en compartir como en seguridad de cada recurso compartido Carpeta ADMINISTRACION
Carpeta GERENCIA
Carpeta RRHH
Ya s贸lo nos queda probar el acceso, vamos a ir entrando desde una m谩quina asociada al dominio con los distintos usuarios y comprobando si funcionan correctamente las restricciones a las carpetas. Usuario Jorge (Gerencia), tiene acceso a las tres carpetas
Usuario Rodrigo (Gerencia), tiene acceso a las tres carpetas
Usuario Mariana (RRHH), s贸lo deber铆a de tener acceso al propio recurso de RRHH
Usuario Juan (Administraci贸n), s贸lo deber铆a de tener acceso lectura y escritura a ADMINISTRACION y lectura a RRHH
Usuario Pedro (Administraci贸n), s贸lo deber铆a de tener acceso lectura y escritura a ADMINISTRACION y lectura a RRHH