Cómo: Conectarse a SQL Server mediante la autenticación de Windows en ASP.NET 2.0

Julio de 2005

Publicado: 21 de Diciembre de 2005

patterns & practices Developer Center (en inglés)

J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley
Microsoft Corporation

Este artículo se aplica a:
ASP.NET versión 2.0
Microsoft ® SQL® Server 2000
Sistema operativo Microsoft Windows Server® 2003

Resumen: En este artículo se describe cómo conectarse a SQL Server 2000 utilizando una cuenta de servicio de Windows desde ASP.NET versión 2.0. Siempre que sea posible, debe utilizar la autenticación de Windows en lugar de la autenticación de SQL, ya que de este modo evita que las credenciales se almacenen en las cadenas de conexión y que las contraseñas se transmitan a través de la red al servidor de base de datos. Además, debe cifrar la cadena de conexión para proteger los detalles de conexión del servidor, tales como el nombre y servidor de la base de datos. De forma predeterminada, ASP.NET no suplanta al autor de la llamada a la base de datos. En Windows Server 2003, puede utilizar la cuenta de servicio de red, que tiene credenciales de red (machine$), o configurar una identidad de grupo de aplicaciones. Si configura la suplantación para utilizar al autor original de la llamada, debe evaluar la escalabilidad de los grupos de conexión por usuario.

En esta página

Objetivos Objetivos
Descripción general Descripción general
Modelos de suplantación/delegación y de subsistema de confianza Modelos de suplantación/delegación y de subsistema de confianza
Resumen de los pasos Resumen de los pasos
Paso 1. Configuración de una cadena de conexión Paso 1. Configuración de una cadena de conexión
Paso 2. Cifrado de una cadena de conexión Paso 2. Cifrado de una cadena de conexión
Paso 3. Configuración de la seguridad de SQL Server Paso 3. Configuración de la seguridad de SQL Server
Paso 4. Prueba de acceso de seguridad Paso 4. Prueba de acceso de seguridad
Factores de implementación Factores de implementación
Factores de batería de servidores Web Factores de batería de servidores Web
Cuentas duplicadas Cuentas duplicadas
Suplantación/delegación frente a subsistema de confianza Suplantación/delegación frente a subsistema de confianza
Recursos adicionales Recursos adicionales
Comentarios Comentarios
Soporte técnico Soporte técnico
Comunidad y grupos de noticias Comunidad y grupos de noticias
Colaboradores y revisores Colaboradores y revisores

Objetivos

  • Elegir entre los modelos de subsistema de confianza y de suplantación/delegación.

  • Conectarse a SQL Server mediante la autenticación de Windows.

  • Autorizar la identidad de su aplicación Web en SQL Server.

  • Proteger la cadena de conexión a la base de datos.

  • Proteger la cadena de conexión a la base de datos en una batería de servidores Web.

Descripción general

Cuando utiliza la autenticación de Windows para conectarse a SQL Server, utiliza la identidad de proceso o de subproceso de la aplicación (si ésta utiliza la suplantación) para conectarse. Debe utilizar la autenticación de Windows para conectarse a SQL Server siempre que sea posible por los motivos siguientes:

  • Las credenciales no se transmiten a través de la red durante la autenticación y no es preciso incrustar nombres de usuario ni contraseñas en la cadena de conexión a la base de datos. Esto significa que los usuarios malintencionados e intrusos no podrán obtener las credenciales supervisando la red ni viendo las cadenas de conexión contenidas en los archivos de configuración.

  • Además, puede disfrutar de las ventajas de la administración de cuentas centralizada. Las cuentas de usuario están sujetas a las directivas normales de seguridad de administración de cuentas, como períodos de validez de contraseñas, longitudes mínimas y bloqueo de cuenta tras varios intentos de inicio de sesión fallidos.

Cuando utiliza la autenticación de Windows para conectarse a SQL Server, utiliza la autenticación Kerberos o NTLM, en función de la configuración de los servidores y el dominio. Es posible que no pueda utilizar la autenticación Kerberos si:

  • El cliente y servidor de base de datos están separados por un firewall que impide la autenticación Kerberos.

  • Los servidores de aplicaciones y base de datos se encuentran en dominios diferentes entre los que no hay confianza.

En ambas situaciones, puede utilizar cuentas locales duplicadas o autenticación SQL. En el caso de las cuentas locales duplicadas, se configuran dos cuentas en cada servidor con idénticos nombre de usuarios y contraseñas. Debe asegurarse de que las contraseñas son iguales.

Si utiliza la autenticación SQL, debe:

  • Administrar las credenciales usted mismo.

  • Proteger las credenciales contenidas en la cadena de conexión.

  • Posiblemente, proteger las credenciales transmitidas a través de la red desde el servidor Web a la base de datos.

Para obtener más información, consulte How To: Connect to SQL Server Using SQL Authentication in ASP.NET 2.0 (en inglés)

Modelos de suplantación/delegación y de subsistema de confianza

De forma predeterminada, las aplicaciones ASP.NET no llevan a cabo la suplantación. Como consecuencia, cuando utilizan la autenticación de Windows para conectarse a SQL Server, utilizan la identidad de proceso de la aplicación Web. De este modo, la aplicación Web cliente autentica y autoriza a los usuarios y, a continuación, utiliza una identidad de confianza para tener acceso a la base de datos. La base de datos confía en la identidad de la aplicación, así como en que ésta autenticará y autorizará correctamente a los autores de las llamadas. Este enfoque se denomina modelo de subsistema de confianza.

El modelo alternativo, denominado modelo de suplantación/delegación, utiliza la identidad de Windows del autor original de la llamada para tener acceso a la base de datos. Este enfoque requiere que la aplicación ASP.NET esté configurada para utilizar la suplantación. Consulte el apartado "Suplantación/delegación frente a subsistema de confianza" de este mismo artículo.

Resumen de los pasos

Para conectarse a SQL Server mediante la autenticación de Windows, siga los pasos descritos a continuación:

  • Paso 1. Configuración de una cadena de conexión.

  • Paso 2. Cifrado de una cadena de conexión.

  • Paso 3. Configuración de la seguridad de SQL Server.

  • Paso 4. Prueba de acceso de seguridad.

Paso 1. Configuración de una cadena de conexión

En el caso de las aplicaciones ASP.NET 2.0, debe almacenar las cadenas de conexión en la sección <connectionStrings> del archivo Web.config de la aplicación. La cadena de conexión utilizada con la autenticación de Windows debe incluir el atributo Trusted_Connection=Yes, o el atributo equivalente Integrated Security=SSPI, tal y como se muestra a continuación.

<connectionStrings>
  <add name="MyDbConn1" 
       connectionString="Server=MyServer;Database=MyDb;Trusted_Connection=Yes;"/>
  <add name="MyDbConn2" 
      connectionString="Initial Catalog=MyDb;Data Source=MyServer;Integrated Security=SSPI;"/>
</connectionStrings>

Estos dos atributos son equivalentes y el resultado de ambos es la autenticación de Windows para la base de datos.

Si utiliza expresiones de enlace de datos en sus páginas Web, utilice el calificador ConnectionStrings: en una expresión ASP.NET 2.0 para utilizar una cadena de conexión almacenada en el archivo Web.config de la aplicación tal y como se muestra a continuación.

<asp:SqlDataSource ID="SqlDataSource1" Runat="server" 
  ConnectionString="<%$ ConnectionStrings:MyDbConn1%>">
  ...
</asp:SqlDataSource>

Para tener acceso a una cadena de conexión en código, utilice ConfigurationManager.ConnectionStrings tal y como se muestra a continuación.

string connStr = ConfigurationManager.ConnectionStrings["MyDbConn1"].ToString();
SqlConnection conn = new SqlConnection(connStr);

Paso 2. Cifrado de una cadena de conexión

Aunque las cadenas de conexión a la base de datos para la autenticación de Windows no contienen nombres de usuario ni contraseñas, aún así debe cifrarlas en el archivo Web.config para reducir la posibilidad de revelar nombres de servidores y bases de datos. Para cifrarlas, utilice la utilidad Aspnet_regiis con el proveedor de configuración protegida de su elección, API de protección de datos (DPAPI) de Windows o RSA.

DataProtectionConfigurationProvider utiliza DPAPI y RSAProtectedConfigurationProvider utiliza el cifrado de claves públicas RSA. Utilice RSAProtectedConfigurationProvider si la aplicación está implementada en una batería de servidores Web, ya que en este caso es muy sencillo exportar las claves RSA.

El comando siguiente muestra cómo cifrar la sección <connectionStrings> del archivo Web.config utilizando DataProtectionConfigurationProvider:

aspnet_regiis -pe "connectionStrings" -app "/MiSitioWeb" -prov "DataProtectionConfigurationProvider"

Donde /MiSitioWeb es la ruta de acceso virtual a la aplicación ASP.NET.

Para utilizar RSAProtectedConfigurationProvider, cambie el modificador -prov del modo siguiente:

aspnet_regiis -pe "connectionStrings" -app "/MiSitioWeb" -prov "RSAProtectedConfigurationProvider"

El proveedor de configuración protegida RSA necesita que se cree un contenedor de claves antes de empezar a trabajar. NetFrameWorkConfigurationKey es el contenedor de claves que el proveedor utiliza de forma predeterminada. Si desea crear un contenedor de claves RSA, puede utilizar la herramienta aspnet_regiis.exe con el modificador -pc. Agregue la opción -exp si además desea exportar el contenedor de claves RSA.

aspnet_regiis -pc "NetFrameworkConfigurationKey" -exp

Para utilizar la cadena de conexión cifrada en la aplicación, únicamente necesita tener acceso al valor de cadena en tiempo de ejecución, tal y como se muestra a continuación.

string connStr = ConfigurationManager.ConnectionString["MyDbConn1"].ToString();

ASP.NET descifra automáticamente en tiempo de ejecución las secciones cifradas.

Nota

Es posible programar el cifrado y descifrado de las cadenas de conexión y otras secciones del archivo de configuración utilizando para ello la clase System.Configuration.SectionInformation y los métodos ProtectSection y UnProtectSection.

Para obtener más información acerca del uso de los proveedores de configuración protegida para cifrar secciones del archivo de configuración, consulte:

Paso 3. Configuración de la seguridad de SQL Server

A continuación, debe crear un inicio de sesión de SQL Server para la cuenta de servicio de la aplicación y conceder permisos restringidos para tener acceso a la base de datos. Debe restringir el acceso a determinados objetos de la base de datos, por ejemplo, a los procedimientos almacenados. Utilice el modelo siguiente para conceder acceso a la base de datos y limitar los permisos:

  1. Cree un inicio de sesión de SQL Server para la cuenta de la aplicación.

  2. Asigne el inicio de sesión a un usuario de base de datos en la base de datos correspondiente.

  3. Incluya al usuario de base de datos en una función de base de datos.

  4. Conceda los permisos limitados de función de base de datos únicamente a aquellas tablas y procedimientos almacenados a los que la aplicación necesite tener acceso.

Convendría que no concediera acceso directo a las tablas y que limitara el acceso únicamente a los procedimientos almacenados seleccionados. En caso de que tenga que conceder acceso a las tablas, conceda el acceso mínimo que la aplicación necesite. Por ejemplo, no conceda permiso de actualización si el permiso de lectura es suficiente.

La cuenta de servicio de la aplicación generalmente es la cuenta de servicio de red, que es la cuenta que se utiliza de forma predeterminada para ejecutar los grupos de aplicaciones ASP.NET en Windows Server 2003 e IIS 6.0, o una cuenta de servicio personalizada.

Utilización de la cuenta de servicio de red

Para conceder acceso a la base de datos a la cuenta de servicio de red

  1. Cree un inicio de sesión de SQL Server para la cuenta de servicio de red. Si la base de datos se encuentra en un servidor independiente, cree el inicio de sesión para la identidad nombreDominio\nombreEquipoServidorWeb$. Para crear el inicio de sesión de SQL Server, puede utilizar Enterprise Manager o ejecutar la instrucción SQL siguiente en la herramienta de línea de comandos osql.

    exec sp_grantlogin 'nombreDominio\nombreEquipoServidorWeb$'

  2. Cree un usuario de base de datos en la base de datos correspondiente y asigne el inicio de sesión a dicho usuario. Si lo prefiere, puede ejecutar las instrucciones SQL siguientes en osql:

    use targetDatabase

    go

    exec sp_grantdbaccess 'nombreDominio\nombreEquipoServidorWeb$'

    go

  3. Incluya al usuario de base de datos en una función de base de datos.

  4. Conceda permisos a la función. Convendría que concediera permisos de ejecución para los procedimientos almacenados seleccionados y que no concediera permiso directo a las tablas.

Utilización de una cuenta de servicio personalizada

En aquellas situaciones en las que ejecute varias aplicaciones Web en el mismo servidor Web, puede proporcionar aislamiento de la aplicación adicional si ejecuta cada aplicación en su propio grupo de aplicaciones mediante una cuenta de servicio personalizada independiente. Al evitar el uso de una identidad común para varias aplicaciones, puede restringir el acceso a la base de datos únicamente a la cuenta de su aplicación y garantizar que otras aplicaciones no puedan tener acceso a la base de datos. Esto también significa que cualquier modificación accidental del modo en que la cuenta de servicio de red está autorizada en la base de datos, o de los privilegios concedidos a la cuenta, no afectará a todas las aplicaciones Web.

Para crear una cuenta de servicio personalizada

  1. Cree una cuenta de dominio de Windows.

  2. Ejecute el comando Aspnet_regiis.exe siguiente para asignar a la cuenta los permisos ASP.NET correspondientes:

    aspnet_regiis.exe -ga machineName\userName

    En Windows 2003, la ejecución del comando Aspnet_regiis.exe -ga agrega la cuenta al grupo IIS_WPG. La pertenencia al grupo IIS_WPG concede a la cuenta el permiso Iniciar sesión como proceso por lotes y garantiza la concesión de los permisos del sistema de archivos y la metabase de IIS necesarios.

  3. Utilice la herramienta Directiva de seguridad local para conceder a la cuenta de Windows el derecho de usuario Denegar el inicio de sesión localmente.

  4. Utilice Administrador de IIS para crear un grupo de aplicaciones que se ejecute con la identidad de la nueva cuenta y asigne la aplicación ASP.NET al grupo.

Para obtener más información, consulte How To: Create a Service Account for an ASP.NET 2.0 Application (en inglés).

Para conceder acceso a la base de datos a la cuenta de servicio personalizada

Siga los pasos descritos anteriormente en el apartado "Utilización de la cuenta de servicio de red" pero, en esta ocasión, cree un inicio de sesión y conceda acceso a la cuenta de servicio personalizada en lugar de a la cuenta de servicio de red.

Paso 4. Prueba de acceso de seguridad

Para probar el acceso a la base de datos, cree una aplicación Web ASP.NET de prueba y agregue la página .aspx siguiente.

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<script runat="server">
  protected void Page_Load(object sender, EventArgs e)
  {
      using (SqlConnection cn = new SqlConnection
	  (ConfigurationManager.ConnectionStrings["MyDbConn1"].ToString()))
      {
          SqlCommand cmd = new SqlCommand("SELECT COUNT(*) FROM authors", cn);
          cn.Open();
          SqlDataReader rdr = cmd.ExecuteReader(CommandBehavior.CloseConnection);
          rdr.Read();
          Response.Write(rdr[0].ToString()); //read a value
      }
  }
</script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>SQL Authentication</title>
</head>
<body/>
</html>

Agregue un archivo Web.config y una entrada de cadena de conexión como se describe en el paso 1. Genere y ejecute la aplicación. Si no ha permitido específicamente el acceso SELECT a la tabla de autores, verá un mensaje de error similar al siguiente:

SELECT permission denied on object 'authors', database 'pubs', owner 'dbo'.

Factores de implementación

Cuando utilice la autenticación de Windows para conectarse a SQL en entornos de producción, considere las medidas siguientes:

  • Utilización de una cuenta de servicio personalizada.

  • Creación de un inicio de sesión de SQL Server para un grupo de Windows.

  • Asignación de permisos de base de datos a una función de base de datos.

Utilización de una cuenta de servicio personalizada

De forma predeterminada, las aplicaciones ASP.NET se ejecutan en grupos de aplicaciones que tienen una identidad de servicio de red. En aplicaciones de producción, se recomienda utilizar una cuenta de servicio personalizada y un grupo de aplicaciones dedicado. Esto ofrece una serie de ventajas:

  • La aplicación está aislada del resto de aplicaciones del servidor y las listas de control de acceso (ACL) a bases de datos y otros recursos de Windows se pueden configurar para ajustarlas a la aplicación concreta.

  • Las demás aplicaciones que se ejecutan con la identidad de servicio de red no pueden tener acceso a las bases de datos de la aplicación ni a otros recursos de Windows.

  • La auditoría de Windows se puede utilizar para realizar un seguimiento de la actividad de una aplicación individual.

  • La aplicación está blindada debido a los cambios en los permisos o privilegios aplicados, accidental o intencionadamente, por el administrador a la cuenta de servicio de red de otra aplicación

Creación de un inicio de sesión de SQL Server para un grupo de Windows.

En lugar de crear un inicio de sesión de SQL Server para la cuenta de servicio de red o la cuenta de servicio personalizada directamente, agregue esta cuenta a un grupo de Windows del servidor de base de datos y, a continuación, cree un inicio de sesión de SQL Server para ese grupo de Windows. Esto es más eficaz desde la perspectiva de la administración y le protege de posibles cambios en la identidad de la cuenta de la aplicación.

Asignación de permisos de base de datos a una función de base de datos

Durante el desarrollo, es posible conceder permisos de forma rápida y fácil directamente a un usuario de base de datos según el inicio de sesión de SQL Server de la cuenta de la aplicación. En entornos de producción, debe agregar el usuario de base de datos a una función de base de datos y, a continuación, asignar permisos a dicha función. Esto protege su configuración de posibles cambios en el nombre de usuario de base de datos.

Factores de batería de servidores Web

Utilice el proveedor RSA para proteger la información de la cadena de conexión si la aplicación está implementada en una batería de servidores Web. Puede utilizar el cifrado RSA en baterías de servidores Web, ya que es posible exportar claves RSA. Y debe hacerlo si cifra datos en un archivo Web.config antes de implementarlo en otros servidores de la batería de servidores Web. En este caso, es preciso exportar e implementar en los demás servidores la clave privada que se necesita para descifrar los datos.

Para obtener más información, consulte el apartado "Utilización del proveedor RSA para cifrar una cadena de conexión del archivo Web.config en una batería de servidores Web" del artículo Cómo: Cifrar secciones de configuración en ASP.NET 2.0 mediante RSA.

Cuentas duplicadas

Las cuentas duplicadas no son recomendables aunque son la solución si necesita utilizar la autenticación de Windows y sus servidores Web y de base de datos se encuentran en dominios diferentes entre los que no hay confianza, o si la autenticación de Windows está bloqueada por un firewall. Para utilizar cuentas duplicadas, cree una cuenta local con los mismos nombre de usuario y contraseña en cada servidor y, a continuación, cree un inicio de sesión de SQL Server para la cuenta local del servidor de base de datos.

Para crear una cuenta local

  1. Cree una cuenta de Windows local.

  2. Ejecute el comando Aspnet_regiis.exe siguiente para asignar a la cuenta los permisos ASP.NET correspondientes:

    aspnet_regiis.exe -ga machineName\userName

    En Windows 2003, la ejecución del comando Aspnet_regiis.exe -ga agrega la cuenta al grupo IIS_WPG. El grupo IIS_WPG concede el derecho de usuario Iniciar sesión como proceso por lotes y garantiza la concesión de los permisos del sistema de archivos necesarios.

  3. Utilice la herramienta Directiva de seguridad local para conceder a la cuenta de Windows el derecho de usuario Denegar el inicio de sesión localmente.

  4. Utilice Administrador de IIS para crear un grupo de aplicaciones que se ejecute con la identidad de la nueva cuenta y asigne la aplicación ASP.NET al grupo.

    Para obtener más información, consulte How To: Create a Service Account for an ASP.NET 2.0 Application (en inglés).

Para crear una cuenta duplicada en el servidor de base de datos

Cree una cuenta local en el servidor de base de datos con los mismos nombre de usuario y contraseña que la cuenta que ha creado en el servidor Web.

Para conceder acceso a la base de datos a la cuenta duplicada

Siga los pasos descritos anteriormente en el apartado "Utilización de la cuenta de servicio de red" pero, en esta ocasión, cree un inicio de sesión y conceda acceso a la cuenta local en lugar de a la cuenta de servicio de red.

Suplantación/delegación frente a subsistema de confianza

Subsistema de confianza

En un modelo de subsistema de confianza, el servidor de base de datos confía en la identidad de la aplicación Web. Por tanto, se confía en la identidad de la aplicación Web para realizar llamadas en nombre del autor original de la llamada (consulte la figura 1).

Figura 1. Modelo de subsistema de confianza

Ventajas e inconvenientes del modelo de subsistema de confianza

Algunas de las ventajas del modelo de subsistema de confianza son:

  • Escalabilidad: el modelo de subsistema de confianza admite la agrupación de conexión eficaz. La agrupación de conexión permite a varios clientes reutilizar las conexiones agrupadas disponibles. Funciona con este modelo porque todos los recursos de servidor a los que se tiene acceso utilizan el contexto de seguridad de la cuenta de servicio de la aplicación, independientemente de la identidad del autor de la llamada.

  • Reducción de las tareas de administración de ACL de servidor: únicamente la cuenta de servidor tiene acceso a los recursos de servidor (por ejemplo, bases de datos). Las ACL se configuran para esta identidad única.

  • Los usuarios no tienen acceso directo a los datos: en el modelo de subsistema de confianza, únicamente la cuenta de servicio tiene acceso a los recursos de servidor. Como consecuencia, los usuarios no tienen acceso directo a los datos de servidor sino que el acceso es a través de la aplicación (y por tanto, están sujetos a la autorización de ésta).

El modelo de subsistema de confianza también presenta una serie de inconvenientes:

  • Auditoría: para realizar la auditoría en el servidor, puede transmitir explícitamente (en el nivel de la aplicación) la identidad del autor original de la llamada al servidor y realizar la auditoría en éste. Está obligado a confiar en el nivel medio y existe efectivamente un posible riesgo de repudio. Si lo prefiere, puede generar una pista de auditoría en el nivel medio y, a continuación, correlacionarla con las pistas de auditoría del servidor (para hacerlo, debe asegurarse de que los relojes de los servidores estén sincronizados).

  • Mayor riesgo de exposición del servidor: en el modelo de subsistema de confianza, el servicio de nivel medio tiene acceso amplio a los recursos de servidor. Como consecuencia, un servicio de nivel medio expuesto podría facilitar a los intrusos el acceso amplio a los recursos de servidor.

Suplantación/delegación

Para suplantar al autor original de la llamada en ASP.NET, el método más sencillo es utilizar la autenticación de Windows para autenticar a los autores de las llamadas y definir impersonate="true" en el elemento <identity> del archivo Web.config, tal y como se muestra a continuación.

<configuration>
    <system.web>
        <authentication mode="Windows"/>
        <identity impersonate="true"/>
    ...
    </system.web>
</configuration>

Si la base de datos se encuentra en un servidor remoto, debe configurar además las cuentas correspondientes en Active Directory para la delegación. Por ejemplo, debe asegurarse de que la cuenta de servicio de la aplicación está marcada como Se confía para delegación y que las cuentas de usuario final no están marcadas como confidenciales, lo que significa que no pueden delegarse.

Para obtener más información, consulte How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0 (en inglés).

Ventajas e inconvenientes del modelo de suplantación/delegación

Algunas de las ventajas del modelo de suplantación/delegación son:

  • La auditoría del sistema operativo: permite a los administradores realizar un seguimiento de los usuarios que han intentado obtener acceso a recursos específicos.

  • La auditoría entre niveles: el contexto de seguridad del usuario se mantiene en todos los niveles físicos de la aplicación, lo que permite a los administradores auditar entre niveles. Normalmente, la auditoría se considera más autorizada si las generan las mismas rutinas que tienen acceso al recurso y en el momento preciso del acceso a éste.

  • Posibilidad de configurar controles de acceso específicos en la base de datos: es posible restringir cuentas de usuario individuales de forma independiente en la base de datos.

Algunos de los inconvenientes del modelo de suplantación/delegación son:

  • Escalabilidad: el modelo de suplantación/delegación no permite utilizar la agrupación de conexión de base de datos porque el acceso a la base de datos se realiza a través de conexiones vinculadas a los contextos de seguridad individuales de los autores originales de las llamadas. Esto limita considerablemente la capacidad de la aplicación de ampliarse para un número elevado de usuarios.

  • Mayor esfuerzo de administración: las ACL de los recursos de servidor deben mantenerse de modo que cada usuario disfrute del nivel adecuado de acceso. Si el número de recursos de servidor aumenta (y, con él, el número de usuarios), la administración de las ACL requerirá un esfuerzo considerable.

Recursos adicionales

Comentarios

Si desea enviar comentarios puede utilizar la wikipedia (en inglés) o el correo electrónico:

Nos interesan especialmente sus comentarios sobre los aspectos siguientes:

  • Problemas técnicos relacionados con nuestras recomendaciones

  • Problemas de aprovechamiento y utilidad

Soporte técnico

Los servicios de soporte de Microsoft ofrecen el soporte técnico de los productos y tecnologías de Microsoft a los que se hace referencia en esta guía. Para obtener información sobre soporte, visite el sitio Web de soporte de Microsoft en http://msdn.microsoft.com/security/default.aspx?pull=/isapi/gosupport.asp?Target=/.

Comunidad y grupos de noticias

El soporte técnico de la comunidad se ofrece en los foros y grupos de noticias:

Para sacar el mayor partido de estos foros, busque el grupo de noticias correspondiente a su tecnología o problema. Por ejemplo, si tiene un problema con las características de seguridad de ASP.NET, debería utilizar el foro de seguridad de ASP.NET (ASP.NET Security).

Colaboradores y revisores

  • Colaboradores y revisores externos: Andy Eunson; Chris Ullman, Content Master; David Raphael, Foundstone Professional Services, Rudolph Araujo, Foundstone Professional Services; Manoranjan M. Paul

  • Colaboradores y revisores de PSS y Microsoft Consulting Services: Wade Mascia, Tom Christian, Adam Semel, Nobuyuki Akama, Microsoft Corporation

  • Colaboradores y revisores de Microsoft Product Group: Stefan Schackow, Vikas Malhotra, Microsoft Corporation

  • Colaboradores y revisores de MSDN: Kent Sharkey, Microsoft Corporation

  • Colaboradores y revisores de Microsoft IT: Eric Rachner, Shawn Veney (ACE Team), Microsoft Corporation

  • Equipo de pruebas: Larry Brader, Microsoft Corporation; Nadupalli Venkata Surya Sateesh, Sivanthapatham Shanmugasundaram, Sameer Tarey, Infosys Technologies Ltd.

  • Equipo de edición: Nelly Delgado, Microsoft Corporation; Sharon Smith, Tina Burden McGrayne, Linda Werner & Associates Inc.

  • Dirección de publicación: Sanjeev Garg, Satyam Computer Services

Mostrar: