Internet Information Server ofrece desde hace muchos años un concepto llamado Grupo de Aplicaciones, que incluso más comúnmente se suele denominar con su nombre en inglés: "Application Pool".
Un Application Pool es una forma de aislar unas aplicaciones web de otras, confinándolas en su propio proceso y en sus propios límites de seguridad. Son tremendamente útiles ya que nos ayudan con la estabilidad general del sistema, la mejora de la seguridad y la salud de las propias aplicaciones entre otras muchas cosas.
Un mismo grupo de aplicaciones puede contener a varias aplicaciones a la vez, pero lo más habitual es que haya una relación uno a uno entre aplicaciones y grupos de aplicaciones, es decir, uno por cada aplicación.
De este modo para cada grupo de aplicaciones podemos establecer multitud de parámetros, por ejemplo (hay todavía más):
- La identidad bajo la que se ejecuta el proceso de nuestra aplicación (súper-importante y de lo que amos a hablar enseguida).
- Las acciones a llevar a cabo en caso de que se superen ciertos límites de uso de CPU o memoria, de modo que no tengamos aplicaciones acaparadoras que, debido a fugan memoria o consumen muchos recursos, puedan afectar a las demás.
- Si debemos ejecutar el proceso en un único procesador para sacarle partido a la caché, o en varios (afinidad de procesador).
- El tiempo máximo de inactividad antes de descartar un proceso y así liberar recursos de una aplicación que no se usa de modo que queden libres para el resto.
- El número máximo de peticiones que se pueden encolar antes de devolver estatus 503 de servicio no disponible.
- Bajo qué condiciones se debe reciclar el proceso para librar recursos (cada x tiempo, al cabo de x peticiones, si se producen fallos, etc...)
- Si se permite ejecutar aplicaciones de 32 bits en sistemas operativos de 64bits.
- La versión de .NET que ejecuta el proceso
- El modo de integración de la pila de peticiones (integrada o clásica)
Además aislamos a las aplicaciones entre sí, evitando que los problemas de estabilidad o de seguridad de una puedan afectar a las demás. Son útiles para todos, pero para empresas que albergan aplicaciones para otras empresas son una bendición del cielo.
Puedes encontrar los grupos de aplicaciones en el primer nodo del administrador de IIS, como puedes ver en la figura siguiente:
Uno de los parámetros más importantes y quizá más incomprendidos de los grupos de aplicaciones es su identidad.
En Windows todos los procesos de usuario del sistema (es decir, los que no forman parte del núcleo de bajo nivel del mismo, como los controladores y otros componentes similares) se deben ejecutar siempre bajo los auspicios de una determinada cuenta de usuario. Si abres el administrador de tareas de tu equipo (CTRL+MAYUSCULAS+ESC) en la pestaña "Procesos" verás que todos los procesos que aparecen se ejecutan bajo una determinada cuenta de usuario. Eso quiere decir que cada proceso tendrá en el sistema los mismos permisos que tendría dicho usuario a la hora de acceder a cualquier recurso: archivos en disco, ramas del registro, recursos de red, etc...
Esto reviste una importancia enorme, puesto que determina qué podrá y qué no podrá hacer el proceso en el sistema, y por lo tanto si un proceso malicioso tendrá acceso a lo que no debe y nos podrá robar información o instalar un troyano, por ejemplo.
En el caso de las aplicaciones web que se ejecutan bajo IIS, la identidad de cada grupo de aplicaciones se refiere al usuario que se va a utilizar para ejecutar el proceso de dicha aplicación. Por lo tanto, si por ejemplo ejecutamos una aplicación web bajo la identidad de un administrador del sistema, su proceso tendría las mismas atribuciones de seguridad que éste. Esto significa que si tiene un error y por ejemplo un atacante consigue escribir archivos a disco, tendrá permisos para hacerlo donde quiera, y es un enorme peligro de seguridad.
JAMÁS ejecutes una aplicación web con permisos de administrador o de un usuario con privilegios elevados. No es necesario y además es una irresponsabilidad.
Las diferentes identidades de procesos en IIS
En Internet Information Server 6.0 y 7.0 (es decir, en Windows Server 2003 y Windows Server 2008), por defecto los grupos de aplicaciones se ejecutaban bajo la identidad "Servicio de red" (o Network Service). Esta identidad había nacido precisamente para disponer de un usuario del sistema con permisos recortados pero suficientes para ejecutar aplicaciones web y que además tuviera permisos para acceder a recursos de red si fuese necesario. Además es una cuenta que no necesita contraseña, lo que facilita sobremanera su utilización para estos menesteres.
El mayor problema de usar la identidad del servicio de red era que, dado que si no lo cambiamos todos los grupos de aplicaciones se ejecutan bajo la misma cuenta, es posible que cierto código malicioso pudiese interferir entre procesos usando las mismas credenciales.
Lo ideal sería que cada grupo de aplicaciones/proceso se ejecutase bajo su propia cuenta. Pero esto supone un problema desde el punto de vista de gestión ya que hacerlo manualmente implicaría crear una nueva cuenta de usuario en el sistema para cada aplicación, con su correspondiente clave, confiar en que el que la crea le otorgue los permisos y atribuciones apropiados y se la asigne al grupo correspondiente. Una locura.
Por suerte Windows ofrece una característica muy interesante denominada "Cuentas virtuales". Las cuentas virtuales tampoco necesitan contraseña y además pueden acceder a la red como "Network Service", pero además se pueden administrar programáticamente.
IIS 7.5 y ISS 8.0 ( es decir, a día de hoy el que viene con Windows Server 2008 Service Pack 2, Windows Server 2008 R2 o con Windows Server 2012) asignan por defecto una identidad de cuenta virtual a sus grupos de aplicaciones, haciendo que cada uno de ellos se ejecute en una cuenta diferente y estén totalmente aislados.
Si abres el gestor de IIS y vas a las propiedades avanzadas de un grupo de aplicaciones (usando el menú de la derecha) verás que dispone de una propiedad "Identidad":
Por defecto tiene el valor "ApplicationPoolIdentity" como vemos en la figura anterior, aunque puede tomar otros valores:
Podemos establecerla como el clásico servicio de red o como un servicio local, la cuenta del sistema o una cuenta concreta con clave que tengamos creada en el equipo (opción de debajo, tapada por la lista desplegable). Ninguna de ellas necesita clave, por eso lo único que tenemos que hacer es seleccionarlas en la lista.
OJO: En general jamás deberías tener que establecer la identidad de un grupo de aplicaciones como servicio local o sistema. Si lo haces seguro que se te solucionan muchos problemas de acceso a recursos, pero estás condenando a tu servidor a que tarde o temprano alguien logre romper la seguridad. Son cuentas muy poderosas que no deberías usar salvo en casos extremos, y con esa intención se ofrecen en este diálogo. Lo dicho: escapa de ellas como de la peste.
Este valor por defecto por regla general no debiéramos tocarlo. Lo que está indicando es que para ejecutar el proceso de nuestra aplicación se va a utilizar una cuenta virtual específica para este grupo de usuarios. Esta cuenta tendrá el mismo nombre que el grupo de aplicaciones.
Por ejemplo, esta es una captura de los procesos que se están ejecutando en el servidor web que utilizo para albergar este blog:
Como vemos mis dos blog se ejecutan en su propio proceso de IIS (w3wp.exe, o sea WWW Worker Process) y el usuario bajo el que se ejecutan se llama igual que el grupo de aplicaciones correspondiente a cada uno. Es decir, están perfectamente aislados entre sí y de los demás procesos que hay en la máquina. Además controlo perfectamente en cada uno de ellos los límites de CPU y memoria, cada cuánto deben reciclarse, si deben cerrarse en caso de que no haya peticiones después de cierto tiempo, y muchos otros parámetros. Una gran ventaja.
Permisos en el sistema de archivos
Bien. Lo más habitual es que necesitemos otorgar permisos a los procesos de IIS para que puedan ejecutar código (asp, php, etc...), leer ciertos archivos de disco (imágenes, scripts, código..) y escribir otros. Esta segunda capa de permisos, que no tiene nada que ver con los permisos que se otorgan en el propio IIS, son tremendamente importantes porque determinan qué puede hacer nuestra aplicación en el almacenamiento del servidor. Debemos tenerlos muy controlados y no otorgar ni un solo permiso más de lo necesario o podríamos tener muchos problemas de seguridad.
Para ello usaremos la interfaz gráfica del explorador de archivos. Supongamos que debemos otorgar permisos a nuestra aplicación para que pueda leer y escribir determinada carpeta en la que se almacenan las imágenes que publicamos para el blog, por ejemplo.
Vamos hasta esa carpeta en el administrador de archivos, pulsamos con el botón derecho sobre la misma y en su pestaña de propiedades de seguridad podemos verificar la seguridad actual y también modificarla:
Para conceder acceso de lectura y escritura al usuario de nuestra aplicación pulsaremos el botón "Add" (Añadir) del diálogo de permisos. Éste nos abrirá una nueva ventana en la que intentaremos escribir el nombre del pool de aplicaciones, algo así:
Como podemos comprobar, pongamos como pongamos el nombre (suelto, con el nombre de la máquina o el dominio delante...) no se encuentra. De hecho si intentamos localizarlo visualmente sacando una lista de usuarios de la máquina veremos que no aparece por ningún lado. WTF?
Como he dicho antes, este tipo de usuarios son virtuales. Esto quiere decir que en realidad no existen en el sistema como un usuario normal, sino que los crea la aplicación bajo demanda, como de hecho hace Internet Information Server.
Entonces ¿cómo los añadimos a las propiedades de seguridad de nuestra carpeta?
Muy sencillo, precediéndolos de un nombre de dominio virtual llamado "IIS AppPool". Es decir, debemos escribir lo siguiente como nombre de usuario: IIS AppPool\NombreAppPool. O sea, en nuestro ejemplo IIS AppPool\JASoft.org:
Ahora sí que se reconoce y nos pone el nombre del grupo de aplicaciones, pudiendo marcar los permisos que sean necesarios, como con cualquier usuario normal:
¡Listo! Ahora ya tenemos a nuestro usuario virtual con los permisos apropiados en cada carpeta y archivo de la aplicación, pudiendo afinar tanto como queramos la seguridad del sistema de archivos. Lo mismo se haría con cualquier otro recurso como una carpeta compartida en red, el registro, etc.. Como ya he dicho los usuarios virtuales tienen acceso a la red también (como "Network Service") por lo que no tendremos problemas si algunos recursos están compartidos en otro servidor.
¡Espero que te sea útil!
💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor
