asp.net - Identidad de grupo de aplicaciones o suplantación
iis asmx (5)
La suplantación es útil cuando necesita una experiencia de usuario final común con otros servicios de Windows basados en la seguridad de Windows.
Por ejemplo, los servidores de Microsoft SharePoint utilizan la suplantación porque puede acceder a las bibliotecas de documentos de SharePoint con navegadores web y con la interfaz de usuario compartida de Windows estándar (conectarse / desconectarse a una red compartida, según el protocolo SMB ). Para garantizar que la seguridad sea coherente entre los dos, en este caso, necesita la suplantación.
Aparte de este tipo de escenario, la suplantación de identidad no suele ser útil (pero puede costar mucho en términos de escalabilidad)
(Se ha formulado una pregunta similar, pero tanto la pregunta como la respuesta aceptada no proporcionan el detalle que estoy buscando)
Con la intención de ejecutar un servicio web asmx bajo una cuenta de dominio dedicada, ¿cuáles son los escenarios de uso y / o las ventajas y desventajas de usar un grupo de aplicaciones con la identidad de la cuenta de dominio frente a la personificación?
Tenemos 3 pequeños servicios web internos que se ejecutan con una carga relativamente baja y nos gustaría que funcionen con sus propias cuentas de dominio (con el propósito de seguridad integrada con SQL Server, etc.). Parece que tengo la opción de crear grupos de aplicaciones dedicados para cada aplicación, o tener un solo grupo de aplicaciones para todas las aplicaciones y usar la suplantación en cada una.
Entiendo que los grupos de aplicaciones proporcionan aislamiento del proceso de trabajo y hay consideraciones de rendimiento al usar la suplantación de identidad, sin embargo, ¿qué otra cosa determinaría la opción correcta?
Le aconsejaría que consulte la siguiente página para obtener detalles de seguridad ...
https://www.attosol.com/sample-aspx-page-to-show-security-details-in-asp-net/
Una vez que haya terminado con esto, verá "precisamente" cómo la suplantación cambia la identidad.
Normalmente, elegirá una identidad diferente para el proceso de trabajo (o realizará la suplantación de ASP.NET) porque es necesario acceder a los recursos locales / de red que necesitan permisos específicos. Una desventaja obvia es que el código de su aplicación puede ejecutarse con más permisos de los que puede necesitar, lo que aumenta la vulnerabilidad frente a ataques maliciosos.
La suplantación de ASP.NET tendría más sobrecarga porque las necesidades del contexto del usuario se deben cambiar para cada solicitud. Le sugeriré que utilice un enfoque de grupo de aplicaciones por separado. La única desventaja con el enfoque de grupo de aplicaciones es que tiene un proceso para cada uno de ellos y por lo tanto habrá gastos generales (desde la perspectiva del sistema operativo) para cada proceso. Si sus aplicaciones son más pequeñas y no tienen una gran demanda de memoria, esto no debería ser un problema.
Si desea que sus servicios web se conecten a SQL a través de la autenticación de Windows, es casi seguro que desee configurar cada aplicación con la opción de grupo de aplicaciones dedicado. Esto requiere la menor cantidad de configuración y administración.
Si sigue la ruta de suplantación, deberá tener en cuenta el problema del "salto doble". Cuando un usuario llama a un servicio web que está utilizando la suplantación, el servicio web puede acceder a los recursos locales , como ese usuario. Sin embargo, si el servicio web intenta conectarse a un recurso no local (por ejemplo, una base de datos que se ejecuta en un servidor separado), el resultado será un error de autenticación. La razón es que NTLM evita que sus credenciales hagan más de un "salto". Para solucionar esto, necesitarías usar la delegación de Kerberos. La delegación no es difícil de configurar, pero requiere privilegios de administrador de dominio, lo que puede dificultar las cosas en algunos entornos corporativos.
Además, usar la suplantación significa que necesita administrar los permisos de la base de datos para cada usuario que pueda visitar su servicio web. La combinación de los roles de la base de datos y los grupos de AD contribuirá en gran medida a simplificar esto, pero es un paso administrativo adicional que tal vez no desee realizar. También es un posible riesgo de seguridad, ya que ciertos usuarios pueden terminar con privilegios que son mayores de lo que anticipan sus servicios web.
Aplicación pool pros:
No tienes que ser un programador de .Net para entender lo que está pasando.
El aspecto de seguridad abandona el dominio del programador y cae dentro del ámbito de la infraestructura.
Fácil de cambiar a través de IIS con controles de seguridad adecuados que el nombre de usuario es correcto al configurar el grupo de aplicaciones. Es decir, no te permitirá ingresar un nombre de usuario incorrecto.
Profesionales de la personificación:
- Los privilegios se pueden documentar y rastrear a través de cambios en la configuración a través del historial de control de origen si los archivos de configuración se almacenan allí.
Contras de la personificación:
- Para cambiar al usuario, debe estar familiarizado con la configuración de .Net en lugar de simplemente configurar un sitio web
No estoy seguro de que pueda pensar en otra cosa.
Mi instinto dice que vaya con diferentes grupos de aplicaciones para cada uno de los sitios web, pero es su fiesta.