asp.net permissions iis-7.5 windows-server-2008-r2

asp.net - IIS AppPoolIdentity y permisos de acceso de escritura del sistema de archivos



permissions iis-7.5 (3)

  1. Haga clic derecho en la carpeta.

  2. Haga clic en Propiedades

  3. Haga clic en la pestaña de seguridad. Verás algo como esto:

  1. Haga clic en el botón "Editar ..." en la pantalla superior. Verás algo como esto:

  1. Haga clic en el botón "Agregar ..." en la pantalla superior. Verás algo como esto:

  1. Haga clic en el botón "Ubicaciones ..." en la pantalla superior. Verás algo como esto. Ahora, vaya al extremo superior de esta estructura de árbol y seleccione el nombre de su computadora, luego haga clic en Aceptar.

  1. Ahora escriba "iis apppool / your_apppool_name" y haga clic en el botón "Comprobar nombres". Si el conjunto de aplicaciones existe, verá el nombre de su conjunto de aplicaciones en el cuadro de texto con el subrayado. Haga clic en el botón Aceptar.

  1. Marque / desmarque cualquier acceso que necesite para otorgar a la cuenta

  2. Haga clic en el botón Aplicar y luego en Aceptar.

Aquí hay un problema con IIS 7.5 y ASP.NET con el que he estado investigando y sin llegar a ninguna parte. Cualquier ayuda sería muy apreciada.

Mi pregunta es: al utilizar ASP.NET en IIS 7.5, ¿cómo IIS y / o el sistema operativo permiten que la aplicación web escriba en una carpeta como C:/dump cuando se ejecuta con plena confianza? ¿Cómo es que no tengo que agregar explícitamente el acceso de escritura para el usuario del grupo de aplicaciones (en este caso, ApplicationPoolIdentity )?

Esto lo sé mucho:

  • En IIS 7.5, la identidad predeterminada para un grupo de aplicaciones es ApplicationPoolIdentity .
  • ApplicationPoolIdentity representa una cuenta de usuario de Windows llamada "IIS APPPOOL / AppPoolName", que se crea cuando se crea el Grupo de aplicaciones, donde AppPoolName es el nombre del Grupo de aplicaciones.
  • El usuario "IIS APPPOOL / AppPoolName" es de manera predeterminada un miembro del grupo IIS_IUSRS .
  • Si está ejecutando bajo Full Trust, su aplicación web puede escribir en muchas áreas del sistema de archivos (excluyendo carpetas como C:/Users , C:/Windows , etc.). Por ejemplo, su aplicación tendrá acceso para escribir en algunas carpetas, como C:/dump .
  • De forma predeterminada, al grupo IIS_IUSRS no se le otorga acceso de lectura o escritura a C:/dump (al menos no se puede acceder a él a través de la pestaña "Seguridad" en el Explorador de Windows).
  • Si niega el acceso de escritura a IIS_IUSRS , obtendrá una IIS_IUSRS seguridad cuando intente escribir en la carpeta (como se esperaba).

Entonces, teniendo todo esto en cuenta, ¿cómo se otorga el acceso de escritura al usuario "IIS APPPOOL / AppPoolName"? El proceso w3wp.exe se ejecuta como este usuario, entonces, ¿qué le permite a este usuario escribir en una carpeta a la que parece no tener acceso explícito?

Tenga en cuenta que entiendo que esto se hizo probablemente por conveniencia, ya que sería una molestia otorgarle a un usuario acceso a todas las carpetas en las que debe escribir si está ejecutando bajo Full Trust. Si desea limitar este acceso, siempre puede ejecutar la aplicación en Medium Trust. Estoy interesado en conocer la forma en que el sistema operativo y / o IIS permiten que se realicen estas escrituras, a pesar de que no parece haber un acceso explícito al sistema de archivos.

A ApplicationPoolIdentity se le asigna la pertenencia al grupo de Users , así como al grupo IIS_IUSRS . A primera vista, esto puede parecer algo preocupante, sin embargo, el grupo de Users tiene derechos NTFS algo limitados.

Por ejemplo, si intenta crear una carpeta en la carpeta C:/Windows , verá que no puede. ApplicationPoolIdentity aún necesita poder leer archivos de las carpetas del sistema de Windows (de lo contrario, ¿de qué otra manera podría el proceso de trabajo cargar dinámicamente los archivos DLL esenciales)?

Con respecto a sus observaciones acerca de poder escribir en su carpeta c:/dump . Si echa un vistazo a los permisos en la Configuración de seguridad avanzada, verá lo siguiente:

Ver ese permiso especial que se hereda de c:/ :

Esa es la razón por la que ApplicationPoolIdentity su sitio puede leer y escribir en esa carpeta. Ese derecho se hereda de la unidad c:/ .

En un entorno compartido donde posiblemente tenga varios cientos de sitios, cada uno con su propio grupo de aplicaciones e Identidad de grupo de aplicaciones, almacenará las carpetas del sitio en una carpeta o volumen al que se haya eliminado el grupo de Users y los permisos establecidos de tal manera que solo los Administradores y La cuenta del SISTEMA tiene acceso (con herencia).

Luego, asignaría individualmente los permisos necesarios que cada IIS AppPool/[name] requiere en su carpeta raíz del sitio.

También debe asegurarse de que se elimine el grupo de Users todas las carpetas que cree donde almacena archivos o datos potencialmente confidenciales. También debe asegurarse de que las aplicaciones que instale no almacenen datos confidenciales en sus carpetas c:/program files/[app name] y que utilicen las carpetas de perfil de usuario en su lugar.

Así que sí, a primera vista, parece que ApplicationPoolIdentity tiene más derechos de los que debería, pero en realidad no tiene más derechos de los que dicta la pertenencia a un grupo.

La membresía de un grupo ApplicationPoolIdentity se puede examinar usando la herramienta SysInternals Process Explorer . Encuentre el proceso de trabajo que se está ejecutando con la Identidad de grupo de aplicaciones que le interesa (tendrá que agregar la columna User Name a la lista de columnas para mostrar:

Por ejemplo, tengo un grupo aquí llamado 900300 que tiene una Identidad de Grupo de Aplicaciones de IIS APPPOOL/900300 . Haciendo clic derecho en las propiedades del proceso y seleccionando la pestaña Seguridad vemos:

Como podemos ver, IIS APPPOOL/900300 es miembro del grupo de Users .

Cada grupo de aplicaciones en IIs crea su propia carpeta de usuario segura con el permiso COMPLETO de lectura / escritura de manera predeterminada en c: / usuarios. Abra su carpeta de Usuarios y vea qué carpetas de grupos de aplicaciones hay, haga clic con el botón derecho, y verifique sus derechos para la cuenta virtual del grupo de aplicaciones asignada. Debería ver su cuenta de grupo de aplicaciones ya agregada con acceso de lectura / escritura asignado a su raíz y subcarpetas.

De modo que el tipo de acceso al almacenamiento de archivos se realiza automáticamente y debería poder escribir lo que quiera allí en las carpetas de cuentas de usuario de los grupos de aplicaciones sin cambiar nada. Es por eso que se crearon cuentas de usuario virtuales para cada grupo de aplicaciones.