Resumen: Este artículo presenta principalmente los tipos de modelos de seguridad para aplicaciones WEB ASP.NET, compara sus ventajas y desventajas y propone un mecanismo de selección.
Palabras clave: modelo de seguridad submodelo confiable submodelo de simulación/delegación Aplicación WEB ASP.NET
1.Prefacio
Las aplicaciones WEB ASP.NET generalmente pertenecen a una arquitectura multicapa. Generalmente, la estructura lógica se puede dividir en capa de presentación, capa de lógica empresarial y capa de acceso a datos. Para acceder a los recursos de la aplicación, la autenticación y autorización de identidad del cliente deben abarcar varias capas. nivel. Este artículo analiza principalmente el modelo de seguridad de acceso a recursos de las aplicaciones SP.NET
2. Identificación de acceso a recursos
Los recursos típicos proporcionados externamente por las aplicaciones WEB a los clientes incluyen:
Recursos del servidor web, como páginas web, servicios web y recursos estáticos (páginas e imágenes HTML).
Recursos de base de datos, como datos por usuario o datos a nivel de aplicación.
Recursos de red, como recursos del sistema de archivos remoto, etc.
Recursos del sistema, como el registro, registros de eventos y archivos de configuración, etc.
Los clientes acceden a estos recursos a través de capas de aplicaciones, con una identidad que fluye a través de cada capa. Esta identidad utilizada para el acceso a recursos consta de:
La identidad de la persona que llama original. La identidad de la persona que llama original se obtiene y posteriormente fluye a través de cada capa del sistema.
ID de proceso El acceso a recursos locales y las llamadas posteriores se realizan utilizando la ID de proceso actual. La viabilidad de este enfoque depende del límite que se debe cruzar, ya que el sistema objetivo debe reconocer la identidad del proceso. Esto debe llamarse de dos maneras:
Cruce dominios de seguridad de Windows dentro del mismo dominio de seguridad de Windows: utilice fideicomisos y cuentas de dominio, o utilice nombres de usuario y contraseñas duplicados cuando no exista una relación de confianza.
Cuenta de servicio Este enfoque utiliza una cuenta de servicio (fija). Por ejemplo, para el acceso a la base de datos, la cuenta de servicio podría estar representada por un nombre de usuario y una contraseña SQL fijos mediante un componente conectado a la base de datos.
Cuando se requiere una identidad de Windows fija, se debe utilizar la aplicación del servidor Enterprise Services.
Identidad personalizada Cuando no hay una cuenta de Windows disponible, puede usar Iprincipal e Iidentity para construir su propia identidad, que puede incluir detalles sobre el contexto de seguridad.
3. Modelo de acceso a recursos
3.1 Modelo de subsistema confiable
Como se muestra en la Figura 1, en este modelo, el contexto de seguridad de la persona que llama original no fluye a través del servicio en el nivel del sistema operativo, sino que se utiliza una identidad fija en la capa de servicio intermedia para acceder a servicios y recursos posteriores. El modelo de subsistema confiable recibe su nombre del hecho de que un servicio descendente (quizás una base de datos) confía en un servicio ascendente para autorizar a sus llamantes. En el ejemplo de la Figura 1, la base de datos confía en la autorización de la persona que llama por parte de la capa intermedia y solo permite que las personas autorizadas accedan a la base de datos utilizando identidades confiables.
3.1.1 Modo de acceso a recursos
En el modelo de subsistema confiable, el modelo de acceso a recursos es el siguiente:
Autenticar usuarios Asignar usuarios a roles Autorizar según la membresía del rol Usar una identidad confiable fija para acceder a recursos posteriores
3.1.2 Identificación fija
Una identidad fija que se utiliza para acceder a sistemas posteriores y administradores de recursos, que se puede proporcionar mediante una identidad de proceso o una cuenta de servicio de cuenta de Windows preestablecida. Para SQL Server Explorer, esto significa autenticación de Windows en SQL Server.
Cuando se utiliza la identidad del proceso, normalmente se utiliza la identidad del proceso ASP.NET (el valor predeterminado es la cuenta ASPNET). En aplicaciones prácticas, a menudo es necesario cambiar la cuenta ASPNET a una contraseña más segura y crear una cuenta de Windows en la computadora con SQL Server que coincida con la cuenta del proceso ASP.NET. El método específico es el siguiente:
Edite el archivo Machine.config ubicado en el directorio %windr%Microsoft.NETFrameworkv1.1.4322CONFIG y reconfigure el atributo de contraseña en el elemento <processModel> a su valor predeterminado <!-UserName="machine" contraseña = "AutoGenerate" -->Cambie a <!-UserName="machine" contraseña="NewPassword" --> o use la herramienta ASPNET_setreg.exe para guardar el nombre de usuario y la contraseña en el registro y cambie la configuración a: < !- enable="true" Nombre de usuario="Registro:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,nombre de usuario" contraseña=" Registro:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,contraseña " -->
Otras aplicaciones utilizan una cuenta SQL designada (especificada por el nombre de usuario y la contraseña en la cadena de conexión) para acceder a SQL Server. En este caso, la base de datos debe estar configurada para la autenticación SQL. La cadena de conexión guardada en el archivo de configuración debe estar protegida mediante cifrado.
3.2 Modelo de simulación/delegación
Como se muestra en la Figura 2, cuando se utiliza el modelo de suplantación/eliminación, un servicio o componente (normalmente ubicado en la capa de servicios empresariales lógicos) utiliza capacidades de suplantación del sistema operativo para suplantar la identidad del cliente antes de acceder al siguiente servicio descendente. Si el servicio está en la misma máquina, usar la suplantación es suficiente; si el servicio descendente está en una máquina remota, también necesita usar la delegación; el contexto de seguridad del acceso a los recursos descendentes es el contexto del cliente.
3.3 Seleccionar modelo de acceso a recursos
La comparación de los dos modelos de acceso a recursos se muestra en la Tabla 1.
El backend de la función de simulación de modelo de subsistema confiable/auditoría de modelo delegada confía en los servicios de la capa superior. Si la capa intermedia se ve comprometida, los recursos de back-end son vulnerables a los ataques. El servicio de back-end puede autenticar y autorizar a cada persona que llama con buena seguridad.
La escalabilidad admite la agrupación de conexiones y tiene buena escalabilidad. No admite la agrupación de conexiones y tiene poca escalabilidad.
Administración de ACL de back-end La ACL está configurada para una sola entidad, lo que requiere menos trabajo de administración. A cada usuario se le debe otorgar el nivel de acceso correspondiente. Cuando aumenta la cantidad de recursos y usuarios de back-end, el trabajo de administración se vuelve engorroso.
No es necesario delegar cuestiones técnicas. Se requiere delegación. La mayoría de los proveedores de servicios de seguridad no admiten la delegación.
El modelo de subsistema confiable se utiliza en la mayoría de las aplicaciones de Internet, así como en aplicaciones de intranet grandes, principalmente porque este modelo puede soportar bien la escalabilidad. El modelo de simulación/delegado tiende a usarse en sistemas más pequeños. Para estas aplicaciones, la escalabilidad no es la consideración principal; la consideración principal es la auditoría.