Exportar (0) Imprimir
Expandir todo

Capítulo 5 - Seguridad de intranet

Publicado: 26 de junio de 2006

J.D. Meier, Alex Mackman, Michael Dunner y Srinath Vasireddy
Microsoft Corporation
Octubre de 2002

Consulte la Página de entrada como punto de partida y para obtener una descripción completa del documento Crear aplicaciones ASP.NET seguras.

Resumen: Este capítulo describe cómo proteger escenarios de aplicaciones de intranet habituales. Presenta las características de cada escenario y describe los pasos necesarios para proteger el escenario. Se incluyen además secciones de análisis para proporcionar información adicional.

El acceso a las aplicaciones de intranet está restringido a un grupo limitado de usuarios autorizados (como los empleados que pertenecen a un dominio). Aunque una configuración de intranet limita la exposición de la aplicación, todavía deberá enfrentarse a varios problemas a la hora de desarrollar estrategias de autenticación, autenticación y comunicación segura. Por ejemplo, es posible que tenga dominios que no son de confianza, lo que dificulta la transmisión del contexto de seguridad y la identidad del llamador a los recursos de servidor del sistema. Además, puede que su entorno sea heterogéneo con diversos tipos de explorador. Esto dificulta todavía más el uso de un mecanismo de autenticación común.

Si tiene una intranet homogénea en la que todos los equipos ejecutan el sistema operativo Microsoft® Windows® 2000 o posterior y un dominio en el que se confía en los usuarios para la delegación, entonces dispone de la opción de realizar la delegación del contexto de seguridad del llamador al servidor.

También deberá considerar la comunicación segura. Aunque la aplicación se ejecuta en un entorno de intranet, no puede considerar como seguros los datos que se envían por la red. Es probable que necesite proteger los datos enviados entre los exploradores y el servidor Web además de los datos enviados entre los servidores de aplicaciones y las bases de datos.

Los siguientes escenarios habituales de intranet se utilizan en este capítulo para ilustrar técnicas clave de autenticación, autorización y comunicación segura.

  • ASP.NET y SQL Server

  • ASP.NET y Servicios Empresariales y SQL Server

  • ASP.NET y Servicios Web y SQL Server

  • ASP.NET y Remoting y SQL Server

Además, este capítulo describe un escenario de delegación de Windows 2000 (Transmitir el llamador original a la base de datos), en el que el contexto de seguridad y la identidad del llamador original se transmiten en el sistema operativo desde el explorador a la base de datos mediante servidores Web y de aplicaciones intermedios.

Nota

Varios de los escenarios descritos en este capítulo sustituyen la cuenta ASPNET predeterminada que se utiliza para ejecutar aplicaciones ASP.NET o bien cambian su contraseña para permitir la creación de cuentas duplicadas en equipos remotos. Estos escenarios actualizan el elemento de Machine.config, con lo que las credenciales se almacenan como texto no cifrado en Machine.config. Para obtener información detallada acerca de este tema, consulte "Obtener acceso a recursos de red" en el capítulo 8, "Seguridad de ASP.NET".

En esta página

ASP.NET y SQL Server ASP.NET y SQL Server
ASP.NET y Servicios Empresariales y SQL Server ASP.NET y Servicios Empresariales y SQL Server
ASP.NET y Servicios Web y SQL Server ASP.NET y Servicios Web y SQL Server
ASP.NET y Remoting y SQL Server ASP.NET y Remoting y SQL Server
Transmitir el llamador original a la base de datos Transmitir el llamador original a la base de datos
ASP.NET y Servicios Empresariales y SQL Server ASP.NET y Servicios Empresariales y SQL Server
Conclusión Conclusión

ASP.NET y SQL Server

En este escenario, una base de datos de RR.HH. distribuye datos por usuario de forma segura en una intranet homogénea. La aplicación utiliza un modelo de subsistemas de confianza y ejecuta llamadas en nombre de los llamadores originales. La aplicación autentica los llamadores mediante la autenticación integrada de Windows y realiza llamadas a la base de datos con la identidad del proceso de ASP.NET. Debido al carácter confidencial de los datos, se emplea SSL entre el servidor Web y los clientes.

La ilustración 5.1 muestra el modelo básico de este escenario de aplicaciones.

imagen

Ilustración 5.1
ASP.NET y SQL Server

Características

Este escenario tiene las siguientes características:

  • Los clientes tienen Internet Explorer.

  • Las cuentas de usuario están en el servicio de directorios de Microsoft Active Directory®.

  • La aplicación proporciona datos confidenciales por usuario.

  • Sólo deben obtener acceso a la aplicación los clientes autenticados.

  • La base de datos confía en la aplicación para la autenticación correcta de usuarios (es decir, la aplicación realiza llamadas a la base de datos en nombre de los usuarios).

  • Microsoft SQL Server™ utiliza una sola función de usuario de base de datos para la autorización.

Proteger el escenario

En este escenario, el servidor Web autentica el llamador y restringe el acceso a los recursos locales mediante la identidad del llamador. No es necesario realizar la suplantación en la aplicación Web para restringir el acceso a recursos con el llamador original. La base de datos realiza la autenticación con la identidad del proceso predeterminada de ASP.NET, que se trata de una cuenta con los mínimos privilegios (es decir, la base de datos confía en la aplicación ASP.NET).

Tabla 5.1: Medidas de seguridad

Categoría

Detalles

Autenticación

  • Proporcione autenticación segura en el servidor Web para autenticar llamadores originales mediante la autenticación integrada de Windows en IIS.

  • Utilice la autenticación de Windows en ASP.NET (sin suplantación).

  • Proteja las conexiones a la base de datos mediante SQL Server configurado para utilizar la autenticación de Windows.

  • La base de datos confía en el proceso de trabajo de ASP.NET para realizar llamadas. Autentique la identidad del proceso de ASP.NET en la base de datos.

Autorización

  • Configure recursos en el servidor Web mediante ACL vinculadas a los llamadores originales. Para facilitar la administración, los usuarios se agregan a grupos de Windows y los grupos se utilizan en las ACL.

  • La aplicación Web realiza comprobaciones de funciones de .NET con el llamador original para restringir el acceso a las páginas.

Comunicación segura

  • Proteja los datos confidenciales enviados entre el servidor Web y la base de datos.

  • Proteja los datos confidenciales enviados entre los llamadores originales y la aplicación Web.

El resultado

La ilustración 5.2 muestra la configuración de seguridad recomendada para este escenario.

imagen

Ilustración 5.2
La configuración de seguridad recomendada para el escenario de intranet de ASP.NET y SQL Server

Pasos para la configuración de la seguridad

Antes de empezar, conviene que consulte las siguientes referencias:

  • Crear cuentas de ASP.NET personalizadas (consulte "Cómo: Crear una cuenta personalizada para ejecutar ASP.NET" en la sección Referencia de esta guía)

  • Crear una cuenta de base de datos con los mínimos privilegios (consulte el capítulo 12, "Seguridad del acceso a datos")

  • Configurar SSL en un servidor Web (consulte "Cómo: Configurar SSL en un servidor Web" en la sección Referencia de esta guía)

  • Configurar IPSec (consulte "Cómo: Utilizar IPSec para proporcionar comunicación segura entre dos servidores" en la sección Referencia de esta guía.

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Web Habilitar la autenticación integrada de Windows

Para utilizar la configuración de autenticación de IIS, utilice el complemento MMC de IIS. Haga clic con el botón secundario del mouse (ratón) en el directorio virtual de la aplicación y, a continuación, haga clic en Propiedades.
Haga clic en la ficha Seguridad de directorios y después en Modificar en el grupo Control de autenticación y acceso anónimo.

Configurar ASP.NET

Paso

Más información

Cambiar la contraseña de ASPNET a un valor de contraseña segura conocido

ASPNET es una cuenta local con los mínimos privilegios que se utiliza de forma predeterminada para ejecutar aplicaciones Web ASP.NET.

Establezca la contraseña de la cuenta ASPNET en un valor conocido mediante Usuarios y grupos locales.

Edite el archivo Machine.config que está ubicado en %windir%\Microsoft.NET\Framework\ v1.0.3705\CONFIG
y vuelva a configurar el atributo de contraseña en el elemento <processModel>.

Predeterminado

<!-- userName="machine" password="AutoGenerate"  
        -->

Se convierte en

<!-- userName="machine"  
  password="YourNewStrongPassword"  
        -->

Configurar la aplicación Web ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en la raíz del directorio virtual de la aplicación.
Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Comprobar que está desactivada la suplantación

La suplantación está desactivada de forma predeterminada; no obstante, deberá comprobar que está desactivada en Web.config tal y como se muestra a continuación:

<identity impersonate="false" />

También puede obtener el mismo resultado si quita el elemento <identity>.

Configurar la comunicación segura

Paso

Más información

Crear una cuenta de Windows en el equipo de SQL Server idéntica a la cuenta del proceso de ASP.NET (ASPNET)

El nombre de usuario y la contraseña deben coincidir con los de la cuenta ASPNET.
Otorgue a la cuenta los siguientes privilegios:
- Tener acceso a este equipo desde la red
- Denegar el inicio de sesión localmente
- Iniciar sesión como trabajo por lotes

Configurar SQL Server para que utilice la autenticación de Windows

.

Crear un inicio de sesión de SQL Server para la cuenta ASPNET local

Así se concede acceso a SQL Server.

Crear un nuevo usuario de base de datos y asignar el nombre de inicio de sesión al usuario de base de datos

Así se concede acceso a la base de datos especificada.

Crear una nueva función de base de datos definida por el usuario y agregar el usuario de base de datos a la función

.

Establecer permisos de base de datos para la función de base de datos

Conceda los permisos mínimos. Para obtener más información, consulte el capítulo 12, "Seguridad del acceso a datos".

Análisis

  • La autenticación integrada de Windows en IIS es ideal para este escenario porque todos los usuarios tienen cuentas de Windows y utilizan Microsoft Internet Explorer. La ventaja de la autenticación integrada de Windows reside en que la contraseña del usuario nunca se envía por la red. Además, el inicio de sesión es transparente para el usuario porque Windows utiliza la sesión de inicio interactiva actual del usuario.

  • ASP.NET se ejecuta como cuenta con los mínimos privilegios, con lo que se reduce la posibilidad de que se comprometa la seguridad y se produzcan daños.

  • No es necesario utilizar la suplantación en ASP.NET para llevar a cabo comprobaciones de funciones de .NET ni para proteger recursos de ACL de Windows del llamador original. Para realizar comprobaciones de funciones de .NET con el llamador original, se recupera del contexto HTTP el objeto WindowsPrincipal que representa al llamador original tal y como se muestra a continuación:

WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal); 
if ( wp.IsInRole("Manager") ) 
{ 
  // User is authorized to perform manager-specific functionality 
}

FileAuthorizationModule de ASP.NET realiza controles de ACL con el llamador original para tipos de archivo de ASP.NET que están asignados a aspnet_isapi.dll en IIS. En el caso de tipos de archivo estáticos, como .jpg, .gif y .htm, IIS actúa de guardián y realiza controles de acceso con la identidad del llamador original en función de los permisos de NTFS asociados al archivo.

  • Al utilizar la autenticación de Windows en SQL Server, se evita tener que almacenar credenciales en archivos y transmitirlas por la red al servidor de bases de datos.

  • El uso de una cuenta duplicada de Windows en el servidor de bases de datos (una cuenta idéntica a la cuenta ASPNET local) facilita la administración. Si de modifica la contraseña en un equipo, deberá sincronizarse y actualizarse en el otro. En algunos escenarios, es posible utilizar una cuenta de dominio con los mínimos privilegios para facilitar la administración.

  • El uso de la cuenta local duplicada también funciona cuando existe un servidor de seguridad en el que pueden no estar abiertos los puertos necesarios para la autenticación de Windows. Por el contrario, el uso de la autenticación de Windows y cuentas de dominio podría no funcionar en este escenario.

  • Necesitará asegurarse de que la granularidad de los grupos de Windows se ajuste a sus necesidades de seguridad. Puesto que la seguridad basada en funciones de .NET está fundamentada en la pertenencia a grupos de Windows, esta solución depende de la configuración de los grupos de Windows con el nivel adecuado de granularidad correspondiente a las categorías de usuarios (que comparten los mismos privilegios de seguridad) que tienen acceso a la aplicación. Los grupos de Windows que utilice en este caso para administrar las funciones podrían ser locales del equipo o grupos de dominio.

  • Se prefieren las funciones de usuario de base de datos de SQL Server en lugar de las funciones de aplicación para evitar los problemas de administración de contraseñas y de agrupación de conexiones relacionados con el uso de funciones de aplicación de SQL.

Las aplicaciones activan las funciones de aplicación de SQL mediante la llamada a un procedimiento almacenado integrado con un nombre de función y una contraseña. Por lo tanto, deberá almacenarse la contraseña de forma segura. La agrupación de conexiones de bases de datos también deberá estar deshabilitada cuando utilice funciones de aplicación de SQL, lo que tiene un grave impacto sobre la escalabilidad de la aplicación.

Para obtener más información acerca de las funciones de usuario de base de datos y las funciones de aplicación de SQL Server, consulte el capítulo 12, "Seguridad del acceso a datos".

  • El usuario de base de datos se agrega a una función de usuario de base de datos y se asignan permisos a la función de modo que, en caso de modificarse la cuenta de base de datos, no tenga que modificar los permisos de todos los objetos de base de datos.

Preguntas y respuestas

¿Por qué no puedo habilitar la suplantación para la aplicación Web y así poder proteger los recursos a los que tiene acceso mi aplicación Web mediante ACL configuradas con el llamador original?

Si habilita la suplantación, el contexto de seguridad suplantado no tendrá credenciales de red (suponiendo que no se ha habilitado la delegación y utiliza la autenticación integrada de Windows). Por lo tanto, la llamada remota a SQL Server utilizará una sesión NULL, que producirá una llamada con errores. Con la suplantación deshabilitada, la petición remota utilizará la identidad del proceso de ASP.NET.

El escenario anterior utiliza FileAuthorizationModule de ASP.NET, que realiza la autorización mediante ACL de Windows con la identidad del llamador original y no requiere suplantación.

Si utiliza la autenticación básica en lugar de la autenticación integrada de Windows (NTLM) y habilita la suplantación, todas las llamadas a la base de datos utilizarían el contexto de seguridad del llamador original. Cada cuenta de usuario (o los grupos de Windows a los que pertenece el usuario) requeriría inicios de sesión de SQL Server. Sería necesario proteger los permisos de objetos de base de datos del grupo de Windows (o llamador original).

La base de datos desconoce quién es el llamador original. ¿Cómo puedo crear una pista de autoría?

Lleve a cabo la auditoría de usuarios finales en la aplicación Web o transmita la identidad del usuario de forma explícita como parámetro de la llamada de acceso a datos.

Escenarios relacionados

Exploradores distintos de Internet Explorer

El uso de la autenticación integrada de Windows en IIS requiere Internet Explorer. Éstas son las opciones que suelen estar disponibles en un entorno con distintos tipos de exploradores:

  • Autenticación básica y SSL. La mayoría de los exploradores admiten la autenticación básica. Puesto que las credenciales del usuario se transmiten por la red, debe utilizar SSL para proteger el escenario.

  • Certificados de cliente. Los certificados de cliente pueden asignarse a una cuenta única de Windows o se puede utilizar una sola cuenta de Windows para representar a todos los clientes. El uso de certificados de cliente requiere también SSL.

  • Autenticación mediante Formularios. La autenticación mediante Formularios puede validar credenciales en un almacén de datos personalizado, como una base de datos, o en Active Directory.

Si realiza la autenticación en Active Directory, asegúrese de recuperar solamente los grupos necesarios que sean relevantes para la aplicación. Del mismo modo que no se deben utilizar cláusulas SELECT * para emitir consultas a una base de datos, no deberá tampoco recuperar ciegamente todos los grupos de Active Directory.

Si realiza la autenticación en una base de datos, necesitará analizar cuidadosamente la información de los comandos SQL para protegerse de los ataques de inyección SQL y deberá guardar los valores hash de contraseña (con valor salt) en la base de datos en lugar de utilizar contraseñas cifradas o de texto no cifrado.

Para obtener más información acerca de cómo utilizar SQL Server como almacén de credenciales y almacenar contraseñas en la base de datos, consulte el capítulo 12, "Seguridad del acceso a datos".

Observe que, en todos los casos, si no utiliza la autenticación integrada de Windows, en la que la plataforma administra las credenciales de forma automática, acabará teniendo que utilizar SSL. No obstante, esta ventaja se aplica estrictamente al proceso de autenticación. Si transmite datos confidenciales por la red, todavía deberá utilizar IPSec o SSL.

Autenticación de SQL en la base de datos

En algunos escenarios, es posible que se vea obligado a utilizar la autenticación de SQL en lugar de la autenticación de Windows que prefiere. Por ejemplo, podría haber un servidor de seguridad entre la aplicación Web y la base de datos, o el servidor Web podría no ser miembro del dominio por motivos de seguridad. Esto también impide el uso de la autenticación de Windows. En este caso, podría utilizar la autenticación de SQL entre la base de datos y el servidor Web. Para proteger este escenario, debería:

Transmitir el llamador original a la base de datos

En este escenario, las llamadas se realizan desde la aplicación Web a la base de datos con el contexto de seguridad del llamador original. En este enfoque, es importante tener en cuenta los siguientes aspectos:

  • Si elige este enfoque, necesitará utilizar la autenticación Kerberos (con cuentas configuradas para la suplantación) o la autenticación básica.Puede ver una explicación de un escenario de delegación en la sección "Transmitir el llamador original a la base de datos" más adelante en este capítulo.

  • También deberá habilitar la suplantación en ASP.NET. De este modo, el acceso a los recursos del sistema local se realiza mediante el contexto de seguridad del llamador original y, por lo tanto, las ACL de recursos locales como el registro y el registro de sucesos requieren la configuración apropiada.

  • La agrupación de conexiones de bases de datos es limitada porque no permite a los llamadores originales compartir conexiones. Cada conexión está asociada al contexto de seguridad del llamador.

  • Una alternativa a la transmisión del contexto de seguridad del usuario consiste en transmitir la identidad del llamador original en la aplicación (por ejemplo, mediante parámetros de métodos y de procedimientos almacenados).

ASP.NET y Servicios Empresariales y SQL Server

En este escenario, las páginas ASP.NET llaman a componentes empresariales alojados en una aplicación de Servicios Empresariales que, a su vez, se conecta a una base de datos. Como ejemplo, considere un sistema interno de emisión de pedidos de compra que utiliza transacciones en la intranet y permite realizar pedidos a los departamentos internos. Este escenario se muestra en la ilustración 5.3.

imagen

Ilustración 5.3
ASP.NET llama a un componente de Servicios Empresariales que, a su vez, llama a la base de datos.

Características

Este escenario tiene las siguientes características:

  • Los usuarios tienen Internet Explorer.

  • Los componentes se distribuyen en el servidor Web.

  • La aplicación maneja datos confidenciales que se deben proteger durante la transmisión.

  • Los componentes empresariales se conectan a SQL Server mediante la autenticación de Windows.

  • La funcionalidad empresarial de estos componentes está restringida en función de la identidad del llamador.

  • Los componentes revisados están configurados como aplicación de servidor (fuera del proceso).

  • Los componentes se conectan a la base de datos con la identidad del proceso de la aplicación de servidor.

  • La suplantación está habilitada en ASP.NET (para facilitar la seguridad basada en funciones de Servicios Empresariales).

Proteger el escenario

En este escenario, el servidor Web autentica el llamador original y transmite el contexto de seguridad del llamador al componente revisado. Este componente autoriza el acceso a la funcionalidad empresarial en función de la identidad del llamador original. La base de datos realiza la autenticación con la identidad del proceso de la aplicación de Servicios Empresariales (es decir, la base de datos confía en los componentes revisados de la aplicación de Servicios Empresariales). Cuando el componente revisado realiza llamadas a la base de datos, transmite la identidad del usuario en la aplicación (mediante parámetros de consulta de confianza).

Tabla 5.2: Medidas de seguridad

Categoría

Detalles

Autenticación

  • Proporcione autenticación segura en el servidor Web mediante la autenticación integrada de Windows.

  • Transmita el contexto de seguridad del llamador original al componente revisado para admitir las comprobaciones de funciones de Servicios Empresariales (COM+).

  • Las conexiones seguras a la base de datos utilizan la autenticación de Windows.

  • La base de datos confía en la identidad del componente revisado para que realice las llamadas de base de datos. La base de datos autentica la identidad del proceso de la aplicación de Servicios Empresariales.

Autorización

Autorice el acceso a la lógica empresarial mediante funciones de Servicios Empresariales (COM+).

Comunicación segura

  • Proteja los datos confidenciales enviados entre los usuarios y la aplicación Web mediante SSL.

  • Proteja los datos confidenciales enviados entre el servidor Web y la base de datos mediante IPSec.

El resultado

La ilustración 5.4 muestra la configuración de seguridad recomendada para este escenario.

imagen

Ilustración 5.4
La configuración de seguridad recomendada para el escenario de intranet de ASP.NET y Servicios Empresariales locales y SQL Server

Pasos para la configuración de la seguridad

Antes de empezar, conviene que consulte las siguientes referencias:

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Web
Habilitar la autenticación integrada de Windows

.

Configurar ASP.NET

Paso

Más información

Configurar la aplicación Web ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en la raíz del directorio virtual de la aplicación.

Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Configurar la aplicación Web ASP.NET para la suplantación

Edite el archivo Web.config en el directorio virtual de la aplicación Web.

Establezca el elemento <identity> en:

<identity impersonate="true" />

Configurar la seguridad DCOM de ASP.NET para garantizar que las llamadas a Servicios Empresariales admitan la suplantación de llamador

Edite Machine.config y busque el elemento <processModel>. Confirme que el atributo comImpersonationLevel está establecido en Impersonate (suplantar), que es la configuración predeterminada.

<processModel
comImpersonationLevel="Impersonate"

Configurar Servicios Empresariales

Paso

Más información

Configurar la aplicación Web ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en la raíz del directorio virtual de la aplicación.

Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Configurar la aplicación Web ASP.NET para la suplantación

Edite el archivo Web.config en el directorio virtual de la aplicación Web.

Establezca el elemento <identity> en:

<identity impersonate="true" />

Configurar la seguridad DCOM de ASP.NET para garantizar que las llamadas a Servicios Empresariales admitan la suplantación de llamador

Edite Machine.config y busque el elemento <processModel>. Confirme que el atributo comImpersonationLevel está establecido en Impersonate (suplantar), que es la configuración predeterminada.

<processModel
comImpersonationLevel="Impersonate"

Configurar Servicios Empresariales

Paso

Más información

Crear una cuenta personalizada para ejecutar Servicios Empresariales

NOTA: si utiliza una cuenta local, deberá crear también una cuenta duplicada en el equipo de SQL Server.

Configurar la aplicación de Servicios Empresariales como aplicación de servidor

Para configurarla, puede utilizar la herramienta Servicios de componente o el siguiente atributo de .NET en el ensamblado de componentes revisados.

[assembly: 
  ApplicationActivation(ActivationOption.Server)]

Configurar funciones de Servicios Empresariales (COM+)

Utilice la herramienta Servicios de componente o una secuencia de comandos para agregar usuarios o grupos de Windows a funciones. Las funciones pueden definirse mediante atributos de .NET en el ensamblado de componentes revisados.

Configurar Servicios Empresariales para que se ejecute como la cuenta personalizada

Puede utilizar la herramienta Servicios de componente o una secuencia de comandos para la configuración. No se pueden utilizar atributos de .NET en el ensamblado de componentes revisados.

Configurar SQL Server

Paso

Más información

Crear una cuenta de Windows en el equipo de SQL Server idéntica a la cuenta del proceso de Servicios Empresariales

El nombre de usuario y la contraseña deben coincidir con los de la cuenta personalizada de Servicios Empresariales.
Otorgue a la cuenta los siguientes privilegios:
- Tener acceso a este equipo desde la red
- Denegar el inicio de sesión localmente
- Iniciar sesión como trabajo por lotes

Configurar SQL Server para que utilice la autenticación de Windows

.

Crear un inicio de sesión de SQL Server para la cuenta de Servicios Empresariales

Así se concede acceso a SQL Server.

Crear un nuevo usuario de base de datos y asignar el nombre de inicio de sesión al usuario de base de datos

Así se concede acceso a la base de datos especificada

Crear una nueva función de usuario de base de datos y agregar el usuario de base de datos a la función

.

Establecer permisos de base de datos para la función de usuario de base de datos

Conceda los permisos mínimos. Para obtener más información, consulte el capítulo 12, "Seguridad del acceso a datos".

Configurar la comunicación segura

Paso

Más información

Configurar el sitio Web para que utilice SSL

Consulte "Cómo: Configurar SSL en un servidor Web" en la sección Referencia de esta guía.

Configurar IPSec entre el servidor Web y el servidor de bases de datos

Consulte "Cómo: Utilizar IPSec para proporcionar comunicación segura entre dos servidores" en la sección Referencia de esta guía.

Análisis

  • ASP.NET y Servicios Empresariales se ejecutan como cuentas con los mínimos privilegios, con lo que se reduce la posibilidad de que se comprometa la seguridad y se produzcan daños. Si se ve comprometida cualquiera de las identidades del proceso, los privilegios limitados de la cuenta reducen el alcance de los daños. Además, en el caso de ASP.NET, se consigue limitar el daño producido por secuencias de comandos malintencionadas.

  • La aplicación ASP.NET deberá estar configurada para la suplantación con el fin de transmitir el contexto de seguridad del llamador original a los componentes de Servicios Empresariales [para admitir la autorización basada en funciones de Servicios Empresariales (COM+)]. Si no realiza la suplantación, las comprobaciones de funciones se realizan con la identidad del proceso (es decir, el proceso de trabajo de ASP.NET). La suplantación afecta a los usuarios autorizados a usar los recursos.Sin la suplantación, las comprobaciones de recursos del sistema se llevan a cabo con la identidad del proceso de ASP.NET. Con la suplantación, estas comprobaciones se realizan con el llamador original. Para obtener más información acerca de cómo obtener acceso a recursos del sistema desde ASP.NET, consulte "Obtener acceso a recursos de sistema" en el capítulo 8, "Seguridad de ASP.NET".

  • Al utilizar funciones de Servicios Empresariales (COM+), los controles de acceso se llevan a cabo en el nivel medio, donde está ubicada la lógica empresarial. En este caso, los llamadores se comprueban en la puerta, se asignan a funciones y las llamadas a la lógica empresarial se basan en funciones. Así se evita realizar llamadas innecesarias al servidor. Otra ventaja de las funciones de Servicios Empresariales (COM+) reside en que se pueden crear y administrar funciones durante la implementación mediante el Administrador de Servicios de componente.

  • La autenticación de Windows en SQL permite evitar almacenar credenciales en archivos y enviarlas por la red.

  • El uso de una cuenta local para ejecutar la aplicación de Servicios Empresariales junto con una cuenta duplicada en el servidor de bases de datos también funciona cuando existe un servidor de seguridad en el que los puertos necesarios para la autenticación de Windows podrían no estar abiertos. Por el contrario, el uso de la autenticación de Windows y cuentas de dominio podría no funcionar en este escenario.

Riesgos

  • El uso de una cuenta duplicada de Windows en el servidor de bases de datos (una cuenta idéntica a la cuenta del proceso de Servicios Empresariales) facilita la administración. Deberán actualizarse y sincronizarse las contraseñas manualmente de forma periódica.

  • Puesto que la seguridad basada en funciones de .NET está fundamentada en la pertenencia a grupos de Windows, esta solución depende de la configuración de los grupos de Windows con el nivel adecuado de granularidad correspondiente a las categorías de usuarios (que comparten los mismos privilegios de seguridad) que tienen acceso a la aplicación.

ASP.NET y Servicios Web y SQL Server

En este escenario, un servidor Web que ejecuta páginas ASP.NET se conecta a un servicio Web de un servidor remoto. A su vez, este servidor se conecta a un servidor de bases de datos remoto. Como ejemplo, considere una aplicación Web de RR.HH. que suministra datos confidenciales específicos de un usuario. La aplicación depende del servicio Web para la recuperación de datos. La ilustración 5.5 muestra el modelo básico de este escenario de aplicaciones.

imagen

Ilustración 5.5
ASP.NET y servicio Web remoto y SQL Server

El servicio Web expone un método que permite a un empleado recuperar sus datos personales. Los datos deberán suministrarse solamente a usuarios autenticados que utilizan la aplicación Web. El servicio Web también proporciona un método que admite la recuperación de información de cualquier empleado. Esta funcionalidad deberá estar disponible únicamente para los miembros del departamento de RR.HH. o de nóminas. En este escenario, los empleados se clasifican en tres grupos de Windows.

  • HRDept (miembros del departamento de RR.HH.)

    Los miembros de este grupo pueden recuperar información acerca de cualquier empleado.

  • PayrollDept (miembros del departamento de nóminas)

    Los miembros de este grupo pueden recuperar información acerca de cualquier empleado.

  • Employees (todos los empleados)

    Los miembros de este grupo sólo pueden recuperar su propia información.

Debido al carácter confidencial de los datos, el tráfico entre todos los nodos deberá ser seguro.

Características

  • Los usuarios tienen Internet Explorer 5.x o posterior.

  • Todos los equipos ejecutan Windows 2000 o posterior.

  • Las cuentas de usuario están en un único bosque de Active Directory.

  • La aplicación transmite el contexto de seguridad del llamador original hasta la base de datos.

  • Todos los niveles utilizan la autenticación de Windows.

  • Las cuentas de usuarios del dominio están configuradas para la delegación.

  • La base de datos no admite la delegación.

Proteger el escenario

En este escenario, el servidor Web que aloja la aplicación Web ASP.NET autentica la identidad del llamador original y transmite su contexto de seguridad al servidor remoto que aloja el servicio Web. De este modo, se permite la aplicación de controles de autorización a métodos Web para permitir o denegar el acceso al llamador original. La base de datos realiza la autenticación con la identidad del proceso del servicio Web (la base de datos confía en el servicio Web). A su vez, el servicio Web realiza llamadas a la base de datos y transmite la identidad del usuario en la aplicación mediante parámetros de procedimientos almacenados.

Tabla 5.3: Medidas de seguridad

Paso

Más información

Autenticación

  • La aplicación Web autentica usuarios mediante la autenticación integrada de Windows desde IIS.

  • El servicio Web utiliza la autenticación integrada de Windows desde IIS. Autentica el contexto de seguridad del llamador original delegado por la aplicación Web.

  • El protocolo de autenticación Kerberos se utiliza para transmitir el contexto de seguridad del llamador original desde la aplicación Web al servicio Web mediante la delegación.

  • La autenticación de Windows se utiliza para establecer la conexión con la base de datos mediante la cuenta del proceso de ASP.NET.

Autorización

  • La aplicación Web realiza comprobaciones de funciones con el llamador original para restringir el acceso a las páginas.

  • El acceso a los métodos del servicio Web se controla mediante el uso de funciones de .NET basadas en la pertenencia a grupos de Windows del llamador original.

Comunicación segura

  • Los datos confidenciales enviados entre los llamadores originales y la aplicación Web y el servicio Web se protegen con SSL.

  • Los datos confidenciales enviados entre el servicio Web y la base de datos se protegen con IPSec.

El resultado

La ilustración 5.6 muestra la configuración de seguridad recomendada para este escenario.

imagen

Ilustración 5.6
La configuración de seguridad recomendada para el escenario de intranet de ASP.NET y el servicio Web y SQL Server

Pasos para la configuración de la seguridad

Antes de empezar, conviene que consulte las siguientes referencias:

Configurar el servidor Web (que aloja la aplicación Web)

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Web
Habilitar la autenticación integrada de Windows para la raíz virtual de la aplicación Web

.

Configurar ASP.NET

Paso

Más información

Configurar la aplicación Web ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en el directorio virtual de la aplicación Web.
Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Configurar la aplicación Web ASP.NET para la suplantación

Edite el archivo Web.config en el directorio virtual de la aplicación Web.
Establezca el elemento <identity> en:

<identity impersonate="true" />

Configurar el servidor de aplicaciones (que aloja el servicio Web)

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual del servicio Web

Habilitar la autenticación integrada de Windows para el directorio raíz virtual del servicio Web

.

Configurar ASP.NET

Paso

Más información

Configurar la aplicación Web ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en la raíz del directorio virtual de la aplicación.Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Configurar la aplicación Web ASP.NET para la suplantación

Edite el archivo Web.config en el directorio virtual de la aplicación Web.Establezca el elemento <identity> en:

<identity impersonate="true" />

Configurar la seguridad DCOM de ASP.NET para garantizar que las llamadas a Servicios Empresariales admitan la suplantación de llamador

Edite Machine.config y busque el elemento <processModel>. Confirme que el atributo comImpersonationLevel está establecido en Impersonate (suplantar), que es la configuración predeterminada.

<processModel
        comImpersonationLevel="Impersonate"

Configurar Servicios Empresariales

Paso

Más información

Crear una cuenta personalizada para ejecutar Servicios Empresariales

NOTA: si utiliza una cuenta local, deberá crear también una cuenta duplicada en el equipo de SQL Server.

Configurar la aplicación de Servicios Empresariales como aplicación de servidor

Para configurarla, puede utilizar la herramienta Servicios de componente o el siguiente atributo de .NET en el ensamblado de componentes revisados.

[assembly:
  ApplicationActivation(ActivationOption.Server)]

Configurar funciones de Servicios Empresariales (COM+)

Utilice la herramienta Servicios de componente o una secuencia de comandos para agregar usuarios o grupos de Windows a funciones.
Las funciones pueden definirse mediante atributos de .NET en el ensamblado de componentes revisados.

Configurar Servicios Empresariales para que se ejecute como la cuenta personalizada

Puede utilizar la herramienta Servicios de componente o una secuencia de comandos para la configuración. No se pueden utilizar atributos de .NET en el ensamblado de componentes revisados.

Configurar SQL Server

Paso

Más información

Crear una cuenta de Windows en el equipo de SQL Server idéntica a la cuenta del proceso de Servicios Empresariales

El nombre de usuario y la contraseña deben coincidir con los de la cuenta personalizada de Servicios Empresariales.
Otorgue a la cuenta los siguientes privilegios:
- Tener acceso a este equipo desde la red
- Denegar el inicio de sesión localmente
- Iniciar sesión como trabajo por lotes

Configurar SQL Server para que utilice la autenticación de Windows

.

Crear un inicio de sesión de SQL Server para la cuenta de Servicios Empresariales

Así se concede acceso a SQL Server.

Crear un nuevo usuario de base de datos y asignar el nombre de inicio de sesión al usuario de base de datos

Así se concede acceso a la base de datos especificada

Crear una nueva función de usuario de base de datos y agregar el usuario de base de datos a la función

.

Establecer permisos de base de datos para la función de usuario de base de datos

Conceda los permisos mínimos.Para obtener más información, consulte el capítulo 12, "Seguridad del acceso a datos".

Configurar la comunicación segura

Paso

Más información

Configurar el sitio Web para que utilice SSL

Consulte "Cómo: Configurar SSL en un servidor Web" en la sección Referencia de esta guía.

Configurar IPSec entre el servidor Web y el servidor de bases de datos

Consulte "Cómo: Utilizar IPSec para proporcionar comunicación segura entre dos servidores" en la sección Referencia de esta guía.

Análisis

  • ASP.NET y Servicios Empresariales se ejecutan como cuentas con los mínimos privilegios, con lo que se reduce la posibilidad de que se comprometa la seguridad y se produzcan daños. Si se ve comprometida cualquiera de las identidades del proceso, los privilegios limitados de la cuenta reducen el alcance de los daños. Además, en el caso de ASP.NET, se consigue limitar el daño producido por secuencias de comandos malintencionadas.

  • La aplicación ASP.NET deberá estar configurada para la suplantación con el fin de transmitir el contexto de seguridad del llamador original a los componentes de Servicios Empresariales [para admitir la autorización basada en funciones de Servicios Empresariales (COM+)]. Si no realiza la suplantación, las comprobaciones de funciones se realizan con la identidad del proceso (es decir, el proceso de trabajo de ASP.NET). La suplantación afecta a los usuarios autorizados a usar los recursos.
    Sin la suplantación, las comprobaciones de recursos del sistema se llevan a cabo con la identidad del proceso de ASP.NET. Con la suplantación, estas comprobaciones se realizan con el llamador original. Para obtener más información acerca de cómo obtener acceso a recursos del sistema desde ASP.NET, consulte "Obtener acceso a recursos de sistema" en el capítulo 8, "Seguridad de ASP.NET".

  • Al utilizar funciones de Servicios Empresariales (COM+), los controles de acceso se llevan a cabo en el nivel medio, donde está ubicada la lógica empresarial. En este caso, los llamadores se comprueban en la puerta, se asignan a funciones y las llamadas a la lógica empresarial se basan en funciones. Así se evita realizar llamadas innecesarias al servidor. Otra ventaja de las funciones de Servicios Empresariales (COM+) reside en que se pueden crear y administrar funciones durante la implementación mediante el Administrador de Servicios de componente.

  • La autenticación de Windows en SQL permite evitar almacenar credenciales en archivos y enviarlas por la red.

  • El uso de una cuenta local para ejecutar la aplicación de Servicios Empresariales junto con una cuenta duplicada en el servidor de bases de datos también funciona cuando existe un servidor de seguridad en el que los puertos necesarios para la autenticación de Windows podrían no estar abiertos. Por el contrario, el uso de la autenticación de Windows y cuentas de dominio podría no funcionar en este escenario.

Riesgos

  • El uso de una cuenta duplicada de Windows en el servidor de bases de datos (una cuenta idéntica a la cuenta del proceso de Servicios Empresariales) facilita la administración. Deberán actualizarse y sincronizarse las contraseñas manualmente de forma periódica.

  • Puesto que la seguridad basada en funciones de .NET está fundamentada en la pertenencia a grupos de Windows, esta solución depende de la configuración de los grupos de Windows con el nivel adecuado de granularidad correspondiente a las categorías de usuarios (que comparten los mismos privilegios de seguridad) que tienen acceso a la aplicación.

ASP.NET y Servicios Web y SQL Server

En este escenario, un servidor Web que ejecuta páginas ASP.NET se conecta a un servicio Web de un servidor remoto. A su vez, este servidor se conecta a un servidor de bases de datos remoto. Como ejemplo, considere una aplicación Web de RR.HH. que suministra datos confidenciales específicos de un usuario. La aplicación depende del servicio Web para la recuperación de datos. La ilustración 5.5 muestra el modelo básico de este escenario de aplicaciones.

imagen

Ilustración 5.5
ASP.NET y servicio Web remoto y SQL Server

El servicio Web expone un método que permite a un empleado recuperar sus datos personales. Los datos deberán suministrarse solamente a usuarios autenticados que utilizan la aplicación Web. El servicio Web también proporciona un método que admite la recuperación de información de cualquier empleado. Esta funcionalidad deberá estar disponible únicamente para los miembros del departamento de RR.HH. o de nóminas. En este escenario, los empleados se clasifican en tres grupos de Windows.

  • HRDept (miembros del departamento de RR.HH.)

    Los miembros de este grupo pueden recuperar información acerca de cualquier empleado.

  • PayrollDept (miembros del departamento de nóminas)

    Los miembros de este grupo pueden recuperar información acerca de cualquier empleado.

  • Employees (todos los empleados)

    Los miembros de este grupo sólo pueden recuperar su propia información.

Debido al carácter confidencial de los datos, el tráfico entre todos los nodos deberá ser seguro.

Características

  • Los usuarios tienen Internet Explorer 5.x o posterior.

  • Todos los equipos ejecutan Windows 2000 o posterior.

  • Las cuentas de usuario están en un único bosque de Active Directory.

  • La aplicación transmite el contexto de seguridad del llamador original hasta la base de datos.

  • Todos los niveles utilizan la autenticación de Windows.

  • Las cuentas de usuarios del dominio están configuradas para la delegación

  • La base de datos no admite la delegación.

Proteger el scenario

En este escenario, el servidor Web que aloja la aplicación Web ASP.NET autentica la identidad del llamador original y transmite su contexto de seguridad al servidor remoto que aloja el servicio Web. De este modo, se permite la aplicación de controles de autorización a métodos Web para permitir o denegar el acceso al llamador original. La base de datos realiza la autenticación con la identidad del proceso del servicio Web (la base de datos confía en el servicio Web). A su vez, el servicio Web realiza llamadas a la base de datos y transmite la identidad del usuario en la aplicación mediante parámetros de procedimientos almacenados.

Tabla 5.3: Medidas de seguridad

Paso

Más información

Autenticación

  • La aplicación Web autentica usuarios mediante la autenticación integrada de Windows desde IIS.

  • El servicio Web utiliza la autenticación integrada de Windows desde IIS. Autentica el contexto de seguridad del llamador original delegado por la aplicación Web.

  • El protocolo de autenticación Kerberos se utiliza para transmitir el contexto de seguridad del llamador original desde la aplicación Web al servicio Web mediante la delegación.

  • La autenticación de Windows se utiliza para establecer la conexión con la base de datos mediante la cuenta del proceso de ASP.NET

Autorización

  • La aplicación Web realiza comprobaciones de funciones con el llamador original para restringir el acceso a las páginas.

  • El acceso a los métodos del servicio Web se controla mediante el uso de funciones de .NET basadas en la pertenencia a grupos de Windows del llamador original.

Comunicación segura

  • Los datos confidenciales enviados entre los llamadores originales y la aplicación Web y el servicio Web se protegen con SSL.

  • Los datos confidenciales enviados entre el servicio Web y la base de datos se protegen con IPSec.

El resultado

La ilustración 5.6 muestra la configuración de seguridad recomendada para este escenario.

imagen

Ilustración 5.6
La configuración de seguridad recomendada para el escenario de intranet de ASP.NET y el servicio Web y SQL Server

Pasos para la configuración de la seguridad

Antes de empezar, conviene que consulte las siguientes referencias:

Configurar el servidor Web (que aloja la aplicación Web)

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Web
Habilitar la autenticación integrada de Windows para la raíz virtual de la aplicación Web

.

Configurar ASP.NET

Paso

Más información

Configurar la aplicación Web ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en el directorio virtual de la aplicación Web.Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Configurar la aplicación Web ASP.NET para la suplantación

Edite el archivo Web.config en el directorio virtual de la aplicación Web.Establezca el elemento <identity> en:

<identity impersonate="true" />

Configurar el servidor de aplicaciones (que aloja el servicio Web)

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual del servicio Web
Habilitar la autenticación integrada de Windows para el directorio raíz virtual del servicio Web

.

Configurar ASP.NET

Paso

Más información

Cambiar la contraseña de ASPNET a un valor conocido

ASPNET es una cuenta local con los mínimos privilegios que se utiliza de forma predeterminada para ejecutar las aplicaciones Web ASP.NET.

Establezca la contraseña de la cuenta ASPNET en un valor conocido mediante Usuarios locales y grupos.

Edite el archivo Machine.config que está ubicado en %windir%\Microsoft.NET\Framework\ v1.0.3705\CONFIG
y vuelva a configurar el atributo de contraseña en el elemento <processModel>:
Predeterminado

<!-- userName="machine" password="AutoGenerate" 
  -->

Se convierte en

<! -- UserName="machine" password="YourNewStrongPassword" 
  -->

Configurar el servicio Web ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en el directorio virtual del servicio Web.
Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Comprobar que está desactivada la suplantación

La suplantación está desactivada de forma predeterminada; no obstante, deberá comprobar que está desactivada en Web.config tal y como se muestra a continuación:

<identity impersonate="false" />

Observe que, al estar deshabilitada la suplantación de forma predeterminada, puede obtener el mismo resultado si quita el elemento <identity>.

Configurar SQL Server

Paso

Más información

Crear una cuenta de Windows en el equipo de SQL Server idéntica a la cuenta del proceso de ASP.NET que se utiliza para ejecutar el servicio Web

El nombre de usuario y la contraseña deben coincidir con los de la cuenta personalizada de ASP.NET.
Otorgue a la cuenta los siguientes privilegios:
- Tener acceso a este equipo desde la red
- Denegar el inicio de sesión localmente
- Iniciar sesión como trabajo por lotes

Configurar SQL Server para que utilice la autenticación de Windows

.

Crear un inicio de sesión de SQL Server para la cuenta personalizada de ASP.NET

Así se concede acceso a SQL Server.

Crear un nuevo usuario de base de datos y asignar el nombre de inicio de sesión al usuario de base de datos

Así se concede acceso a la base de datos especificada.

Crear una nueva función de usuario de base de datos y agregar el usuario de base de datos a la función

.

Establecer permisos de base de datos para la función de usuario de base de datos

Conceda los permisos mínimos.

Configurar la comunicación segura

Paso

Más información

Configurar el sitio Web en el servidor Web para que utilice SSL

Consulte "Cómo: Configurar SSL en un servidor Web" en la sección Referencia de esta guía.

Configurar IPSec entre el servidor Web y el servidor de bases de datos

Consulte "Cómo: Utilizar IPSec para proporcionar comunicación segura entre dos servidores" en la sección Referencia de esta guía.

Análisis

  • La autenticación integrada de Windows en IIS es ideal en este escenario porque todos los usuarios utilizan Windows 2000 o posterior, Internet Explorer 5.x o posterior y tienen cuentas en Active Directory, lo que permite utilizar el protocolo de autenticación Kerberos (que admite la delegación). De este modo, puede transmitir el contexto de seguridad del usuario a través de varios límites de equipos.

  • Las cuentas de usuario final NO deben estar marcadas como "Importante y no se puede delegar" en Active Directory. La cuenta del equipo del servidor Web debe estar marcada como "De confianza para la delegación" en Active Directory. Para obtener más información, consulte " Cómo: Implementar la delegación Kerberos en Windows 2000" en la sección Referencia de esta guía.

  • ASP.NET se ejecuta en el servidor Web y en el servidor de aplicaciones como una cuenta local con los mínimos privilegios (la cuenta ASPNET local), con lo que se reduce la posibilidad de que se comprometa la seguridad y se produzcan daños.

  • Tanto el servicio Web como la aplicación Web están configurados para utilizar la autenticación de Windows. IIS está configurado en ambos equipos para utilizar la autenticación integrada de Windows.

  • Al realizar una llamada al servicio Web desde la aplicación Web, no se transmiten ningunas credenciales de forma predeterminada. Son necesarias para responder al desafío de autenticación de red emitido por IIS en el servidor Web de nivel inferior. Deberá especificarlo de forma explícita mediante la configuración de la propiedad Credentials del proxy del servicio Web tal y como se muestra a continuación:

wsproxy.Credentials = CredentialCache.DefaultCredentials;

Para obtener más información acerca de cómo llamar a los servicios Web con credenciales, consulte el capítulo 10, "Seguridad de servicios Web".

  • La aplicación Web está configurada para la suplantación. De este modo, las llamadas desde la aplicación Web al servicio Web transmiten el contexto de seguridad del llamador original y permiten al servicio Web autenticar (y autorizar) el llamador original.

  • Las funciones de .NET se utilizan en el servicio Web para autorizar a los usuarios en función del grupo de Windows al que pertenecen (HRDept, PayrollDept y Employees). Los miembros de HRDept y PayrollDept pueden recuperar información de cualquier empleado, mientras que los miembros del grupo Employees sólo tienen autorización para recuperar su propia información.

Los métodos Web pueden anotarse con la clase PrincipalPermissionAttribute para solicitar la pertenencia a funciones específicas, tal y como se muestra en el siguiente ejemplo de código. Observe que se puede utilizar PrincipalPermission en lugar de PrincipalPermissionAttribute. Es una característica que comparten todos los tipos de atributo de .NET.

[WebMethod]
[PrincipalPermission(SecurityAction.Demand, 
                  Role=@"DomainName\HRDept)]
public DataSet RetrieveEmployeeDetails()
{
}

El atributo mostrado en el código anterior indica que sólo se permite llamar al método RetrieveEmployeeDetails a los miembros del grupo de Windows DomainName\HRDept (nombreDeDominio\DepRRHH). Si un usuario no miembro intenta llamar al método, se genera una excepción de seguridad.

  • La autorización de archivos de ASP.NET (en la aplicación Web y el servicio Web) realiza controles de ACL con el llamador para cualquier tipo de archivo que disponga de una asignación en la metabase de IIS que asigna el tipo de archivo a Aspnet_isapi.dll. Los tipos de archivo estáticos (como .jpg, .gif, .htm, etc.) que no disponen de una asignación ISAPI los comprueba IIS (mediante la ACL adjunta al archivo).

  • Puesto que la aplicación Web está configurada para la suplantación, los recursos a los que tenga acceso la propia aplicación deberán estar configurados con una ACL que conceda por lo menos acceso de lectura al llamador original.

  • El servicio Web no suplanta ni delega y, por lo tanto, obtiene acceso a los recursos del sistema local y a la base de datos mediante la identidad del proceso de ASP.NET. De este modo, todas las llamadas se realizan con la cuenta única del proceso. Esto permite el uso de la agrupación de conexiones de bases de datos. Si la base de datos no admite las delegaciones (como en SQL 7.0 y anteriores), este escenario constituye una buena opción.

  • Con la autenticación de Windows en SQL Server, no es necesario almacenar las credenciales en el servidor Web y las credenciales no se envían por la red al equipo de SQL Server.

  • El uso de SSL entre el llamador original y el servidor Web protege los datos transmitidos a la aplicación Web y desde ella.

  • El uso de IPSec entre el servidor Web de nivel inferior y la base de datos protege los datos transmitidos a la base de datos y desde ella.

Riesgos

  • El uso de una cuenta duplicada de Windows en el servidor de bases de datos (una cuenta idéntica a la cuenta del proceso de ASP.NET) facilita la administración. Deberán actualizarse y sincronizarse las contraseñas manualmente de forma periódica.

    Como alternativa, considere la posibilidad de utilizar cuentas de dominio con los mínimos privilegios. Para obtener más información acerca de cómo elegir una identidad del proceso de ASP.NET, consulte el capítulo 8, "Seguridad de ASP.NET".

  • Puesto que la seguridad basada en funciones de .NET está fundamentada en la pertenencia a grupos de Windows, esta solución depende de la configuración de los grupos de Windows con el nivel adecuado de granularidad correspondiente a las categorías de usuarios (que comparten los mismos privilegios de seguridad) que tendrán acceso a la aplicación.

  • La delegación Kerberos no tiene restricciones y, por lo tanto, deberá controlar con cuidado las identidades de aplicaciones que se ejecutan en el servidor Web. Para aumentar la seguridad, deberá limitar el ámbito del alcance de la cuenta de dominio; para ello, quite la cuenta del grupo Usuarios del dominio y proporcione acceso solamente desde los equipos apropiados. Para obtener más información, consulte las notas del producto "Default Access Control Settings" (en inglés).

Preguntas y respuestas

La base de datos desconoce quién es el llamador original. ¿Cómo puedo crear una pista de autoría?

Lleve a cabo la auditoría de usuarios finales en el servicio Web o transmita la identidad del usuario de forma explícita como parámetro de la llamada de acceso a datos.

Escenarios relacionados

Si necesita conectarse a bases de datos que no sean de SQL Server o utiliza la autenticación de SQL, deberá transmitir credenciales de cuentas de base de datos de forma explícita mediante la cadena de conexión. En ese caso, deberá asegurarse de almacenar la cadena de conexión de forma segura.

Para obtener más información, consulte " Almacenar cadenas de conexión de forma segura" en el capítulo 12, "Seguridad del acceso a datos".

ASP.NET y Remoting y SQL Server

En este escenario, un servidor Web que ejecuta páginas ASP.NET establece conexiones seguras a un componente remoto de un servidor de aplicaciones remoto. El servidor Web se comunica con el componente mediante .NET Remoting por el canal HTTP. El componente remoto está alojado en ASP.NET, tal y como se muestra en la ilustración 5.7.

imagen

Ilustración 5.7
ASP.NET y remoting mediante .NET Remoting y SQL Server

Características

  • Los usuarios tienen diversos tipos de explorador Web.

  • El componente remoto está alojado en ASP.NET.

  • La aplicación Web se comunica con el componente remoto mediante el canal HTTP.

  • La aplicación ASP.NET llama al componente remoto de .NET y transmite las credenciales del llamador original para la autenticación. La autenticación básica proporciona las credenciales.

  • Los datos son confidenciales y, por lo tanto, deben protegerse entre procesos y equipos.

Proteger el escenario

En este escenario, el servidor Web que aloja la aplicación Web ASP.NET autentica los llamadores originales. La aplicación Web puede recuperar las credenciales de autenticación del llamador (nombre de usuario y contraseña) de las variables del servidor HTTP. A continuación, puede utilizarlas para conectarse al servidor de aplicaciones que aloja el componente remoto mediante la configuración del proxy del componente remoto. La base de datos utiliza la autenticación de Windows para realizar la autenticación con la identidad del proceso de ASP.NET (es decir, la base de datos confía en el componente remoto). A su vez, el componente remoto llama a la base de datos y transmite la identidad del llamador original en la aplicación mediante parámetros de procedimientos almacenados.

Tabla 5.4: Medidas de seguridad

Categoría

Detalles

Autenticación

  • Autentique los usuarios mediante la autenticación básica desde IIS (además de SSL).

  • Utilice la autenticación de Windows desde el componente remoto (ASP.NET/IIS).

  • Utilice la autenticación de Windows para conectarse a la base de datos con una cuenta de ASP.NET con los mínimos privilegios.

Autorización

  • Utilice controles de ACL con el llamador original en el servidor Web.

  • Realice comprobaciones de funciones en el componente remoto con el llamador original.

  • Defina permisos de base de datos con la identidad de ASP.NET (componente remoto).

Comunicación segura

  • Proteja los datos confidenciales enviados entre los usuarios y la aplicación Web y los objetos remotos alojados en IIS mediante SSL.

  • Proteja los datos confidenciales enviados entre el servidor Web y la base de datos mediante IPSec.

El resultado

La ilustración 5.8 muestra la configuración de seguridad recomendada para este escenario

imagen

Ilustración 5.8
La configuración de seguridad recomendada para el escenario de intranet de ASP.NET y el servicio Web remoto y SQL Server

Pasos para la configuración de la seguridad

Configurar el servidor Web

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Web
Habilitar la autenticación básica

Utilice SSL para proteger las credenciales de autenticación básica

Configurar ASP.NET

Paso

Más información

Configurar la aplicación Web ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en la raíz del directorio virtual de la aplicación.

Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Configurar el servidor de aplicaciones

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Web
Habilitar la autenticación integrada de Windows

.

Configurar ASP.NET

Paso

Más información

Configurar el componente remoto (en ASP.NET) para que utilice la autenticación de Windows

Edite el archivo Web.config en la raíz del directorio virtual del componente remoto.

Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Cambiar la contraseña de ASPNET a un valor conocido

ASPNET es una cuenta local con los mínimos privilegios que se utiliza para ejecutar aplicaciones Web ASP.NET (y, en este caso, el proceso del host del componente remoto) de forma predeterminada.

Establezca la contraseña de la cuenta ASPNET en un valor conocido mediante Usuarios locales y grupos.
Edite el archivo Machine.config que está ubicado en %windir%\Microsoft.NET\Framework\ v1.0.3705\CONFIG
y vuelva a configurar el atributo de contraseña en el elemento <processModel>.

Predeterminado

<!-- userName="machine" password="AutoGenerate" 
        -->

Se convierte en

<!-- userName="machine" password="YourNewStrongPassword" 
        -->

Comprobar que está desactivada la suplantación

La suplantación está desactivada de forma predeterminada; no obstante, deberá comprobar que está desactivada en web.config tal y como se muestra a continuación:

<identity impersonate="false" />

También puede obtener el mismo resultado si quita el elemento <identity>.

Configurar SQL Server

Paso

Más información

Crear una cuenta de Windows en el equipo de SQL Server idéntica a la cuenta del proceso de ASP.NET que se utiliza para ejecutar el servicio Web

El nombre de usuario y la contraseña deben coincidir con los de la cuenta personalizada de ASP.NET.
Otorgue a la cuenta los siguientes privilegios:
- Tener acceso a este equipo desde la red
- Denegar el inicio de sesión localmente
- Iniciar sesión como trabajo por lotes

Configurar SQL Server para que utilice la autenticación de Windows

.

Crear un inicio de sesión de SQL Server para la cuenta personalizada de ASP.NET

Así se concede acceso a SQL Server.

Crear un nuevo usuario de base de datos y asignar el nombre de inicio de sesión al usuario de base de datos

Así se concede acceso a la base de datos especificada.

Crear una nueva función de usuario de base de datos y agregar el usuario de base de datos a la función

.

Establecer permisos de base de datos para la función de usuario de base de datos

Conceda los permisos mínimos.

Configurar la comunicación segura

Paso

Más información

Configurar el sitio Web en el servidor Web para que utilice SSL

Consulte "Cómo: Configurar SSL en un servidor Web" en la sección Referencia de esta guía.

Configurar el sitio Web en el servidor de aplicaciones para que utilice SSL

Consulte "Cómo: Configurar SSL en un servidor Web" en la sección Referencia de esta guía.

Configurar IPSec entre el servidor de aplicaciones y el servidor de bases de datos

Consulte "Cómo: Utilizar IPSec para proporcionar comunicación segura entre dos servidores" en la sección Referencia de esta guía.

Análisis

  • ASP.NET se ejecuta en el servidor Web y en el servidor de aplicaciones como una cuenta local con los mínimos privilegios, con lo que se reduce la posibilidad de que se comprometa la seguridad y se produzcan daños.
    Se utiliza la cuenta ASPNET predeterminada en ambos casos.

El uso de la cuenta local ASPNET (duplicada en el equipo de SQL Server) disminuye aún más los posibles riesgos de seguridad. Una cuenta de Windows duplicada en el servidor de bases de datos permite la ejecución del componente remoto con una cuenta de ASP.NET con los mínimos privilegios en el servidor de aplicaciones.

  • La autenticación básica en el servidor Web permite que la aplicación Web utilice las credenciales del usuario para responder a desafíos de autenticación de Windows desde el servidor de aplicaciones.

Para llamar al componente remoto con las credenciales del llamador, la aplicación Web configura el proxy del componente remoto tal y como se muestra en el siguiente fragmento de código.

string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
IDictionary channelProperties =  
                         ChannelServices.GetChannelSinkProperties(proxy);
NetworkCredential credentials;
credentials = new NetworkCredential(uid, pwd);
ObjRef objectReference = RemotingServices.Marshal(proxy);
Uri objectUri = new Uri(objectReference.URI);
CredentialCache credCache = new CredentialCache();
credCache.Add(objectUri, "Negotiate", credentials);
channelProperties["credentials"] = credCache;
channelProperties["preauthenticate"] = true;

Para obtener más información acerca de cómo transmitir credenciales de seguridad a un componente remoto, consulte el capítulo 11, " Seguridad de .NET Remoting".

  • La suplantación no está habilitada en la aplicación Web ASP.NET porque el proxy de remoting está configurado específicamente con las credenciales del usuario obtenidas mediante la autenticación básica. Cualquier otro recurso al que obtiene acceso la aplicación Web utiliza el contexto de seguridad proporcionado por la cuenta del proceso de ASP.NET.

  • El uso de SSL entre el usuario y el servidor Web protege los datos transmitidos al servidor Web y desde él y, además, las credenciales básicas transmitidas como texto no cifrado durante el proceso de autenticación.

  • La autenticación integrada de Windows en el servidor de aplicaciones realiza comprobaciones de funciones de .NET con el llamador original.
    Las funciones corresponden a grupos de Windows.
    Las comprobaciones basadas en funciones pueden realizarse incluso sin la suplantación.

  • La autorización de archivos de ASP.NET realiza controles de ACL con el llamador para cualquier tipo de archivo que disponga de una asignación en la metabase de IIS que asigne el tipo de archivo a aspnet_isapi.dll. IIS realiza controles de acceso para archivos estáticos (no asignados a una extensión ISAPI en IIS).

  • Puesto que la suplantación no está habilitada en el servidor de aplicaciones, todo acceso a recursos locales o remotos por parte del componente remoto se realiza con el contexto de seguridad de ASPNET. Deberán configurarse las ACL de forma adecuada.

  • Con la autenticación de Windows en SQL Server, no es necesario almacenar las credenciales en el servidor de aplicaciones y las credenciales no se envían por la red al equipo de SQL Server.

Riesgos

  • El uso de una cuenta duplicada de Windows en el servidor de bases de datos (una cuenta idéntica a la cuenta del proceso de ASP.NET) facilita la administración. Deberán actualizarse y sincronizarse las contraseñas manualmente de forma periódica.

  • Puesto que la seguridad basada en funciones de .NET está fundamentada en la pertenencia a grupos de Windows, esta solución depende de la configuración de los grupos de Windows con el nivel adecuado de granularidad correspondiente a las categorías de usuarios (que comparten los mismos privilegios de seguridad) que tendrán acceso a la aplicación.

Escenarios relacionados

El servidor Web utiliza Kerberos para autenticar llamadores. La delegación Kerberos se utiliza para transmitir el contexto de seguridad del llamador original al componente remoto en el servidor de aplicaciones.

Este enfoque requiere que todas las cuentas de usuario estén configuradas para la delegación. La aplicación Web también estaría configurada para la suplantación y utilizaría DefaultCredentials para configurar el proxy del componente remoto. Esta técnica se explica en mayor detalle en la sección "Transmitir el llamador original" del capítulo 11, "Seguridad de .NET Remoting".

Transmitir el llamador original a la base de datos

Los escenarios expuestos anteriormente han utilizado el modelo de subsistemas de confianza y la base de datos siempre ha confiado en el servidor de aplicaciones o en el servidor Web para la autenticación y autorización correctas de los usuarios. Aunque el modelo de subsistemas de confianza ofrece muchas ventajas, puede que algunos escenarios (quizás por motivos de auditoría) requieran que utilice el modelo de suplantación/delegación y que transmita el contexto de seguridad del llamador original a través de límites de equipos hasta la base de datos.

Entre las razones por las que puede necesitar transmitir el llamador original a la base de datos, figuran:

  • Necesita acceso granular en la base de datos y los permisos están restringidos por objeto. Algunos usuarios o grupos tienen permiso de lectura, mientras que otros tienen permiso de escritura para determinados objetos. Se contrapone a la autorización menos granular basada en tareas, en la que la pertenencia a funciones determina las capacidades de lectura y escritura de objetos específicos.

  • Puede que desee utilizar las capacidades de auditoría de la plataforma, en lugar de transmitir la identidad y realizar la auditoría en la aplicación.

Si decide usar un modelo de suplantación/delegación (o debe utilizarlo debido a la directiva de seguridad corporativa) y transmite el contexto del llamador original por los niveles de la aplicación hasta el servidor, deberá tener en cuenta la delegación y el acceso a la red en el diseño (puesto que son importantes cuando existen varios equipos). La agrupación de recursos compartidos (como las conexiones de bases de datos) también se convierte en un factor clave y puede disminuir considerablemente la escalabilidad de la aplicación.

Esta sección explica cómo implementar la suplantación/delegación para dos de los escenarios de aplicaciones más habituales:

  • ASP.NET y SQL Server

  • ASP.NET y Servicios Empresariales y SQL Server

Para obtener más información acerca de los modelos de subsistemas de confianza y de suplantación/delegación y de sus ventajas, consulte el capítulo 3, " Autenticación y autorización".

ASP.NET y SQL Server

En este escenario, las llamadas a la base de datos se realizan mediante el contexto de seguridad del llamador original. Entre las opciones de autenticación descritas en esta sección, figuran la autenticación básica y la autenticación integrada de Windows. En la sección "ASP.NET y Servicios Empresariales y SQL Server", se describe un escenario de delegación Kerberos.

Utilizar la autenticación básica en el servidor Web

Las siguientes opciones de configuración de la autenticación básica le permiten transmitir el llamador original hasta la base de datos.

Tabla 5.5: Medidas de seguridad

Categoría

Detalles

Autenticación

  • Autentique los usuarios mediante la autenticación básica desde IIS.

  • Utilice la autenticación de Windows en ASP.NET.

  • Active la suplantación en ASP.NET.

  • Utilice la autenticación de Windows para comunicarse con SQL Server.

Autorización

  • Utilice controles de ACL con el llamador original en el servidor Web.

  • Si los llamadores originales están asignados a grupos de Windows (en función de los requisitos de aplicaciones, como por ejemplo, Directores, Cajeros, etc.), puede utilizar comprobaciones de funciones de .NET con el llamador original para restringir el acceso a los métodos.

Comunicación segura

  • Proteja las credenciales de texto no cifrado enviadas entre el servidor Web y la base de datos mediante SSL.

  • Utilice IPSec para proteger todos los datos confidenciales enviados entre la aplicación Web y la base de datos.

En este enfoque, es importante tener en cuenta los siguientes aspectos:

  • La autenticación básica solicita información al usuario con un cuadro de diálogo emergente en el que puede escribir credenciales (nombre de usuario y contraseña).

  • La base de datos debe reconocer al llamador original. Si el servidor Web y la base de datos se encuentran en dominios distintos, deberán habilitarse las relaciones de confianza correspondientes para permitir la autenticación del llamador original.

Utilizar la autenticación integrada de Windows en el servidor Web

La autenticación integrada de Windows utiliza autenticación NTLM o Kerberos y depende de la configuración de los equipos cliente y servidor. La autenticación NTLM no admite la delegación y, por lo tanto, no permite transmitir el contexto de seguridad del llamador original desde el servidor Web a una base de datos situada en una ubicación remota. El único salto de red que se permite en la autenticación NTLM se utiliza entre el explorador y el servidor Web. Para utilizar la autenticación NTLM, deberá estar instalado SQL Server en el servidor Web, lo que suele ser apropiado solamente para aplicaciones de intranet de pequeño tamaño.

ASP.NET y Servicios Empresariales y SQL Server

En este escenario, las páginas ASP.NET llaman a componentes empresariales alojados en una aplicación remota de Servicios Empresariales que, a su vez, se comunica con una base de datos. El contexto de seguridad del llamador original se transmite desde el explorador hasta la base de datos. Este escenario se muestra en la ilustración 5.9.

imagen

Ilustración 5.9
ASP.NET llama a un componente de Servicios Empresariales que, a su vez, llama a la base de datos.

Características

  • Los usuarios tienen Internet Explorer 5.x o posterior.

  • Todos los equipos ejecutan Windows 2000 o posterior.

  • Las cuentas de usuario se mantienen en un único bosque de Active Directory.

  • La aplicación transmite el contexto de seguridad del llamador original (en el sistema operativo) hasta la base de datos.

  • Todos los niveles utilizan la autenticación de Windows.

  • Las cuentas de usuarios del dominio están configuradas para la delegación y la cuenta utilizada para ejecutar la aplicación de Servicios Empresariales deberá estar marcada como "De confianza para la delegación" en Active Directory.

Proteger el escenario

En este escenario, el servidor Web autentica el llamador. A continuación, deberá configurar ASP.NET para la suplantación con el fin de transmitir el contexto de seguridad del llamador original a la aplicación remota de Servicios Empresariales. En la aplicación de Servicios Empresariales, el código de componente deberá suplantar de forma explícita al llamador (mediante CoImpersonateClient) para garantizar la transmisión del contexto del llamador a la base de datos.

Tabla 5.6: Medidas de seguridad

Categoría

Detalles

Autenticación

  • Todos los niveles admiten la autenticación Kerberos (el servidor Web, el servidor de aplicaciones y el servidor de bases de datos).

Autorización

  • Las comprobaciones de autorización se realizan en el nivel medio mediante funciones de Servicios Empresariales (COM+) con la identidad del llamador original.

Comunicación segura

  • Se utiliza SSL entre el explorador y el servidor Web para proteger los datos confidenciales.

  • La Privacidad de paquete RPC (que proporciona el cifrado) se utiliza entre ASP.NET y los componentes revisados en la aplicación remota de Servicios Empresariales.

  • IPSec se utiliza entre los componentes revisados y la base de datos.

El resultado

La ilustración 5.10 muestra la configuración de seguridad recomendada para este escenario.

imagen

Ilustración 5.10
ASP.NET llama a un componente de Servicios Empresariales que, a su vez, llama a la base de datos. El contexto de seguridad del llamador original se transmite a la base de datos.

Pasos para la configuración de la seguridad

Antes de empezar, deberá estar al tanto de los siguientes problemas de configuración:

  • La cuenta del proceso de Servicios Empresariales debe estar marcada como "De confianza para la delegación" en Active Directory y las cuentas de usuario final no deberán estar marcadas como "Importante y no se puede delegar". Para obtener más información, consulte "Cómo: Implementar la delegación Kerberos en Windows 2000" en la sección Referencia de esta guía.

  • Se requiere Windows 2000 o posterior en todos los equipos. Incluye los equipos cliente (explorador) y todos los servidores.

  • Todos los equipos deben estar en Active Directory y formar parte de un único bosque.

  • El servidor de aplicaciones que aloja Servicios Empresariales debe ejecutar Windows 2000 SP3.

  • Si utiliza Internet Explorer 6.0 en Windows 2000, éste utiliza la autenticación NTLM de forma predeterminada en lugar de la autenticación Kerberos requerida. Para habilitar la delegación Kerberos, consulte el artículo Q299838, "Can't Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6" (en inglés), en Microsoft Knowledge Base.

Configurar el servidor Web (IIS)

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Web
Habilitar la autenticación integrada de Windows

.

Configurar el servidor Web (ASP.NET)

Paso

Más información

Configurar la aplicación Web ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en la raíz del directorio virtual de la aplicación Web.

Establezca el elemento <authentication> en:

<authentication 
        mode="Windows" />

Configurar la aplicación Web ASP.NET para la suplantación

Edite el archivo Web.config en el directorio virtual de la aplicación Web.

Establezca el elemento <identity> en:

<identity impersonate="true"/>

Configure el nivel de suplantación de DCOM utilizado por la aplicación Web ASP.NET para las llamadas salientes

La aplicación Web ASP.NET llama a los componentes revisados remotos a través de DCOM. El nivel de suplantación predeterminado que se utiliza para las llamadas salientes desde ASP.NET es Impersonate (suplantar). Deberá cambiarse a Delegate (delegar) en Machine.config.
Edite Machine.config, busque el elemento <processModel> y establezca el atributo comImpersonateLevel en "Delegate", tal y como se muestra a continuación.

<processModel comImpersonationLevel="Delegate"

Configurar el nivel de autenticación de DCOM en el cliente

Los niveles de autenticación de DCOM están determinados tanto por el cliente como por el servidor. En este caso, el cliente DCOM es ASP.NET.

Edite Machine.config, busque el elemento <processModel> y establezca el atributo comAuthenitcationLevel en "PktPrivacy", tal y como se muestra a continuación.

<processModel comAuthenticationLevel="PktPrivacy"

Configurar los componentes revisados (y el servidor de aplicaciones)

Paso

Más información

La clase o clases administradas deben heredar de la clase ServicedComponent.

Consulte el artículo Q306296, "HOW TO: Create a Serviced .NET Component in Visual C# .NET" (en inglés), en Microsoft Knowledge Base

Configurar la aplicación de Servicios Empresariales como aplicación de servidor

Agregue referencias a OLE32.DLL:

class COMSec
        {
        [DllImport("OLE32.DLL", CharSet=CharSet.Auto)]
        public static extern long CoImpersonateClient();
      [DllImport("OLE32.DLL", CharSet=CharSet.Auto)]
        public static extern long CoRevertToSelf();
        }

Llame a estas funciones externas antes de llamar a recursos remotos:

COMSec.CoImpersonateClient();
        COMSec.CoRevertToSelf();

Para obtener más información, consulte el capítulo 9, "Seguridad de la aplicación de Servicios Empresariales".

Configurar la aplicación de Servicios Empresariales para que utilice la autenticación de privacidad de paquete (para proporcionar comunicación segura con cifrado)

Agregue el siguiente atributo de .NET al ensamblado de componentes revisados.

[assembly: ApplicationAccessControl(
        Authentication = 
        AuthenticationOption.Privacy)]

Configurar la aplicación de Servicios Empresariales para que utilice la seguridad basada en funciones en el componente

Para configurar las comprobaciones de funciones en el proceso y en el componente (incluidas las interfaces y las clases), utilice el siguiente atributo:

[assembly: ApplicationAccessControl(AccessChecksLevel= 
        AccessChecksLevelOption. ApplicationComponent)]

Agregue el siguiente atributo a las clases:

[ComponentAccessControl(true)]

Para obtener más información acerca de cómo configurar las comprobaciones de funciones de interfaz y de método, consulte "Configurar la seguridad" en el capítulo 9, "Seguridad de la aplicación de Servicios Empresariales".

Crear una cuenta personalizada para ejecutar Servicios Empresariales y marcarla como "De confianza para la delegación" en Active Directory

La aplicación de Servicios Empresariales necesita ejecutarse como cuenta de dominio marcada como "De confianza para la delegación" en Active Directory. Para obtener más información, consulte "Cómo: Implementar la delegación Kerberos en Windows 2000" en la sección Referencia de esta guía

Configurar Servicios Empresariales para que se ejecute como la cuenta personalizada

Puede utilizar la herramienta Servicios de componente o una secuencia de comandos para la configuración. No se pueden utilizar atributos de .NET en el ensamblado de componentes revisados.

Configurar el servidor de bases de datos (SQL Server)

Paso

Más información

Configurar SQL Server para que utilice la autenticación de Windows

.

Crear inicios de sesión de SQL Server para los grupos de Windows a los que pertenecen los usuarios

Así se concede acceso a SQL Server.
La directiva de control de acceso trata los grupos de Windows como funciones. Por ejemplo, podría tener grupos como Employees, HRDept y PayrollDept.

Crear nuevos usuarios de base de datos para cada inicio de sesión de SQL Server

.

Establecer permisos de base de datos para los usuarios de la base de datos

Conceda los permisos mínimos.
Para obtener más información, consulte el capítulo 12, "Seguridad del acceso a datos".

Análisis

  • La clave de la transmisión del contexto de seguridad del llamador original es la autenticación Kerberos, que genera un testigo de delegación. Una vez que el proceso del servidor (IIS) recibe el testigo de delegación, puede ejecutarse como cualquiera de las cuentas del mismo equipo para transmitirlo a cualquier otro proceso sin cambiar su nivel de delegación. No tiene importancia que el proceso de trabajo se ejecute como cuenta local o como cuenta de dominio. Sí que es importante saber cómo se ejecuta IIS. Si no se ejecuta como LocalSystem, la cuenta con la que se ejecuta deberá marcarse como "De confianza para la delegación" en Active Directory.

Si se ejecuta como LocalSystem, la cuenta del equipo deberá estar marcada como "De confianza para la delegación". Para obtener más información, consulte " Cómo: Implementar la delegación Kerberos en Windows 2000" en la sección Referencia de esta guía.

  • La autenticación integrada de Windows (con Kerberos) en IIS es ideal para este escenario porque todos los usuarios tienen cuentas de Windows y utilizan Internet Explorer 5.x o posterior. La ventaja de la autenticación integrada de Windows reside en que la contraseña del usuario nunca se envía por la red. Además, el inicio de sesión será transparente porque Windows utiliza la sesión de inicio interactiva actual del usuario.

  • ASP.NET crea un objeto WindowsPrincipal y lo adjunta al contexto de la petición Web actual (HttpContext.User). Si necesita realizar comprobaciones de autorización en la aplicación Web, puede utilizar el siguiente código:

    WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
    if ( wp.IsInRole("Manager") )
    {
      // User is authorized to perform manager-specific functionality
    }
    

FileAuthorizationModule de ASP.NET realiza controles de ACL con el llamador original para tipos de archivo de ASP.NET que están asignados a Aspnet_isapi.dll en IIS. En el caso de tipos de archivo estáticos, como .jpg, .gif y .htm, IIS actúa de guardián y realiza controles de acceso con la identidad del llamador original.

  • Con la autenticación de Windows en SQL Server, no es necesario almacenar las credenciales en archivos del servidor de aplicaciones y las credenciales no se transmiten por la red Por ejemplo, incluya el atributo Trusted_Connection en la cadena de conexión:

    ConStr="server=YourServer; database=yourdatabase; Trusted_Connection=Yes;”
    
  • El contexto del llamador original se transmite por todos los niveles, lo que facilita considerablemente la auditoría. Puede utilizar la auditoría de la plataforma (por ejemplo, las características de auditoría proporcionadas por Windows y SQL Server).

Riesgos

  • Si utiliza Internet Explorer 6.0 en Windows 2000, el mecanismo predeterminado de autenticación que se negocia es NTLM (y no Kerberos). Para obtener más información, consulte el artículo Q299838, "Can't Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6" (en inglés), en Microsoft Knowledge Base.

  • Comparada con el modelo de subsistemas de confianza, la delegación de usuarios en los niveles resulta costosa en cuanto al rendimiento y a la escalabilidad de la aplicación. No puede utilizar la agrupación de conexiones de la base de datos, puesto que las conexiones de la base de datos están vinculadas al contexto de seguridad del llamador original y, por lo tanto, no se pueden agrupar de forma eficaz.

  • Este enfoque también depende de que la granularidad de los grupos de Windows satisfaga las necesidades de seguridad de la aplicación. En otras palabras, los grupos de Windows deberán configurarse con el nivel correcto de granularidad correspondiente a las categorías de usuarios (que comparten los mismos privilegios de seguridad) que obtienen acceso a la aplicación.

Conclusión

En este capítulo, se ha explicado cómo proteger varios escenarios de aplicaciones de intranet habituales.

Para obtener información acerca de los escenarios de aplicaciones de extranet e Internet, consulte el capítulo 6, "Seguridad de extranet", y el capítulo 7, " Seguridad de Internet".

Mostrar:
© 2014 Microsoft