IIS: Usar Administradores como Identidad del Application Pool
Este es un escenario que he con mucha frecuencia. Si nuestra aplicación está dando problemas de permisos o de accesos, podemos cambiar la identidad del Application Pool (en este artículo tenéis más información sobre las identidades del Application Pool) usando un usuario que sea administrador. Primero, debemos entender cómo funcionan los permisos dentro de una aplicación en el IIS.
En primer lugar tenemos el usuario que se autentica en el IIS, que dependerá del mecanismo de autenticación que hayamos configurado para nuestra aplicación, por otro lado tenemos el usuario que ejecuta el proceso, que sería la Identidad del Application Pool y por último tenemos el usuario que ejecuta los hilos de .NET, que por defecto será la identidad del Application Pool a no ser que realicemos algún tipo de impersonación.
Si por ejemplo, tenemos una aplicación ASP.NET para administrar el IIS, necesitaremos que el usuario sea administrador de la máquina local, por lo que el mecanismo que comentábamos antes parece apropiado. Cambiamos la Identidad para que sea administrador de la máquina y así solventamos el posible error de permisos. Pero si leemos lo que dice este artículo podemos ver que es un riesgo de seguridad:
"For example, you can specify the Local System user account, which has higher-level user rights than either the Network Service or Local Service built-in user accounts. However, remember that running an application pool under an account that has high-level user rights is a serious security risk. "
Recordemos que el usuario que ejecuta por defecto los hilos de la aplicación es la identidad del Application Pool, lo que hace que quién realice las acciones sea un administrador. Ahora pensemos en que un usuario malicioso pueda añadir código, sería el administrador el que realizaría las acciones, lo que haría que pudiese realizar cualquier tipo de acción en ese proceso, incluso adueñarse de los demás procesos de la máquina. Y estando esta máquina en dominio, podríamos llegar a una vulnerabilidad muy grave.
La recomendación es la de no tener nunca un usuario administrador como Identidad del Application Pool. Únicamente los privilegios mínimos para realizar las acciones que necesitamos. Si seguimos el ejemplo de la aplicación para administrar el IIS, podemos tener un usuario "normal" como por ejemplo AppPoolIdentity e impersonar con el usuario autenticado en las acciones que requieran permisos especiales. Así sólo los administradores realizarían las acciones que requieran permisos especiales en el momento preciso.
Por otro lado, si estáis teniendo errores de permisos, lo que os recomendaría, es que usaseis alguna herramienta de monitorización de las acciones como Process Monitor para ver a qué recursos queremos acceder y con qué usuario lo estamos realizando.
Espero que os sirva de ayuda
-- José Ortega Gutiérrez