¿Es este un enfoque recomendado / válido para los permisos del servidor de archivos?

Los servidores de archivos son una realidad en TI y tengo curiosidad por saber si existen prácticas generalmente aceptadas (dudo en usar la palabra "mejor" aquí) sobre cómo crear grupos y aplicar permisos para administrar el acceso del cliente a una carpeta compartida en Un servidor de archivos.

En mi trabajo actual, terminé heredando un montón de formas diferentes de hacerlo, desde docenas de grupos en las ACL hasta simplemente poner usuarios individuales directamente en el sistema de archivos. Mi tarea era limpiar el desorden y encontrar algún tipo de forma estandarizada de abordar esto en toda la empresa (gran entorno, 150,000 empleados, 90,000 computadoras cliente, 100 servidores de archivos).

Según tengo entendido, parece que, como mínimo, necesita un grupo por nivel de acceso requerido por recurso protegido. Este modelo parece ofrecer la mayor flexibilidad, ya que no es necesario volver a tocar los permisos del sistema de archivos a menos que necesite admitir un nivel de acceso diferente. La desventaja es que creará más grupos que si reutiliza el mismo grupo en múltiples recursos compartidos.

Aquí hay un ejemplo que muestra lo que quiero decir:

Hay un recurso compartido llamado "Resultados de la prueba" en un servidor de archivos llamado FILE01 y tiene personas que necesitan acceso de solo lectura, acceso de lectura y escritura y control total. 1 recurso seguro * 3 niveles de acceso = 3 grupos de seguridad. En nuestro entorno de AD, creamos estos como grupos universales para que podamos agregar fácilmente usuarios / grupos de cualquiera de los dominios en el bosque. Dado que cada grupo se refiere únicamente a una carpeta compartida y a un nivel de acceso, los nombres de los grupos incorporan esos datos "clave" y los permisos son:

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

Por lo general, también incluiríamos la cuenta SYSTEM integrada y los administradores incorporados con acceso de Control total también. Cualquier cambio en quién realmente tiene acceso a este recurso compartido ahora se puede manejar usando membresías de grupo en lugar de tener que tocar la ACL (ya sea agregando grupos de "Roles" que representan roles comerciales específicos como Gerentes, Técnicos, Analistas de control de calidad, etc. o solo individualmente usuarios para acceso único).

Dos preguntas:

1) ¿Es realmente un enfoque recomendado o válido para manejar permisos o me falta alguna solución más simple y elegante? Me interesaría especialmente cualquier solución que use la herencia pero que aún conserve la flexibilidad de no tener que volver a ACL grandes partes de los sistemas de archivos cuando las cosas cambian.

2) ¿Cómo maneja los permisos del servidor de archivos y la estructura de grupo en su entorno? Puntos de bonificación para aquellos que también trabajan en entornos grandes.

Mi enfoque es no usar permisos de archivo a nivel de archivo / directorio; use permisos de nivel de uso compartido de archivos y configure toda la unidad de datos del sistema de archivos del servidor en Control total para todos (que se convierte en discutible).

Con los años (más de 10), descubrí que los permisos NTFS son más complejos y generan más errores. Si los permisos están configurados incorrectamente, o la herencia se rompe, expone los datos y es difícil de encontrar y ver. Además, está expuesto al problema de mover / copiar ... los usuarios que mueven archivos también mueven la ACL del archivo, mientras que la copia hereda la ACL de destino.

Use sus grupos de lectura / escritura de la misma manera, pero en todo el archivo compartido usando Comp Mgmt MMC. No lo hagas por completo ... los usuarios se dispararán a sí mismos con conocimiento parcial / mejores intenciones.

Ese enfoque no es malo. Como regla, nunca use usuarios individuales para agregar permisos; use un grupo. Sin embargo, los grupos pueden usarse en todos los recursos. Por ejemplo, HR podría tener acceso RW a los archivos, mientras que MANAGERS podría tener R. También puede configurar la enumeración basada en el acceso. Eche un vistazo al siguiente webcast:

Webcast de TechNet: Serie de administración de Windows Server 2003 (Parte 4 de 12): Administración de grupos (Nivel 200)

La enumeración basada en el acceso puede hacer la vida más fácil también ver:

Enumeración basada en acceso

ABE puede ayudarlo a reducir la cantidad de acciones diferentes que debe administrar.

Su enfoque es básicamente la forma en que lo abordaría.
Las únicas cosas que agregaría son estas:

1) Agregaría a su esquema de "roles" al evaluar lo que necesitan a través de los servidores, no solo en un servidor con el que probablemente se encontrará atípico, pero mi teoría con ellos es que cuando se encuentre con ellos, cree otro grupo. En mi experiencia, donde hay un caso atípico, hay muchos.

2) Revaluaría FUERTEMENTE la necesidad de grupos universales para todo, ya que tomaría un éxito de replicación con ellos ya que los miembros y grupos dentro del grupo Universal se replican en los servidores del Catálogo global, mientras que con el dominio local y global solo el grupo es replicado a los servidores del catálogo global. Entonces, si realiza un cambio en un grupo universal, inicia una replicación, mientras que con global y dominio local no lo hace.

Su método de usar el grupo de recursos para cada nivel de acceso es correcto. Lo único que consideraría es usar Grupos locales de dominio para obtener recursos. No necesariamente necesita usar Grupos universales si está creando grupos de recursos específicos del servidor.

La desventaja de usar Grupos locales de dominio para recursos es que terminas con más grupos totales. Lo bueno es que tiene menos problemas con la replicación, como señaló Zypher.

El enfoque propuesto parece bastante sólido. Sin embargo, hay que tener en cuenta la forma en que configuró inicialmente los archivos compartidos. La práctica recomendada es tener un recurso compartido de nivel superior único, que contenga subcarpetas a las que luego se asignan los permisos de grupo. NTFS puede omitir la "Carpeta transversal / Ejecutar archivo" en la carpeta de nivel superior y otorgar acceso a la subcarpeta.

La estructura entonces se vería como \ servername \ sharename \ group-folder, con permisos compartidos que solo deben establecerse en la carpeta "sharename", y los permisos NTFS reales establecidos en la carpeta "group-folder".

Su servidor de archivos también podrá funcionar mejor con este tipo de configuración.

Otras cosas generales que haría es tener una convención de nomenclatura para los grupos, de modo que el nombre del grupo sea el mismo que el nombre de la carpeta del grupo (con FC / RW / RO agregado si lo desea), y pegue el UNC a la carpeta en la descripción del grupo (para que su secuencia de comandos de inicio de sesión pueda leerlo de nuevo y establecer una asignación de unidad de esa manera, y también para que pueda ver más fácilmente qué carpetas compartidas se aplican a qué grupos).

La práctica estándar que he estado usando para el servidor de archivos de Windows desde Windows 2000 (presentada en la serie Mastering de Windows Server de Mark Minasi, así que busque más información) es usar grupos que sean locales en el servidor de archivos para anidar.

Por ejemplo, considere un servidor de archivos llamado KERMIT en un dominio llamado MUPPETS.

Digamos que KERMIT tiene algunos archivos compartidos:

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

Cree grupos locales a KERMIT para acceder y otorgue permisos en el sistema de archivos exactamente como lo haya especificado (es decir, un grupo por nivel de acceso por recurso compartido)

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

Debido a que estos son grupos locales, puede poner cualquier otro grupo o usuario que desee en ellos: grupos locales de dominio, grupos globales, grupos universales, cuentas de usuario de cualquier dominio en su bosque. La administración de derechos ahora es local para los grupos del servidor de archivos en lugar del sistema de archivos o el AD.

Esto agrega una capa adicional a la administración de sus grupos, pero tiene la ventaja de permitir (por ejemplo) que los administradores locales del sitio administren sus propios servidores de archivos sin necesitar nada más que derechos de administrador para ese servidor de archivos. Si tiene una estructura de sucursal federada, donde cada tipo de oficina hace lo suyo con sus servidores, esto puede ser un beneficio real. Es posible que no desee otorgar derechos de administrador de AD a unas pocas docenas de administradores de sitios locales.

También evita que su AD se desordene con muchos grupos (un grupo por nivel de acceso por recurso compartido por servidor puede acumularse muy rápidamente) y minimiza la replicación de grupo entre GC. Le permite reservar sus grupos de AD para roles en lugar de permisos.

Si su entorno está rigurosamente estandarizado y todos los servidores de archivos son idénticos y replicados, entonces esta es obviamente una capa más de grupos que no necesita. Además, si sabe que necesita un grupo de AD en particular para tener los mismos derechos sobre un recurso compartido que existe en cada servidor de archivos, necesitará algo de automatización para mantenerlo.

En pocas palabras, cuanto más diferentes sean sus servidores de archivos entre sí, más sentido tendrá el uso de grupos locales de máquinas. Cuanto más similares sean, más querrás usar el sistema que estás usando actualmente.

Estoy viendo una migración de NetWare a Windows Server 2008, así que esto ha estado en mi mente mucho últimamente. Server 2008 (y hasta cierto punto Server 2003R2) tiene algunas características muy buenas que realmente facilitan esta transición. Server 2008 viene con una enumeración basada en acceso lista para usar. Esta es una característica muy agradable que permite a los usuarios ver solo los directorios en los que tienen derechos. Si tienes una acción como ...

\\ user-home-srv \ homes \

Sin ABE, el usuario final vería decenas / cientos / miles de directorios. Con ABE, el usuario final vería solo uno. Lo mismo se aplica a las acciones compartidas. Con ABE puede tener un gran volumen único para todos sus directorios departamentales si lo desea, y no enviar correo basura a sus usuarios con directorios a los que no pueden acceder. Si bien no es un problema de ACL, está algo relacionado, así que lo menciono.

Otra cosa que Server 2008 parece hacer mejor que sus versiones anteriores es la herencia de ACL. Simplemente parece más rápido al propagarse a la hoja un cambio de ACL en la parte superior de un árbol grande.

Debido a nuestro legado de Netware, tenemos una gran cantidad de grupos que se nombran en función de quién está en ellos, y algunos de ellos se nombran por lo que dan acceso. Para los directorios que tienen acceso reglamentado, también utilizamos la nomenclatura "RO" "Completa".

Tenemos un volumen monolítico "compartido" (todavía en NetWare, pero planeamos tenerlo monolítico cuando nos mudemos a Windows) que es el volumen compartido único para todos los 4.400 trabajadores, y tiene más de 3.5 millones de archivos. Los directorios de nivel superior son todos los nombres de departamento, y cada departamento regula lo que sucede dentro de ellos. Hay algunas excepciones para los departamentos realmente grandes, que tienen un segundo nivel de directorios con ACL.

En mi último trabajo, incluso pudimos configurar permisos para que los empleados de RR. HH. Que solicitaran trabajo no pudieran ver sus propios datos de aplicación en su servidor. Se necesitaron algunos filtros de derechos de herencia para hacerlo, que es similar a la etiqueta "bloquear herencia" en Windows. La parte difícil allí era documentarlo todo, pero funcionó .

El mejor de los casos es tener cada usuario agregado a un solo grupo de seguridad para el rol de trabajo del usuario. El rol es el acceso delegado donde sea necesario.

Igualmente, una carpeta compartida debe tener acceso usando grupos de seguridad de "recursos", como su ejemplo "FILE01-Test Results-RW". Esto contendrá los roles de trabajo, roles de departamento u otros grupos aplicables.

La ventaja de este diseño es que delega el acceso por grupo (equipo, departamento, etc.), y no acceso único que puede ser difícil de rastrear. Cuando un usuario se transfiere a otro departamento, debe limpiar todo el acceso anterior.

La desventaja es que los grupos pueden ser mal utilizados. Haga distinciones claras sobre para qué se usan los grupos, de modo que los grupos de recursos asignados a un recurso compartido no se reutilicen como si fueran grupos departamentales, creando un enredo de acceso enredado.