¿Cómo documentar / rastrear sus permisos?

Soy administrador de Windows, por lo que aquellos que se integran con Windows probablemente serán de gran ayuda. Mi principal desafío en este momento es solo con los archivos compartidos, pero a medida que aumenta el uso de SharePoint, esto solo lo hará más difícil.

Tengo todos mis directorios configurados y se permiten muchos grupos de seguridad que están configurados con la política de acceso mínimo necesario. Mi problema es rastrearlo todo por RR.HH. y razones de cumplimiento.

El usuario A necesita permiso para el recurso 1. Necesita obtener la aprobación del administrador del recurso 1 y luego el administrador de los administradores también debe aprobar este acceso. Una vez hecho todo eso, puedo hacer el cambio. En este punto, solo lo estamos rastreando en papel, pero es una carga y es probable que no cumpla cuando el usuario A es reasignado y ya no debería tener acceso al recurso 1, entre otros escenarios.

Sé que lo que estoy buscando ya debería existir, pero no sé dónde buscar y me estoy acercando a la comunidad.

EDITAR:

Gracias por las respuestas Creo que tocan el aspecto técnico y espero que mi pregunta no esté fuera de tema. Debería haberme aclarado mi objetivo. ¿Qué sistemas usa para mostrarle a un auditor que en la fecha X el usuario A tenía permiso agregado / eliminado y fue aprobado por el gerente Y? Actualmente tengo un sistema básico de venta de entradas, pero no lo veo entregando lo que necesito en un formato fácil de entender.
En mi opinión, estoy imaginando algo que tendría un informe sobre el usuario A que mostraría todos los cambios realizados en sus permisos. Idealmente, algo que se vincule a Active Directory sería ideal, pero en este punto espero encontrar algo más básico. Espero que haya una aplicación específica para esto.

¡Gracias!

Necesita un sistema de venta de entradas que proporcione 3 cosas:

1. Marca de tiempo de cuándo se cambiaron (agregaron o eliminaron) los permisos para un usuario en particular
2. ¿Por qué fueron cambiados?
3. Posibilidad de buscar estos cambios.

Casi todos los sistemas de tickets ya le brindan el número 1 en forma de una fecha de creación del ticket, una fecha de modificación, etc. El número 2 depende de usted para documentar el ticket. Por lo general, es un correo electrónico de aprobación del administrador de recursos pegado en el ticket que dice que pueden tener acceso (o que se debe eliminar el acceso) y de qué tipo. El n. ° 3 es el más importante y depende del sistema de emisión de boletos, pero si tiene un sistema que no es fácil de buscar, entonces su trabajo está hecho para usted. Si solo puede buscar por el usuario para que todos los tickets de permiso estén vinculados a su información de contacto en el sistema de tickets, entonces está bien, de lo contrario, esencialmente está documentando sus cambios en un agujero negro.

Fuera de un sistema de tickets que puede hacer esto para rastrear los cambios (usted menciona que tiene un sistema básico de tickets, por lo que tal vez necesite obtener uno mejor que permita una mejor capacidad de búsqueda / informes), cualquier aplicación, utilidad o script que use proporcionará solo una instantánea de los permisos. Todavía estás atrapado con el "¿por qué?" de quién tiene acceso a qué, que solo puede documentarse adecuadamente por separado de la aplicación, ya que es probable que deba capturar el correo electrónico original u otro texto de aprobación del administrador de recursos. Una vez que tenga eso, ¿dónde lo coloca para asociarlo con los resultados de la aplicación?

La ejecución de una aplicación o script para determinar los permisos actuales en una estructura de archivos tampoco le proporciona una buena pista de auditoría de cambios de permisos para un usuario. Esencialmente, está atrapado con una gran instantánea de los permisos actuales en un solo punto en el tiempo. Cuando lo ejecute nuevamente, tendrá otra gran instantánea de los permisos de archivo. Incluso si retuvo la primera captura de permisos y la comparó con la captura reciente, y los permisos han cambiado, ¿cómo relaciona eso con la razón del cambio? Una vez más, esto nos lleva de vuelta al sistema de venta de boletos, ya que los números 1, 2 y 3 anteriores se documentarán en un solo lugar.

Otro problema que mencionó es el arrastre de permisos (cuando un usuario es reasignado a otro permiso y ya no necesita acceso al recurso X, pero lo retiene de todos modos, porque el hecho de que ya no necesita acceso al recurso X no fue ejecutado por TI Departamento durante la transición). La ÚNICA forma de controlar esto es decirle a RR.HH. o al responsable de las reasignaciones de empleados que TI debe ser notificado cuando un empleado es reasignado para que pueda asignar y revocar los permisos de manera adecuada. Eso es. No existe una aplicación mágica que le diga que un usuario tiene acceso al recurso X, pero que ya no debería hacerlo porque su trabajo ahora es Y. De alguna forma, se debe enviar una notificación humana a TI cuando esto sucede.

Si ya tiene un sistema de venta de entradas, le sugiero que cree un nuevo grupo o etiqueta, etc. en su aplicación para este tipo de solicitudes y haga que los usuarios envíen entradas para cambios de permisos. Si su sistema de tickets le permite reenviar tickets a otros usuarios, o agregarlos al ticket, agregue los gerentes requeridos y solicite la verificación. Esto le permitiría mantener un registro para cubrir su trabajo.

Como se mencionó anteriormente, cree un grupo de seguridad para cada recurso compartido. En mi entorno, tendríamos acciones denominadas FIN_Yearly, GEN_Public, MGM_Reports (cada departamento tiene su propio acrónimo). Los grupos de seguridad se denominarían SG_FIN_YearlyAdmin, SG_FIN_YearlyUser, SG_GEN_PublicAdmin, etc. El usuario es de solo lectura, el administrador es de lectura / escritura.

Desde aquí puede crear, por ejemplo, SG_FinancialsManager; grupos de seguridad que incluyen otros grupos de seguridad para simplificar el acceso en función de los trabajos que realizan. Personalmente, no hacemos esto, ya que enturbia un poco el seguimiento. En lugar de verificar el SG de un recurso compartido y ver un montón de SG con permisos, tenemos una lista de usuarios. Preferencia personal, realmente, y dependerá del tamaño de su sitio. Usualmente usamos plantillas de usuario para administrar nuevos usuarios a puestos específicos.

Si su sistema de venta de entradas le permite buscar entradas anteriores, ya ha terminado. Si alguien le solicita que elimine los permisos de un usuario, puede rastrearlo. Si un usuario pregunta por qué ya no tiene acceso, puede proporcionarle el ticket. Si un administrador le pregunta quién tiene acceso a qué, imprima en pantalla el grupo de seguridad solicitado.

En realidad, hay varias aplicaciones comerciales para hacer esto. El área a veces se denomina "Gobierno de datos".

Un par de ejemplos:

Varonis Data Governance Suite
http://www.varonis.com/products/data-governance-suite/index.html

Quest One Identity Manager - Data Governance Edition
http://www.quest.com/identity-manager-data-governance

No uso estos, pero después de investigar el tema y ver algunas demostraciones, el alcance de lo que se puede requerir explicaría el mercado. Estas aplicaciones son muy complejas y no son baratas. Algunos de ellos tienen métodos muy sofisticados para conectarse a plataformas de almacenamiento para rastrear listas de control de acceso. Incluso si no está en su presupuesto, las demostraciones pueden ser útiles para tener una idea de lo que hace una aplicación como esta desde una perspectiva funcional.

Una observación que tuve al revisar esto es que generalmente no auditan a nivel de archivo. Si lo hicieran, no habría forma de que se ampliara a cientos de millones o miles de millones de documentos. Por lo tanto, generalmente solo realizan un seguimiento de los permisos a nivel de directorio.

No sé cómo documentarlos / rastrearlos , pero los asigno con grupos.

El usuario A necesita acceso al recurso # 1. Obtienen permiso y los agrego al grupo de acceso.
Continúan con sus asuntos hasta que un día son reasignados / despedidos / lo que sea, en ese momento los elimino del grupo de acceso.

Los registros de auditoría de modificación de mi cuenta me dicen cuándo obtuvieron / perdieron acceso, por lo que hay un registro de eso, y los grupos de acceso a recursos son típicamente grupos departamentales (recursos humanos, TI, ventas, finanzas, etc.), por lo que administrar las reasignaciones generalmente significa cambiar su grupo membresía de todos modos.

Esto tiende a funcionar mejor en entornos más pequeños: para entornos más grandes o en los que las ACL se vuelven realmente complejas, Zoredache hace un buen punto acerca de hacer que el sistema que realiza el ajuste de ACL también documente en cierta medida

Para iniciar la solicitud de agregar / eliminar acceso, reasignar usuarios, etc., sugeriría papel electrónico (un sistema de venta de entradas): esto garantiza que los usuarios no se escapen de las grietas, pero requiere la aceptación general de la empresa para usar el sistema electrónico religiosamente .
La ventaja sobre el papel es que obtienes algo que puedes buscar, y todos pueden hacer su parte del proceso desde su escritorio (los gerentes pueden aprobar más rápidamente ya que no hay un sobre de correo entre oficinas moviéndose, TI puede otorgar / revocar el acceso tan pronto como el boleto aparece en el contenedor de alguien, etc.)

La mejor manera que encuentro para hacer una configuración de permisos es basada en roles.

GG_HR GG_Finance Etc, generalmente asignado a la posición o unidad de negocios.

Desde allí, crea grupos locales que tienen permiso sobre el recurso, es decir, la impresora o el directorio de Finanzas. LG_RoomXPrinter LG_Finance_Read LG_Finance_FullControl

Usted crea Grupos Globales para estos grupos Locales LG-> GG, luego en sus Grupos Globales basados ​​en roles agrega los grupos Globales basados ​​en permisos.

GG_Finance <- LG_Finance_FullControl, LG_RoomXPrinter

Hace que sea más fácil cuando las personas asumen un rol, solo agrega su cuenta a un grupo y sus permisos fluyen de ese rol y es mucho más fácil de rastrear. (También es excelente si usa algún tipo de Sistema de gestión de identidad). Mucho más fácil que rastrear quién tiene qué permisos individuales, usted sabe que si están en el grupo de Recursos Humanos tienen permisos X.

Simplemente puede rastrear el movimiento de su grupo cuando se solicitan a través de su sistema de gestión de trabajo o ejecutar scripts para escupir quién está en qué grupos basados ​​en roles.

Dos excelentes utilidades:

1. AccessEnum: http://technet.microsoft.com/en-us/sysinternals/bb897332
2. AccessChk: http://technet.microsoft.com/en-us/sysinternals/bb664922

AccessEnum también le permite guardar sus resultados y luego compararlos en el futuro, lo que será útil para buscar cambios.

Realmente debería considerar habilitar la auditoría de los cambios de permisos de archivos / carpetas y luego recopilar registros de seguridad del servidor de archivos (manualmente o usando cualquier herramienta de administración de registro de eventos o SIEM, como Splunk) y usarlo para su documentación. Analice todos los cambios en las DACL de archivo. Además, complementa esto con AccessEnum y AccessChk como se sugirió anteriormente.

Y esto no lo libera de configurar permisos de seguridad adecuados y asignarlos solo a través de grupos.