Exportar (0) Imprimir
Expandir todo

Capítulo 9: Seguridad de la aplicación de Servicios Empresariales

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: En este capítulo se explica cómo asegurar la funcionalidad empresarial en los componentes revisados contenidos en las aplicaciones de Servicios Empresariales. Se muestra cómo y cuándo utilizar las funciones de Servicios Empresariales (COM+) para la autorización y cómo configurar la autenticación y la suplantación RPC. También se muestra cómo llamar de forma segura a los componentes revisados desde una aplicación Web ASP.NET y cómo identificar y transmitir el contexto de seguridad del llamador original a través del componente revisado de nivel medio.

Los componentes .NET incluyen los servicios COM+ tradicionales, como las transacciones distribuidas, la activación instantánea, la agrupación de objetos y la administración simultánea. En .NET, dichos servicios se denominan Servicios Empresariales. Resultan imprescindibles para muchos de los componentes .NET de nivel medio que se ejecutan con aplicaciones Web de .NET.

Para agregar servicios a un componente .NET es preciso derivar la clase de componente de la clase básica EnterpriseServices.ServicedComponent y especificar a continuación los requisitos de servicio correspondientes mediante atributos .NET compilados en el ensamblado que aloja el componente.

En este capítulo se describe la creación de componentes revisados seguros y los procesos de llamada de los mismos desde las aplicaciones Web de ASP.NET.

En esta página

Arquitectura de seguridad Arquitectura de seguridad
Configurar la seguridad Configurar la seguridad
Crear y asignar funciones Crear y asignar funciones
Programar la seguridad Programar la seguridad
Seleccionar una identidad de proceso Seleccionar una identidad de proceso
Obtener acceso a recursos de red Obtener acceso a recursos de red
Transferir el llamador original Transferir el llamador original
Cifrado RPC Cifrado RPC
Crear componentes revisados Crear componentes revisados
DCOM y servidores de seguridad DCOM y servidores de seguridad
Llamar a componentes revisados desde ASP.NET Llamar a componentes revisados desde ASP.NET
Conceptos de seguridad Conceptos de seguridad
Resumen Resumen

Arquitectura de seguridad

La ilustración 9.1 muestra un compendio de las funciones de autenticación, autorización y comunicación segura compatibles con las aplicaciones de Servicios Empresariales. La aplicación cliente de la ilustración 9.1 es una aplicación Web de ASP.NET.

imagen

Ilustración 9.1
Arquitectura de seguridad basada en funciones de Servicios Empresariales

Observe que las funciones de autenticación y comunicación segura las proporciona el transporte RPC subyacente que utiliza el modelo COM Distribuido (DCOM). La autorización se obtiene mediante las funciones de Servicios Empresariales (COM+).

A continuación se resumen los elementos principales de la arquitectura de seguridad de Servicios Empresariales:

  • Las aplicaciones de Servicios Empresariales utilizan la autenticación RPC para autenticar a los llamadores. Esta estrategia significa que, salvo que se lleven a cabo pasos específicos para deshabilitar la autenticación, el llamador recibe la autenticación mediante Kerberos o NTLM.

  • La autorización se ejecuta gracias a las funciones de Servicios Empresariales (COM+), que pueden incluir cuentas de grupo o usuario del sistema operativo Microsoft® Windows®. La pertenencia a funciones se define en el catálogo COM+ y se administra mediante la herramienta Servicios de componente.

Nota

Si la aplicación de Servicios Empresariales utiliza la suplantación, también estará disponible la autorización del llamador mediante listas ACL de Windows de los recursos protegidos.

  • Cuando un cliente (por ejemplo, una aplicación Web de ASP.NET) llama a un método de un componente revisado, una vez completado el proceso de autenticación, el nivel de intercepción de Servicios Empresariales obtendrá acceso al catálogo COM+ para determinar la pertenencia a la función del cliente. A continuación comprobará si la pertenencia de la función o las funciones permite el acceso autorizado a la aplicación, el componente, la interfaz y el método actuales.

  • Si la pertenencia a la función del cliente permite el acceso, se llamará al método. Si el cliente no pertenece a una función adecuada, se rechazará la llamada y, a modo opcional, es posible que se genere un evento de seguridad para reflejar el intento de acceso erróneo.

Nota

Para implementar una autorización basada en funciones, coherente en una aplicación de Servicios Empresariales llamada por una aplicación Web de ASP.NET, es preciso utilizar la autenticación de Windows con suplantación en la citada aplicación Web de ASP.NET a fin de garantizar que el contexto de seguridad del llamador original se transmita a través del componente revisado.

  • Para proteger el enlace de comunicación DCOM entre las aplicaciones cliente y servidor debe utilizarse el nivel de autenticación de integridad del paquete RPC (para garantizar la integridad de los mensajes) o el nivel de autenticación de privacidad del paquete RPC (para garantizar la confidencialidad de los mensajes).

Equipos selectores y puertas de enlace

El tiempo de ejecución de Servicios Empresariales actúa como equipo selector de los componentes revisados. La ilustración 9.2 muestra cada una de las puertas de enlace (puntos de autorización) de una aplicación de Servicios Empresariales. Dichas puertas de enlace deben configurarse mediante las funciones de Servicios Empresariales, que deben llenarse con las cuentas de grupo y usuario de Windows correspondientes.

Es importante asegurarse de que esté habilitada la comprobación de acceso (seguridad basada en funciones) para la aplicación de Servicios Empresariales y que se utilice el nivel de autenticación adecuado. Si desea obtener más información acerca de cómo configurar la seguridad, consulte la sección "Configurar la seguridad" que figura más adelante en este mismo capítulo.

imagen

Ilustración 9.2
Equipos selectores de una aplicación de Servicios Empresariales

Como respuesta al envío de una llamada de método para un componente revisado por parte de un cliente se llevan a cabo tres comprobaciones de acceso distintas. Las tres están reflejadas en la ilustración 9.2, además de describirse a continuación:

  1. Se lleva a cabo una comprobación de acceso inicial por parte del subsistema responsable de activar las aplicaciones de Servicios Empresariales (Administrador de control de servicios COM, SCM) cuando una llamada a un componente revisado da lugar a una solicitud de activación (y a la creación de una nueva instancia del proceso suplente COM+, Dllhost.exe).

    Para superar correctamente esta comprobación de acceso, el llamador debe ser miembro como mínimo de una función definida en la aplicación.

  2. Se realiza una segunda comprobación de acceso cuando la llamada del cliente entra en la instancia de proceso Dllhost.exe.

    De nuevo, es preciso que el llamador sea miembro de una función definida en la aplicación, como mínimo, para superar esta comprobación.

  3. La comprobación de acceso última se efectúa cuando la llamada del cliente entra en una aplicación de servidor o de biblioteca.

    Para superar correctamente esta comprobación es necesario que el llamador sea miembro de una función asociada con la interfaz, la clase o el método de destino de la llamada del cliente.

Nota

Después de que una llamada haya invocado un método de un componente revisado, no se producen comprobaciones de acceso adicionales si el componente se comunica con otros componentes ubicados en la misma aplicación. No obstante, sí que se llevarán a cabo otras comprobaciones de acceso si un componente llama a otro componente de una aplicación distinta (de biblioteca o servidor).

Utilizar aplicaciones de servidor para aumentar la seguridad

Debe utilizarse una aplicación de servidor en aquellos casos en los que una aplicación exige aplicar un nivel de autenticación determinado porque requiere el cifrado para garantizar la confidencialidad de los datos enviados a un componente revisado y forzar las comprobaciones durante las transferencias a través de la red.

Las aplicaciones de servidor permiten la aplicación de niveles de autenticación, mientras que las aplicaciones de biblioteca heredan el nivel de autenticación del proceso host.

Para configurar el tipo de activación de una aplicación de Servicios Empresariales, utilice el atributo ApplicationActivation del nivel de ensamblado como se indica a continuación.

[assembly: ApplicationActivation(ActivationOption.Server)]

O lo que es lo mismo, establezca el Tipo de activación en Aplicación de servidor desde la página Activación del cuadro de diálogo Propiedades de la aplicación de Servicios de componente.

Seguridad para las aplicaciones de servidor y biblioteca

La seguridad basada en funciones funciona de modo similar tanto para las aplicaciones de biblioteca en proceso como para las aplicaciones de servidor fuera de proceso.

Cabe considerar las siguientes diferencias relativas a las aplicaciones de biblioteca:

  • Privilegios. Los privilegios de una aplicación de biblioteca vienen determinados por los privilegios del proceso (host) del cliente. Por ejemplo, si el proceso de cliente se ejecuta con privilegios de administrador, la aplicación de biblioteca también dispondrá de privilegios de administrador.

  • Suplantación. El nivel de suplantación de una aplicación de biblioteca se hereda del proceso de cliente y no puede configurarse explícitamente.

  • Autenticación. El nivel de autenticación de una aplicación de biblioteca se hereda del proceso de cliente. En cambio, las aplicaciones de biblioteca permiten habilitar o deshabilitar de forma explícita la autenticación. Esta opción está disponible desde la página Seguridad del cuadro de diálogo Propiedades de la aplicación de biblioteca.

Esta opción suele utilizarse para admitir las devoluciones de llamadas autenticadas de otros componentes COM fuera de proceso.

Asignar funciones a clases, interfaces o métodos

El empleo de las aplicaciones de biblioteca obliga a asignar funciones al nivel de clases, interfaz o métodos. También es una práctica recomendada para las aplicaciones de servidor.

Los usuarios definidos en las funciones de una aplicación de biblioteca no pueden agregarse al descriptor de seguridad del proceso de cliente. Esto significa que es preciso utilizar una seguridad de nivel de clases para que la aplicación de biblioteca pueda llevar a cabo la autorización basada en funciones.

Requisitos de la seguridad de acceso al código

La seguridad de acceso al código (CAS) requiere que el código cuente con una serie de permisos específicos a fin de ejecutar determinadas operaciones y obtener acceso a recursos restringidos. CAS en un entorno de cliente muy útil en el que el código se descarga de Internet. Por este mismo motivo, es difícil que el código sea de plena confianza.

Por lo general, las aplicaciones que utilizan componentes revisados son de confianza, por lo que se ve limitado el uso de CAS. No obstante, Servicios Empresariales no exige que el código llamador disponga de los permisos necesarios para llamar al código no administrado. Dado este contexto, es importante tener en cuenta las siguientes consideraciones:

  • Se necesita permiso para el código no administrado para activar y realizar llamadas de contexto entre varios componentes revisados.

  • Si el cliente de un componente revisado es una aplicación Web de ASP.NET, dicha aplicación debe tener permiso de código no administrado.

  • Si una referencia a un componente revisado se pasa como argumento a algún método de código no seguro, los métodos definidos en el componente revisado no podrán usarse desde el código no seguro.

Configurar la seguridad

En esta sección se describe cómo configurar la seguridad de:

  • Un componente revisado que se ejecuta en una aplicación de servidor de Servicios Empresariales (fuera de proceso).

  • Un cliente de aplicación Web de ASP.NET.

Configurar una aplicación de servidor

La ilustración 9.3 esboza los pasos necesarios para configurar una aplicación de servidor de Servicios Empresariales.

imagen

Ilustración 9.3
Configurar la seguridad de Servicios Empresariales

Tiempo de desarrollo y configuración del tiempo de implementación

La mayoría de los parámetros del catálogo COM+ se pueden configurar durante el tiempo de desarrollo mediante los atributos .NET del ensamblado que contiene el componente revisado. Estos atributos se utilizan para llenar el catálogo COM+ cuando el componente revisado se ha registrado en COM+ mediante la herramienta Regsvcs.exe.

Otros pasos de configuración, como el llenado de las funciones con cuentas de grupo y usuario de Windows y la configuración de una identidad “ejecutar como” para la aplicación de servidor (instancia Dllhost.exe), deben configurarse mediante la herramienta de administración Servicios de componente (o mediante programación con una secuencia de comandos) durante el tiempo de implementación.

Configurar la autenticación

Para configurar el nivel de autenticación de una aplicación mediante declaraciones, utilice el atributo de nivel de ensamblado ApplicationAccessControl como se indica a continuación.

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

O lo que es lo mismo, establezca el valor de Nivel de autenticación para llamadas de la página Seguridad del cuadro de diálogo Propiedades de la aplicación de Servicios de componente.

Nota

El nivel de autenticación del cliente también incide en el nivel de autenticación que utilizará la aplicación de Servicios Empresariales, puesto que se emplea un proceso de negociación de marca de agua elevado, que siempre selecciona el mayor de los dos parámetros utilizados.

Si desea obtener más información acerca de cómo configurar el nivel de autenticación DCOM que utiliza la aplicación cliente de ASP.NET, consulte la sección "Configurar una aplicación cliente ASP.NET" que figura más adelante.

Para obtener más información acerca de los niveles de autenticación DCOM y la negociación del nivel de autenticación, consulte la sección "Conceptos de seguridad" de este mismo capítulo.

Configurar la autorización (comprobaciones de acceso para componentes)

Para habilitar la autorización de granularidad fina en el nivel de componentes, interfaces o métodos:

  • Habilite las comprobaciones de acceso para el nivel de aplicación.

Utilice el siguiente atributo .NET para habilitar las comprobaciones de acceso en toda la aplicación.

[assembly: ApplicationAccessControl(true)]

O lo que es lo mismo, active la casilla de verificación Aplicar comprobaciones de acceso para esta aplicación de la página Seguridad del cuadro de diálogo Propiedades de la aplicación de Servicios de componente.

Nota

Si no puede configurar este atributo, no se llevará a cabo ninguna comprobación de acceso

  • Configure el nivel de seguridad de la aplicación en el nivel de proceso y componentes.

Para que la seguridad basada en funciones sea coherente, habilite la comprobación de acceso para los niveles de proceso y componentes mediante el siguiente atributo .NET:

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

O lo que es lo mismo, active la casilla de verificación Ejecutar comprobaciones de acceso para procesos y componentes de la página Seguridad del cuadro de diálogo Propiedades de la aplicación de Servicios de componente.

Nota

Habilite siempre la comprobación de acceso para los niveles de proceso y componente en las aplicaciones de biblioteca.

  • Habilitar la comprobación de acceso para el nivel de componentes.

Para habilitar las comprobaciones de acceso para el nivel de componentes, utilice el atributo de nivel de clase ComponentAccessControl como se indica a continuación.

[ComponentAccessControl(true)]
public class MyServicedComponent : ServicedComponent
{
}

O lo que es lo mismo, active la casilla de verificación Aplicar comprobaciones de acceso para componentes de la página Seguridad del cuadro de diálogo Propiedades de la aplicación de Servicios de componente.

Nota

Esta configuración resulta efectiva sólo si se ha habilitado la comprobación de acceso para el nivel de la aplicación y se han configurado las comprobaciones de acceso para los niveles de proceso y componentes, tal como se ha descrito anteriormente.

Crear y asignar funciones

Las funciones pueden crearse y asignarse para los niveles de aplicación, componentes (clase), interfaz y método.

Agregar funciones a una aplicación

Para agregar funciones a una aplicación, utilice el atributo de nivel de ensamblado SecurityRole como se muestra a continuación.

[assembly:SecurityRole("Employee")]
[assembly:SecurityRole("Manager")]

Este proceso es equivalente a agregar funciones a una aplicación mediante la herramienta Servicios de componente.

Nota

El empleo del atributo SecurityRole en el nivel de ensamblado es equivalente a agregar funciones a la aplicación, pero sin asignarlas a los componentes, interfaces o métodos individuales. El resultado no es otro que la determinación por parte de los miembros de estas funciones de la composición del descriptor de seguridad adjunto a la aplicación. Dicho descriptor se utiliza única y exclusivamente para determinar los usuarios que tendrán acceso a la aplicación (y podrán iniciarla).

Si desea que la autorización basada en funciones sea aún más eficaz, aplique siempre funciones a los componentes, interfaces y métodos tal como se describe más adelante.

Agregar funciones a un componente (clase)

Para agregar funciones a una aplicación, aplique el atributo SecurityRole antes de la definición de clase, como se muestra a continuación.

[SecurityRole("Manager")]
public class Transfer : ServicedComponent
{
}

Agregar funciones a una interfaz

Para aplicar funciones en el nivel de interfaz es preciso crear una definición de interfaz e implementarla a continuación en la clase del componente revisado. Después, puede asociar funcionar con la interfaz mediante el atributo SecurityRole.

Nota

Durante el tiempo de desarrollo también debe anotar la clase con el atributo SecureMethod. De este modo se informa a Servicios Empresariales de la posibilidad de que se utilicen los servicios de seguridad del nivel de método. Durante el tiempo de implementación, los administradores también deben agregar usuarios a la función Marshaler definida por el sistema, que se crea automáticamente en el catálogo COM+, cuando una clase marcada con SecureMethod se registra en Servicios de componente.

El empleo de la función Marshaler se describe con mayor detalle en la siguiente sección.

El siguiente ejemplo muestra cómo agregar la función Manager a una interfaz específica.

[SecurityRole("Manager")]
public interface ISomeInterface
{
  void Method1( string message );
  void Method2( int parm1, int parm2 );
}

[ComponentAccessControl]
[SecureMethod]
public class MyServicedComponent : ServicedComponent, ISomeInterface
{
  public void Method1( string message )
  {
    // Implementation
  }
  public void Method2( int parm1, int parm2 )
  {
    // Implementation
  }
}

Agregar funciones a un método

Para garantizar que los métodos públicos de una clase aparezcan en el catálogo COM+ deberá implementar explícitamente una interfaz que defina los métodos. A continuación, utilice el atributo SecureMethod en la clase, o bien los atributos SecureMethod o SecurityRole para el nivel de método, para proteger dichos métodos.

Nota

Los atributos SecureMethod y SecurityRole deben figurar antes de la implementación del método y nunca en la definición de la interfaz.

Para habilitar la seguridad del nivel de método, lleve a cabo los siguientes pasos:

a. Defina una interfaz que contenga los métodos que desea proteger. Por ejemplo:

public interface ISomeInterface
{
  void Method1( string message );
  void Method2( int parm1, int parm2 );
}

b. Implemente la interfaz en la clase del componente revisado.

[ComponentAccessControl]
public class MyServicedComponent : ServicedComponent, ISomeInterface
{
  public void Method1( string message )
  {
    // Implementation
  }
  public void Method2( int parm1, int parm2 )
  {
    // Implementation
  }
}

c. Si desea configurar las funciones de manera administrativa mediante la herramienta Servicios de componente, anote la clase con el atributo SecureMethod, como muestra el siguiente ejemplo.

[ComponentAccessControl]
[SecureMethod]
public class MyServicedComponent : ServicedComponent, ISomeInterface
{
}

d. Si lo desea, también puede agregar funciones a los métodos durante el tiempo de desarrollo con ayuda de los atributos .NET y aplicando el atributo SecurityRole para el nivel de método. En este caso no es necesario aplicar el atributo SecureMethod para el nivel de clases (a pesar de que el atributo ComponentAccessControl debe incluirse de todos modos para configurar las comprobaciones de acceso para el nivel de componentes).

En el siguiente ejemplo, sólo los miembros de la función Manager pueden llamar a Method1, mientras que los miembros de las funciones Manager y Employee pueden llamar a Method2.

[ComponentAccessControl]
public class MyServicedComponent : ServicedComponent, ISomeInterface
{
  [SecurityRole("Manager")]
  public void Method1( string message )
  {
    // Implementation
  }
  [SecurityRole("Manager")]
  [SecurityRole("Employee")]
  public void Method2( int parm1, int parm2 )
  {
    // Implementation
  }
}

e. Durante el tiempo de implementación, los administradores deben agregar a la función predefinida Marshaler cualquier usuario que vaya a necesitar acceso a los métodos o interfaces de la clase.

Nota

La infraestructura de Servicios Empresariales utiliza una serie de interfaces de nivel de sistema que exponen todos los componentes revisados. Dichas interfaces incluyen IManagedObject, IDisposable y IServiceComponentInfo. Si se habilitan las comprobaciones de acceso para los niveles de interfaz o método, se denegará el acceso de la infraestructura de Servicios Empresariales a esas interfaces.

Como consecuencia, Servicios Empresariales crea una función especial denominada Marshaler y la asocia a las interfaces en cuestión. La función puede visualizarse (en las interfaces mencionadas) con ayuda de la herramienta Servicios de componente.

Durante el tiempo de implementación, los administradores deben agregar a la función Marshaler todos los usuarios que vayan a necesitar acceso a los métodos o interfaces de la clase. Este proceso puede automatizarse de dos modos:

  • Escribir una secuencia de comandos que utilice el modelo de objetos Servicios de componente para copiar todos los usuarios desde otras funciones a la función Marshaler.

  • Escribir una secuencia de comandos que asigne el resto de las funciones a estas tres interfaces especiales y que elimine la función Marshaler.

Registrar componentes revisados

Los componentes revisados pueden registrarse en:

  • La caché de ensamblados global. Los componentes revisados alojados en las aplicaciones de servidor COM+ exigen la instalación en la caché de ensamblados global, a diferencia de las aplicaciones de biblioteca.

Para registrar un componente revisado en la caché de ensamblados global, ejecute la utilidad de la línea de comandos Gacutil.exe. Para registrar un ensamblado denominado MyServicedComponent.dll en la caché de ensamblados global, ejecute el siguiente comando.

gacutil –i MyServicedComponent.dll

Nota

También puede utilizar la herramienta Configuración de Microsoft .NET Framework desde el grupo de programas Herramientas administrativas para ver y trabajar con el contenido de la caché de ensamblados global.

  • El catálogo COM+. Para registrar un ensamblado denominado MyServicedComponent.dll en el catálogo COM+, ejecute el siguiente comando.

regsvcs.exe MyServicedComponent.dll

Este comando crea una aplicación COM+. Los atributos .NET del ensamblado se utilizan para llenar el catálogo COM+.

Llenar funciones

Llene las funciones con ayuda de la herramienta Servicios de componente o mediante secuencias de comandos para programar el catálogo COM+ con los objetos de administración COM+.

Utilizar grupos de Windows

Agregue cuentas de grupo de Windows 2000 a funciones de Servicios Empresariales para disfrutar de una flexibilidad máxima. Los grupos de Windows permiten utilizar de forma eficaz una herramienta de administración (la herramienta Administración de usuarios y equipos) para administrar tanto la seguridad de Windows como la de Servicios Empresariales.

  • Cree un grupo de Windows para cada función de la aplicación Servicios Empresariales.

  • Asigne cada grupo a la función pertinente.

Por ejemplo, si tiene una función denominada Manager, cree un grupo de Windows denominado Managers. Asigne el grupo Managers a la función Manager.

  • Una vez asignados los grupos a las funciones, utilice la herramienta Administración de usuarios y equipos para agregar y eliminar usuarios de cada grupo.

Por ejemplo, al agregar una cuenta de usuario de Windows 2000 denominada David al grupo Managers de Windows 2000, David se asigna de forma efectiva a la función Manager.

Para asignar grupos de Windows a funciones de Servicios Empresariales mediante Servicios de componente

  1. Con la herramienta Servicios de componente, expanda la aplicación que contenga las funciones a las que desee agregar grupos de Windows 2000.

  2. Expanda la carpeta Funciones y la función específica a la que desee asignar los grupos de Windows.

  3. Seleccione la carpeta Usuarios de la función en cuestión.

  4. Haga clic con el botón secundario del mouse (ratón) en la carpeta, seleccione Nuevo y haga clic en Usuario.

  5. En el cuadro de diálogo Seleccionar usuarios o grupos, agregue los grupos (o usuarios) que desee a la función.

Más información

Si desea obtener más información acerca de cómo programar el catálogo COM+ mediante los objetos de administración COM+, consulte el apartado "Automating COM+ Administration" (en inglés) de la sección de desarrollo de componentes de la Biblioteca MSDN.

Configurar la identidad

Utilice la herramienta Servicios de componente (o secuencia de comandos) para configurar la identidad de la aplicación de Servicios Empresariales. La propiedad de identidad determina la cuenta utilizada para ejecutar la instancia Dllhost.exe que aloja la aplicación.

  • Para configurar la identidad

    1. Con la herramienta Servicios de componente, seleccione la aplicación que desee.

    2. Haga clic con el botón secundario del mouse (ratón) en el nombre de la aplicación y haga clic en Propiedades.

    3. Haga clic en la ficha Identidad.

    4. Haga clic en Este usuario y especifique la cuenta de servicio configurada para ejecutar la aplicación.

Más información

Para obtener más información acerca de cómo elegir una identidad apropiada para ejecutar una aplicación de Servicios Empresariales, consulte la sección "Seleccionar una identidad de proceso" que encontrará más adelante en este capítulo.

Configurar una aplicación cliente ASP.NET

Configure el nivel de autenticación DCOM y los niveles de suplantación que utilizan las aplicaciones cliente cuando se comunican con componentes revisados que emplean DCOM.

Configurar la autenticación

Para configurar el nivel de autenticación predeterminado de una aplicación Web de ASP.NET cuando se comunica con un componente revisado, edite el atributo comAuthenticationLevel del elemento del archivo Machine.config.

El archivo Machine.config se halla en la carpeta que se indica a continuación.

%windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG

Establezca el atributo comAuthenticationLevel en uno de los siguientes valores.

comAuthenticationLevel=
            "[Default|None|Connect|Call|Pkt|PktIntegrity|PktPrivacy]"

Más información

Para obtener más información acerca de los niveles de autenticación DCOM, consulte el apartado "Autenticación" de la sección “Conceptos de seguridad” de este mismo capítulo.

Configurar la suplantación

El nivel de suplantación establecido por el cliente determina las funciones del nivel de suplantación para el servidor. Para configurar el nivel de suplantación predeterminado de una aplicación basada en Web de ASP.NET cuando se comunica con un componente revisado, edite el atributo comImpersonationLevel del elemento del archivo Machine.config y establézcalo en alguno de los valores que se indican a continuación.

comImpersonationLevel="[Default|Anonymous|Identify|Impersonate|Delegate]"

Más información

Para obtener más información acerca de los niveles de suplantación DCOM, consulte el apartado "Suplantación" de la sección “Conceptos de seguridad” que encontrará en este mismo capítulo.

Configurar los niveles de suplantación para una aplicación de Servicios Empresariales

Si un componente revisado de una aplicación necesita llamar a un componente revisado de una segunda aplicación (de servidor), quizás necesite configurar el nivel de suplantación para la aplicación cliente.

Nota

El nivel de suplantación configurado para una aplicación de Servicios Empresariales (en la página Seguridad del cuadro de diálogo Propiedades de la aplicación) es el nivel de suplantación que utilizan las llamadas salientes de los componentes de la aplicación. No tiene repercusión alguna que los componentes revisados de la aplicación ejecuten o no funciones de suplantación. Utilice las técnicas de suplantación mediante programación descritas en la sección “Transferir el llamador original” que figura más adelante en este mismo capítulo para suplantar clientes de un componente revisado.

Para configurar el nivel de suplantación de la aplicación mediante declaraciones, utilice el atributo de nivel de ensamblado ApplicationAccessControl tal como se indica a continuación.

[assembly: ApplicationAccessControl( ImpersonationLevel=ImpersonationLevelOption.Identify)]

Este proceso es el equivalente a establecer el valor Nivel de suplantación de la página Seguridad del cuadro de diálogo Propiedades de Servicios de componente.

Programar la seguridad

Los componentes .NET permiten disfrutar de las funciones de seguridad de Servicios Empresariales cuando se utilizan las clases ContextUtil, SecurityCallContext y SecurityIdentity.

Seguridad basada en funciones mediante programación

Puede probar mediante programación la pertenencia a funciones mediante el método IsCallerInRole de la clase ContextUtil, con lo que podrá tomar decisiones de autorización de mayor granularidad. Antes de llamar al método, compruebe siempre que estén habilitadas las comprobaciones de acceso para el nivel de componentes, como muestra el siguiente fragmento de código. Si está deshabilitada, el método IsCallerInRole devuelve siempre el valor “true”.

public void Transfer(string fromAccount, string toAccount, double amount)
{
  // Check that security is enabled
  if (ContextUtil.IsSecurityEnabled) 
  {
    // Only Managers are allowed to transfer sums of money in excess of $1000
    if (amount > 1000)
    {
      if (ContextUtil.IsCallerInRole("Manager"))
      {
        // Caller is authorized
      }
      else
      {
        // Caller is unauthorized
      }
    }
}

Identificar los llamadores

El siguiente ejemplo muestra cómo identificar a todos los llamadores precedentes desde un componente revisado.

[ComponentAccessControl]
public class MyServicedComponent : ServicedComponent
{
  public void ShowCallers()
  {
    SecurityCallContext context = SecurityCallContext.CurrentCall;
    SecurityCallers callers = context.Callers;
    foreach(SecurityIdentity id in callers)
    {
      Console.WriteLine(id.AccountName);
    }
  }
}

Nota

La identidad del llamador original puede obtenerse mediante la propiedad SecurityCallContext.OriginalCaller.

Seleccionar una identidad de proceso

Las aplicaciones de Servicios Empresariales activadas por el servidor se ejecutan en una instancia del proceso Dllhost.exe. Es necesario configurar la cuenta utilizada para ejecutar el proceso en el catálogo COM+ mediante la herramienta Servicios de componente.

Nota

No es posible especificar la ejecución como identidad mediante un atributo .NET.

No ejecutar nunca como usuario interactivo

No ejecute las aplicaciones de servidor con la identidad del usuario que haya iniciado sesión de forma interactiva (configuración predeterminada). Existen dos motivos básicos para evitar este comportamiento:

  • Los privilegios y derechos de acceso de la aplicación varían y dependen de la identidad del usuario que haya iniciado una sesión de forma interactiva en el servidor. Si es un administrador quien inicia la sesión, la aplicación dispondrá de privilegios de administrador.

  • Si la aplicación se inicia mientras un usuario inicia una sesión de forma interactiva y se desconecta a continuación, se cerrará la aplicación de servidor. No podrá reiniciarse hasta que otro usuario inicie una sesión interactivamente.

Los desarrolladores diseñan la configuración del usuario interactivo para utilizarla durante el tiempo de desarrollo, por lo que no debería considerarse como una configuración de implementación.

Utilizar una cuenta personalizada con privilegios mínimos

Utilice una cuenta con privilegios mínimos para mitigar la amenaza asociada a la exposición del proceso. Si un determinado intruso consigue poner en peligro el proceso servidor, podrá heredar con facilidad los privilegios y derechos de acceso concedidos a la cuenta de proceso. Una cuenta configurada con privilegios mínimos reduce los daños posibles.

Si necesita obtener acceso a recursos de red con la cuenta de proceso, es imprescindible que el equipo remoto pueda autenticar la cuenta del proceso. Existen dos opciones para escenarios de este tipo:

  • Utilizar una cuenta de dominio si los dos equipos se encuentran en los mismos dominios o en dominios de confianza.

  • Utilizar una cuenta local y crear a continuación una cuenta duplicada (con el mismo nombre y la misma contraseña) en el equipo remoto. Esta opción permite garantizar la sincronización de las contraseñas de ambas cuentas.

Quizás se vea obligado a utilizar el enfoque de la cuenta local duplicada si el equipo remoto se halla en un dominio independiente (sin relación de confianza) o bien protegido por un servidor de seguridad (en el que el hecho de que los puertos estén cerrados no permite utilizar la autenticación de Windows).

Obtener acceso a recursos de red

Es posible que los componentes revisados necesiten obtener acceso a recursos. En este sentido, resulta importante identificar los siguientes elementos:

  • Los recursos a los que necesitan obtener acceso los componentes. Por ejemplo, archivos de recursos compartidos de archivos, bases de datos, otros servidores DCOM, objetos de servicio Active Directory®, etc.

  • La identidad utilizada para realizar el acceso al recurso. Si el componente revisado obtiene acceso a recursos remotos, los equipos remotos deben poder ser capaces de autenticar la identidad utilizada (que de forma predeterminada es la identidad del proceso).

Nota

Si desea obtener información específica acerca de cómo obtener acceso a las bases de datos SQL Server, consulte el capítulo 12, "Seguridad del acceso a datos".

Puede obtener acceso a recursos remotos desde un componente de una aplicación de Servicios Empresariales mediante cualquiera de las siguientes identidades:

  • El llamador original (si se utiliza la suplantación explícita con CoImpersonateClient)

  • La identidad del proceso actual (configurada en el catálogo COM+ para las aplicaciones de servidor)

  • Una cuenta de servicio específica

Utilizar el llamador original

Para utilizar la identidad del llamador original para el acceso a recursos remotos es preciso:

  • Suplantar mediante programación el llamador original llamando a CoImpersonateClient.

  • Poder delegar el contexto de seguridad del llamador desde el servidor de aplicaciones que aloja la aplicación de Servicios Empresariales al equipo remoto. Este comportamiento asume el empleo de la autenticación Kerberos entre la aplicación de Servicios Empresariales y la aplicación cliente.

Advertencia de escalabilidad: si obtiene acceso al nivel de servicios de datos de la aplicación mediante la identidad suplantada del llamador original generará un impacto considerable en la escalabilidad de la aplicación, puesto que de este modo se evita que la agrupación de conexiones a la base de datos funcione de forma eficaz; y no funciona con eficacia porque el contexto de seguridad de cada conexión a una base de datos se halla vinculado a demasiados llamadores individuales.

Más información

Si desea obtener más información acerca de la suplantación de los llamadores, consulte el apartado "Transferir el llamador original" que figura más adelante en este capítulo.

Utilizar la identidad del proceso actual

La configuración de la aplicación para ejecutarse como aplicación de servidores permite utilizar la identidad del proceso configurada para obtener acceso a recursos remotos (comportamiento predeterminado).

Si se desea utilizar la cuenta del proceso servidor para el acceso a los recursos remotos, lleve a cabo los siguientes pasos:

  • Ejecute la aplicación de servidor mediante una cuenta de dominio con privilegios mínimos. Este comportamiento asume que los equipos cliente y servidor se hallan en los mismos dominios o en dominios de confianza.

  • Duplique la cuenta del proceso mediante el mismo nombre de usuario y contraseña del equipo remoto.

Cuando lo que se desea primar es la facilidad de administración es conveniente utilizar una cuenta de dominio con privilegios mínimos.

Si la aplicación que utiliza está configurada para ejecutarse como aplicación de biblioteca, la identidad del proceso se heredará del proceso host (que suele ser una aplicación basada en Web). Para obtener más información acerca del uso de la identidad del proceso ASP.NET para obtener acceso a recursos remotos, consulte el capítulo 8, "Seguridad de ASP.NET".

Utilizar una cuenta de servicio específica

La aplicación de Servicios Empresariales podría obtener acceso a los recursos remotos mediante una cuenta de servicio configurada específicamente para tal fin (es decir, una cuenta de Windows que no sea de usuario). Sin embargo, este enfoque no es recomendable en entornos Windows 2000 porque asume que se llamará a la API LogonUser.

El empleo de LogonUser en Windows 2000 obliga a conceder el privilegio "Actuar como parte del sistema operativo" a la cuenta de proceso de Servicios Empresariales. El resultado es una reducción notable de la seguridad de la aplicación.

Nota

Esta restricción dejará de existir en Microsoft Windows Server 2003.

Transferir el llamador original

De forma predeterminada, las llamadas salientes que envían los componentes revisados (para obtener acceso a recursos locales o remotos, por ejemplo) se realizan con el contexto de seguridad obtenido del proceso de host. En el caso de las aplicaciones de servidor, dicho contexto es la identidad “ejecutar como”. En el caso de las aplicaciones de biblioteca, se trata de la identidad del proceso de cliente (host), como por ejemplo Aspnet_wp.exe cuando la aplicación Web ASP.NET es el cliente.

Para transferir el contexto del llamador original a través de una aplicación de Servicios Empresariales

  1. Llame a CoImpersonateClient.

    De este modo se crea y adjunta un testigo de suplantación de subproceso al subproceso actual.

  2. Ejecute la operación (acceso al recurso local o remoto).

    Dado que la suplantación está habilitada, la llamada saliente se realiza con el contexto de seguridad del cliente (tal como lo define el testigo de suplantación).

    En caso de obtener acceso a recursos locales, el llamador (proceso de cliente) debe haber especificado como mínimo la suplantación de nivel de suplantación. Si se va a obtener acceso a recursos remotos, el llamador debe haber especificado la suplantación de nivel de delegación.

    Si el llamador es una aplicación Web de ASP.NET, el nivel de suplantación predeterminado para el proceso de trabajo de ASP.NET será Suplantación. Por lo tanto, para transferir el llamador original a un equipo remoto de nivel inferior es preciso cambiar este valor predeterminado para la delegación (valor “Delegate” del elemento del archivo Machine.config del equipo cliente).

    Nota

    El empleo del contexto de seguridad del llamador original para obtener acceso a los recursos remotos exige la autenticación Kerberos, además de la configuración de cuentas para la delegación. La cuenta utilizada para ejecutar la aplicación de servidor de Servicios Empresariales también debe marcarse en Active Directory como “Delegación de confianza”.

  3. Detenga la suplantación llamando a CoRevertToSelf.

    De este modo se elimina el testigo de suplantación. Cualquier llamada posterior realizada desde el método actual utilizará el contexto de seguridad del proceso. Si no puede llamar a CoRevertToSelf, se llamará implícitamente durante el tiempo de ejecución cuando termine el método.

Nota

La identidad del llamador original se transmite automáticamente a una aplicación de Servicios Empresariales y puede utilizarse mediante SecurityCallContext.OriginalCaller. Este enfoque puede resultar útil para fines de auditoría.

Llamar a CoImpersonateClient

CoImpersonateClient (y CoRevertToSelf) se hallan en OLE32.dll. Deben importarse las definiciones correspondientes mediante el atributo DllImport a fin de poder llamarlos a través de P/Invoke. El siguiente fragmento de código ilustra esta situación.

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

  [DllImport("OLE32.DLL", CharSet=CharSet.Auto)] 
  public static extern uint CoRevertToSelf(); 
} 
. . .
void SomeMethod()
{
  // To flow the original caller's security context and use it to access local
  // or remote resources, start impersonation 
  COMSec.CoImpersonateClient(); 
  // Perform operations as the caller
  // Code here uses the context of the caller – not the context of the process 
  . . .
  COMSec.CoRevertToSelf();
  // Code here reverts to using the process context
}

Más información

Para obtener más información acerca de cómo configurar un escenario de delegación Kerberos completo que muestre cómo transmitir el contexto de seguridad del llamador original a través de una aplicación Web de ASP.NET o una aplicación de Servicios Empresariales hasta una base de datos, consulte la sección "Transferir el llamador original" del capítulo 5, "Seguridad de intranet".

Cifrado RPC

Para proteger los datos que se envían desde una aplicación cliente a un componente revisado remoto a través de DCOM, utilice el nivel de autenticación de privacidad de paquetes RPC entre el cliente y el servidor. Dicho paquete proporciona confidencialidad e integridad para los mensajes.

Configure el nivel de autenticación en el cliente y el servidor.

Para configurar ASP.NET (cuando una aplicación Web deASP.NET es el cliente), establezca el atributo comAuthenticationLevel del elemento del archivo Machine.config en PktPrivacy.

Para configurar una aplicación de servidor de Servicios Empresariales, establezca el nivel de autenticación para el nivel de aplicación mediante la herramienta Servicios de componente o bien con el siguiente atributo .NET del ensamblado del componente revisado.

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

Más información

  • Si desea obtener más información acerca de cómo configurar la seguridad (incluidos los niveles de autenticación), consulte la sección "Configurar la seguridad" que encontrará en este mismo capítulo.

  • Si desea obtener más información acerca de los niveles de autenticación RPC/DCOM, consulte la sección "Autenticación" que figura más adelante en este capítulo.

  • Para obtener más información acerca de la negociación del nivel de autenticación, consulte la sección "Negociación del nivel de autenticación" que figura más adelante en este mismo capítulo.

Crear componentes revisados

Para obtener una guía detallada paso a paso acerca de la creación de un componente revisado, consulte "Cómo utilizar la seguridad basada en funciones con Servicios Empresariales" en la sección de referencia de este manual.

Problemas del bloqueo de DLL

Si encuentra alguna DLL bloqueada al volver a crear un componente revisado:

  • Utilice Servicios de componente para cerrar la aplicación de servidor COM+.

  • Si desarrolla una aplicación de biblioteca, es posible que aún pueda cargar la aplicación en el proceso Aspnet_wp.exe. Ejecute IISReset desde el símbolo del sistema o utilice el Administrador de tareas para detener el proceso Aspnet_wp.exe.

  • Utilice la herramienta FileMon.exe de www.sysinternals.com para obtener ayuda acerca de la resolución de problemas del bloqueo de archivos.

Versiones

A continuación se muestra el atributo predeterminado AssemblyVersion generado por el sistema de desarrollo Microsoft Visual Studio® .NET.

[assembly: AssemblyVersion("1.0.*")]

Cada vez que vuelva a crear el proyecto se generará una nueva versión del ensamblado. Este comportamiento da lugar a la generación de un nuevo identificador de clase (CLSID) para identificar las clases de componentes revisados. Si registra repetidamente el ensamblado con los servicios de componente mediante Regsvcs.exe, se generarán componentes duplicados (única y exclusivamente clases) con diferentes CLSID que se enumeran en la carpeta Componentes.

Aunque este enfoque es compatible con la semántica estricta de la creación de versiones COM y evita que tanto los clientes administrados como los no administrados tengan problemas de funcionamiento, puede provocar problemas durante el desarrollo.

Durante la fase de pruebas y desarrollo, plantéese la posibilidad de establecer una versión explícita mediante el atributo AssemblyVersion del nivel de ensamblado que figura a continuación.

[assembly: AssemblyVersion("1.0.0.1")]

Esta configuración evitará que se genere un nuevo CLSID cada vez que se cree un nuevo proyecto. Quizás desee también solucionar los identificadores de interfaz (IID). Si la clase que utiliza implementa interfaces explícitas, puede corregir el IID de una determinada interfaz con el atributo GUID, tal como se muestra a continuación:

[Guid("E1FBF27E-9F11-474d-8DF6-58916F798E9D")]
public interface IMyInterface
{
}
  • Para generar nuevos GUID

    1. En el menú Herramientas de Visual Studio .NET, haga clic en Crear GUID.

    2. Haga clic en Formato de registro.

    3. Haga clic en Nuevo GUID.

    4. Haga clic en Copiar.

    5. Pegue el GUID desde el Portapapeles al código fuente.

Nota

Antes de implementar el ensamblado de los componentes revisados para realizar pruebas e iniciar la producción, elimine cualquier GUID fijo y vuelva a usar un mecanismo automático de control de versiones de ensamblados (por ejemplo, “1.0.*”). El hecho de no poder hacerlo aumenta las posibilidades de que una nueva versión del componente estropee los clientes existentes.

Más información

Para obtener más información acerca del control de versiones para la implementación, consulte Understanding Enterprise Services (COM+) in .NET (en inglés) en MSDN.

Excepciones de QueryInterface

Si tras un error de la interfaz IroleSecurity se detecta una llamada a QueryInterface, significa que se ha actualizado la definición de la interfaz del ensamblado pero que no se ha vuelto a registrar el ensamblado en Servicios de componente mediante Regsvcs.exe.

Nota

Cada vez que ejecute Regsvcs.exe deberá volver a configurar la identidad “ejecutar como” de la aplicación de servidor, además de volver a agregar usuarios a los grupos. Puede crear una secuencia de comandos simple para automatizar esta tarea.

DCOM y servidores de seguridad

Windows 2000 (SP3 o QFE 18.1) o Windows Server 2003 permite configurar las aplicaciones de Servicios Empresariales para que utilicen un punto final estático. Si existe un servidor de seguridad que separa el cliente del servidor, bastará con que abra dos puertos de dicho servidor de seguridad. En concreto, deberá abrir el puerto 135 para RPC y un puerto para la aplicación de Servicios Empresariales.

Como alternativa a este enfoque puede sopesar la posibilidad de exponer su aplicación de Servicios Empresariales como servicio Web. De esta forma podrá activar componentes revisados, y llamarlos, mediante el protocolo SOAP y el puerto 80. El principal problema de este enfoque es que no permite transmitir el contexto de la transacción del cliente al servidor. En este caso debería iniciar la transacción en el componente revisado remoto.

Más información

Consulte los siguientes artículos de la Knowledge Base para obtener más información (en inglés):

Llamar a componentes revisados desde ASP.NET

Esta sección resume los problemas básicos a los que deberá hacer frente cuando una aplicación ASP.NET llama a un componente revisado.

Identidad del llamador

Cuando llama a un componente revisado desde una aplicación de ASP.NET, la identidad de seguridad para la llamada se obtiene de la identidad de subproceso Win32® de la aplicación. Si la aplicación Web está configurada para la suplantación del llamador, será la identidad de éste último. De lo contrario, se utilizará la identidad de proceso de ASP.NET (ASPNET de forma predeterminada).

Desde una aplicación ASP.NET puede recuperarse la identidad de subproceso Win32 actual llamando a WindowsIdentity.GetCurrent().

Si se trata de un componente revisado, la identidad del llamador original puede recuperarse mediante SecurityCallContext.OriginalCaller.

Utilizar la autenticación de Windows y la suplantación en la aplicación basada en Web

Habilitar una seguridad basada en funciones coherente desde la aplicación de Servicios Empresariales requiere utilizar la autenticación de Windows y habilitar las funciones de suplantación. De este modo se garantiza que los componentes revisados puedan autenticar a los llamadores originales así como tomar decisiones de autorización según la identidad del llamador original.

Configurar la autenticación y suplantación en Machine.config

Los niveles de autenticación DCOM se negocia entre el cliente (por ejemplo, la aplicación basada en Web) y el servidor (la aplicación de Servicios Empresariales). Siempre se utilizará la configuración de seguridad más exigente de las dos.

Configure los niveles de autenticación de ASP.NET con ayuda del atributo comAuthenitcation del elemento del archivo Machine.config.

En cuanto a los niveles de suplantación, éstos son controlados por el cliente (por ejemplo, una aplicación basada en Web). El cliente puede determinar el grado de suplantación que desea permitir utilizar al servidor.

Configure los niveles de suplantación de ASP.NET (para todas las llamadas DCOM salientes) con ayuda del atributo comImpersonationLevel del elemento del archivo Machine.config.

Configurar los proxies de interfaz

La configuración de seguridad que se aplica a los proxies de interfaz individuales suele obtenerse de la configuración de seguridad predeterminada del nivel de proceso. Cuando se trata de ASP.NET, la configuración de seguridad predeterminada, tal como los niveles de suplantación y autenticación, se configuran en el archivo Machine.config, como se ha descrito anteriormente.

Puede modificar la configuración de seguridad de un proxy de interfaz individual siempre que sea necesario. Por ejemplo, si la aplicación ASP.NET se comunica con un componente revisado que expone dos interfaces y se transmiten datos importantes a través de una interfaz solamente, puede optar por utilizar la compatibilidad para cifrado que incluye el nivel de autenticación del paquete de privacidad sólo en la interfaz a través de la cual se transmitirá la información importante y por utilizar, por ejemplo, la autenticación de paquete en la otra interfaz. Con ello dejarán de producirse las mermas de rendimiento asociadas con el cifrado en ambas interfaces.

De forma global, el conjunto de la configuración de seguridad correspondiente a un proxy de interfaz se denomina “capa de seguridad”. COM ofrece las siguientes funciones para permitir realizar consultas y manipular la configuración de la “capa de seguridad” de los proxies de interfaz individual:

  • CoQueryProxyBlanket

  • CoSetProxyBlanket

  • CoCopyProxy

Utilice P/Invoke para llamar a estas funciones desde una aplicación Web de ASP.NET (el cliente DCOM). El siguiente fragmento de código muestra cómo configurar una interfaz específica para utilizar el nivel de autenticación de privacidad del paquete (que incluye funciones de cifrado). Este código puede utilizarse desde una aplicación Web de ASP.NET que se comunique con un componente revisado remoto.

// Define a wrapper class for the P/Invoke call to CoSetProxyBlanket
class COMSec 
{ 
  // Constants required for the call to CoSetProxyBlanket
  public const uint RPC_C_AUTHN_DEFAULT           = 0xFFFFFFFF;
  public const uint RPC_C_AUTHZ_DEFAULT           = 0xFFFFFFFF;
  public const uint RPC_C_AUTHN_LEVEL_PKT_PRIVACY = 6;
  public const uint RPC_C_IMP_LEVEL_DEFAULT       = 0;
  public const uint COLE_DEFAULT_AUTHINFO         = 0xFFFFFFFF;
  public const uint COLE_DEFAULT_PRINCIPAL        = 0;
  public const uint EOAC_DEFAULT                  = 0x800;

  // HRESULT  CoSetProxyBlanket( IUnknown * pProxy,
  //                             DWORD dwAuthnSvc,
  //                             DWORD dwAuthzSvc,
  //                             WCHAR * pServerPrincName, 
  //                             DWORD dwAuthnLevel,
  //                             DWORD dwImpLevel,
  //                             RPC_AUTH_IDENTITY_HANDLE pAuthInfo,
  //                             DWORD dwCapabilities ); 
[DllImport("OLE32.DLL", CharSet=CharSet.Auto)] 
public unsafe static extern uint CoSetProxyBlanket( 
                                      IntPtr pProxy,
                                      uint dwAuthnSvc,
                                      uint dwAuthzSvc,
                                      IntPtr pServerPrincName,
                                      uint dwAuthnLevel,
                                      uint dwImpLevel,
                                      IntPtr pAuthInfo,
                                      uint dwCapababilities);
} // end class COMSec


// Code to call CoSetProxyBlanket
void CallComponent()
{
  // This is the interface to configure
  Guid IID_ISecureInterface = new Guid("c720ff19-bec1-352c-bb4b-e2de10b858ba");
  IntPtr pISecureInterface;

  // Instantiate the serviced component
  CreditCardComponent comp = new CreditCardComponent();
  // Get its IUnknown pointer
  IntPtr pIUnk = Marshal.GetIUnknownForObject(comp);
  // Get the interface to configure
  Marshal.QueryInterface(pIUnk, ref IID_ISecureInterface, 
                         out pISecureInterface);
  try
  {
    // Configure the interface proxy and set packet privacy authentication
    uint hr = COMSec.CoSetProxyBlanket( pISecureInterface, 
                                        COMSec.RPC_C_AUTHN_DEFAULT,
                                        COMSec.RPC_C_AUTHZ_DEFAULT,
                                        IntPtr.Zero,
                                        COMSec.RPC_C_AUTHN_LEVEL_PKT_PRIVACY,
                                        COMSec.RPC_C_IMP_LEVEL_DEFAULT,
                                        IntPtr.Zero,
                                        COMSec.EOAC_DEFAULT );
    ISecureInterface secure = (ISecureInterface)comp;
    // The following call will be encrypted as ISecureInterface is configured
    // for packet privacy authentication. Other interfaces use the process 
    // level defaults (normally packet authentication).
    secure.ValidateCreditCard("123456789");
  }
  catch (Exception ex)
  {
  }
}

Más información

  • Si desea obtener más información acerca de cómo configurar una aplicación cliente de ASP.NET para que llame a componentes revisados, consulte la sección "Configurar una aplicación cliente ASP.NET" que figura más arriba en este mismo capítulo.

  • Para obtener más información acerca de los niveles de autenticación DCOM, consulte la sección "Autenticación" que encontrará más adelante.

  • Para obtener más información acerca de los niveles de suplantación DCOM, consulte la sección "Suplantación" que encontrará más adelante.

  • Para obtener más información acerca del uso de la autenticación de Windows y la habilitación de la suplantación para una aplicación basada en Web, consulte el capítulo 8, "Seguridad de ASP.NET".

Conceptos de seguridad

Esta sección describe brevemente los conceptos de seguridad de Servicios Empresariales. Si ya ha trabajado con COM+, le resultarán familiares muchos de los conceptos.

Si desea obtener información de referencia acerca de Servicios Empresariales, consulte el artículo "Understanding Enterprise Services (COM+) in .NET" (en inglés) de MSDN.

A continuación figuran una serie de resúmenes de los conceptos clave de seguridad con los que debería estar familiarizado:

  • La configuración de seguridad para los componentes revisados y las aplicaciones de Servicios Empresariales se almacenan en el catálogo COM+. La mayoría de los parámetros pueden configurarse con los atributos .NET. Todos los parámetros pueden configurarse con la herramienta de administración Servicios de componente o las secuencias de comandos del sistema de desarrollo Microsoft Visual Basic® Scripting Edition.

  • La autorización se lleva a cabo mediante las funciones de Servicios Empresariales (COM+), que pueden incluir cuentas de grupo o usuario de Windows. Son distintas de las funciones .NET.

  • La seguridad basada en funciones puede aplicarse en distintos niveles: aplicación, interfaz, clase y método.

  • Las comprobaciones de funciones imperativas se efectúan mediante programación directamente desde los métodos con el método IsCallerInRole de la clase ContextUtil.

  • La eficaz autorización basada en funciones de las aplicaciones de Servicios Empresariales se basa en la identidad de Windows que se utiliza para llamar a los componentes revisados.

  • Quizás sea necesario combinar la autenticación de Windows con la suplantación en las aplicaciones Web de ASP.NET, siempre que la aplicación Web llame a los componentes revisados que se basan en las funciones de Servicios Empresariales (COM+).

  • Cuando se llama a un componente revisado desde una aplicación Web de ASP.NET o un servicio Web, la identidad utilizada para la llamada DCOM saliente la determina la identidad de subproceso Win32 tal como se haya definido en WindowsIdentity.GetCurrent().

  • Los componentes revisados pueden ejecutarse en aplicaciones de servidor o de biblioteca.

  • Las aplicaciones de servidor se ejecutan en instancias independientes de Dllhost.exe.

  • Las aplicaciones de biblioteca se ejecutan en el espacio de direcciones de proceso del cliente.

  • La autorización basada en funciones se ejecuta de modo similar en las aplicaciones de servidor y de biblioteca, a pesar de algunas sutiles diferencias relativas a la seguridad. Para obtener información más detallada, consulte la sección "Seguridad para las aplicaciones de servidor y biblioteca" que figura más arriba en este mismo capítulo.

  • La autenticación se lleva a cabo a través de los servicios subyacentes de DCOM y RPC. Los niveles de autenticación del cliente y el servidor se combinan para determinar el nivel de autenticación resultante que se empleará para la comunicación con el componente revisado.

  • La suplantación se configura desde la aplicación cliente. Éste determina la funcionalidad de suplantación del servidor.

Funciones de Servicios Empresariales (COM+) y .NET

Las funciones de Servicios Empresariales (COM+) sirven para representar categorías comunes de usuarios que comparten los mismos privilegios de seguridad en una aplicación. A pesar de estar basadas en conceptos similares a los de las funciones .NET, funcionan de modo totalmente independiente.

Las funciones de Servicios Empresariales (COM+) contienen cuentas de usuario y grupo de Windows (a diferencia de las funciones .NET, que pueden incluir identidades de usuario no propias de Windows). Como consecuencia, las funciones de Servicios Empresariales (COM+) son sólo un mecanismo de autorización eficaz para aplicaciones que utilizan la autenticación de Windows y la suplantación (para transmitir el contexto de seguridad del llamador a la aplicación de Servicios Empresariales).

Tabla 9.1: comparación de funciones de Servicios Empresariales (COM+) y .NET

Característica

Funciones de Servicios Empresariales (COM+)

Funciones .NET

Administración

Herramienta de administración Servicios de componente

Personalizada

Almacén de datos

Catálogo COM+

Almacén de datos personalizado (SQL Server o Active Directory, por ejemplo)

Declarativas

Sí[SecurityRole("Manager")]

Sí[PrincipalPermission(SecurityAction.Demand, Role="Manager")]

Imperativas

SíContextUtil.IsCallerInRole()

SíIPrincipal.IsInRole

Granularidad para niveles de clases, interfaces y métodos

Extensible

No

Sí(mediante la implementación personalizada de IPrincipal)

Disponible para todos los componentes .NET

Sólo para componentesderivados de la clase básica ServicedComponent

Pertenencia a funciones

Las funciones incluyen cuentas de grupo o usuario de Windows

Cuando se utiliza WindowsPrincipals, las funciones SON grupos de Windows: no hay niveles adicionales de abstracción

Requiere una implementación explícita de la interfaz

SíPara conseguir la autorización para el nivel de método es preciso definir e implementar explícitamente una interfaz.

No

Autenticación

Dado que los Servicios Empresariales se basan en la infraestructura subyacente que proporcionan COM+ y DCOM/RPC, la configuración del nivel de autenticación disponible para las aplicaciones de Servicios Empresariales es la configuración definida por RPC (y que utiliza DCOM).

Tabla 9.2: configuración de la autenticación para aplicaciones de Servicios Empresariales

Nivel de autenticación

Descripción

Predeterminado

Se selecciona el nivel de autenticación con las normas de negociación normales.

Ninguno

No se ejecuta la autenticación.

Conexión

Sólo se autentican las credenciales cuando el cliente se conecta al servidor.

Llamada

Efectúa la autenticación al principio de cada llamada a procedimientos remotos.

Paquete

Autentica todos los datos recibidos del cliente.

Integridad del paquete

Autentica todos los datos y comprueba que no se hayan modificado ninguno de los datos transferidos.

Privacidad del paquete

Autentica todos los datos y cifra el estado de los parámetros para cada llamada a procedimientos remotos.

Promoción del nivel de autenticación

Es importante que sea consciente de la promoción que se efectúa en silencio de algunos niveles de autenticación. Por ejemplo:

  • Cuando se utiliza el transporte de datagramas UDP (protocolo de datos de usuario), los niveles de conexión y llamada se promocionan al nivel de paquete porque los niveles de autenticación mencionados anteriormente son válidos únicamente para el transporte orientado a conexiones como puede ser TCP.

    Nota

    Windows 2000 utiliza de forma predeterminada RPC cuando utiliza el protocolo TCP para las comunicaciones DCOM.

  • En el caso de las llamadas entre procesos de un único equipo, todos los niveles de autenticación se promocionan siempre al nivel de privacidad del paquete. No obstante, en los escenarios de equipos únicos, los datos no se cifran para mantener la confidencialidad (porque los datos no van a ser transmitidos por ninguna red).

Negociación del nivel de autenticación

El nivel de autenticación que utiliza Servicios Empresariales para autenticar un cliente lo determinan estos dos parámetros de configuración:

  • El nivel de autenticación para el nivel de procesos. Para las aplicaciones activadas por un servidor (que se ejecutan en Dllhost.exe), el nivel de autenticación se configura desde el catálogo COM+.

  • El nivel de autenticación del cliente. El nivel de autenticación configurado del proceso de cliente que se comunica con el componente revisado también incide sobre el nivel de autenticación utilizado.

El nivel de autenticación predeterminado para una aplicación Web de ASP.NET se define mediante el atributo comAuthenticationLevel del elemento del archivo Machine.config.

Siempre se selecciona el nivel de autenticación más elevado de los dos (cliente y servidor). La ilustración 9.4 refleja este proceso.

imagen

Ilustración 9.4
Negociación del nivel de autenticación

Más información

Si desea obtener más información acerca de cómo configurar los niveles de autenticación para una aplicación de Servicios Empresariales, consulte la sección "Configurar la seguridad" que figura más arriba en este mismo capítulo.

Suplantación

El nivel de suplantación definido para una aplicación de Servicios Empresariales determina el nivel de suplantación que se aplicará a todas las llamadas DCOM salientes que efectúen los componentes revisados de la aplicación.

Nota

El nivel de suplantación definido para una aplicación de Servicios Empresariales determina el nivel de suplantación que se aplicará a todas las llamadas DCOM salientes que efectúen los componentes revisados de la aplicación.

La suplantación es un parámetro del cliente. Constituye un nivel de protección del cliente puesto que le permite restringir las funciones de suplantación del servidor.

Tabla 9.3: niveles de suplantación disponibles

Nivel de autenticación

Descripción

Predeterminado

Se selecciona el nivel de autenticación con las normas de negociación normales.

Ninguno

No se ejecuta la autenticación.

Conexión

Sólo se autentican las credenciales cuando el cliente se conecta al servidor.

Llamada

Efectúa la autenticación al principio de cada llamada a procedimientos remotos.

Paquete

Autentica todos los datos recibidos del cliente.

Integridad del paquete

Autentica todos los datos y comprueba que no se hayan modificado ninguno de los datos transferidos.

Privacidad del paquete

Autentica todos los datos y cifra el estado de los parámetros para cada llamada a procedimientos remotos

El nivel de suplantación predeterminado de una aplicación basada en Web de ASP.NET cuando se comunica con un componente revisado (o cualquier componente que utilice DCOM) se especifica mediante el atributo comImpersonationLevel del elemento del archivo Machine.config.

Cloaking (diseño invisible)

La opción Cloaking determina exactamente el modo como se protege la identidad del cliente desde un proxy de objetos COM a un servidor durante la suplantación. Existen dos formas de cloaking:

  • Cloaking dinámico. Las aplicaciones servidor de Servicios Empresariales utilizan el cloaking dinámico (que no admite configuración alguna). El cloaking de las aplicaciones biblioteca viene determinado por el proceso de host, por ejemplo, por el proceso de trabajo de ASP.NET (Aspnet_wp.exe). Las aplicaciones basadas en Web también utilizan el cloaking dinámico que tampoco se puede configurar.

    El cloaking dinámico provoca que se utilice el testigo de suplantación de subproceso para suplantar la identidad del cliente durante la suplantación. Esto significa que, si llama a CoImpersonateClient desde un componente revisado, se asume la identidad del cliente para las llamadas salientes posteriores efectuadas con el mismo método, hasta que se llame a CoRevertToSelf o finalice el método (por el que se llama implícitamente a CoRevertToSelf).

  • Cloaking estático. Con el cloaking estático, el servidor ve las credenciales utilizadas en la primera llamada del cliente al servidor (independientemente de si algún subproceso ejecuta la suplantación durante una llamada saliente).

Más información

  • Para obtener información acerca de la configuración de los niveles de suplantación para las aplicaciones de Servicios Empresariales, consulte la sección "Configurar la seguridad" que figura más arriba en este capítulo.

  • Para obtener más información acerca de cloaking (diseño invisible), consulte la información de "Cloaking" en la Platform SDK de MSDN (en inglés).

Resumen

En este capítulo se ha explicado cómo crear componentes revisados seguros en las aplicaciones de Servicios Empresariales. También se ha descrito cómo configurar la aplicación cliente basada en Web de ASP.NET que llama a los componentes revisados.
En resumen:

  • Utilice aplicaciones de Servicios Empresariales activadas por un servidor para mejorar la seguridad. Los saltos de procesos adicionales permiten aumentar el nivel de seguridad.

  • Utilice cuentas locales con privilegios mínimos para ejecutar las aplicaciones de servidor.

  • Utilice el nivel de autenticación de privacidad de paquetes (que debe configurarse tanto en el servidor como en el cliente) cuando sea necesario proteger los datos que se transfieren entre los componentes revisados de una red de una aplicación cliente.

  • Habilite las comprobaciones de acceso para el nivel de componentes para disfrutar de una implementación eficaz de la seguridad basada en funciones.

  • Utilice la autenticación de Windows y habilite la suplantación en las aplicaciones Web de ASP.NET antes de llamar a un componente de una aplicación de Servicios Empresariales que funcione con la seguridad basada en funciones.

  • Utilice las clases seguras de las puertas de enlace como puntos de entrada a las aplicaciones de Servicios Empresariales.

Al reducir el número de clases de puertas de enlace que proporcionan puntos de entrada para los clientes de las aplicaciones de Servicios Empresariales se reduce también el número de clases que precisan tener funciones asignadas. Deben habilitarse las comprobaciones basadas en funciones para otras clases de ayuda auxiliares internas, pero no deben asignárseles funciones. Es decir, los clientes externos no podrán llamarlas directamente, mientras que las clases de puerta de enlace de la propia aplicación disfrutarán de acceso directo.

  • Llame a IsSecurityEnabled justo antes de comprobar la pertenencia a funciones mediante programación.

  • Evite la suplantación en el nivel medio ya que su uso impide la agrupación efectiva de conexiones a bases de datos y reduce considerablemente la escalabilidad de la aplicación.

  • Agregue grupos de Windows a las funciones de Servicios Empresariales (COM+) para aumentar la flexibilidad y facilitar la administración.

Mostrar:
© 2014 Microsoft