Exportar (0) Imprimir
Expandir todo

Capítulo 2 - Modelo de seguridad para aplicaciones ASP.NET

Publicado: 26 de junio de 2006

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

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

Resumen: Este capítulo describe las características comunes de las aplicaciones Web .NET desde la perspectiva de la seguridad y presenta el modelo de seguridad de estas aplicaciones.

Este capítulo contiene una introducción a la seguridad de las aplicaciones Web .NET. Proporciona información general acerca de las características y servicios de seguridad que se aplican a todos los niveles de una aplicación Web .NET típica.

El objetivo del capítulo es:

  • Proporcionar un marco de referencia para las aplicaciones Web .NET típicas

  • Identificar las características de seguridad de autenticación, autorización y comunicación segura ofrecidas por las diversas tecnologías de implementación utilizadas en la creación de aplicaciones Web .NET

  • Identificar guardianes y puertas que pueden utilizarse en la aplicación para imponer límites de confianza.

En esta página

Aplicaciones Web .NET Aplicaciones Web .NET
Tecnologías de implementación Tecnologías de implementación
Arquitectura de seguridad Arquitectura de seguridad
Identidades y principales Identidades y principales
Conclusión Conclusión

Aplicaciones Web .NET

Esta sección contiene una introducción breve a las aplicaciones Web .NET y describe sus características desde un punto de vista tanto lógico como físico. Contiene además una introducción a las diversas tecnologías de implementación utilizadas en la creación de aplicaciones Web .NET.

Niveles lógicos

La arquitectura lógica de aplicaciones considera todos los sistemas como conjuntos de servicios en cooperación que se encuentran agrupados en los niveles siguientes:

  • Servicios de usuarios

  • Servicios empresariales

  • Servicios de datos

El valor de este punto de vista de la arquitectura lógica radica en la identificación de los tipos genéricos de servicios que siempre están presentes en cualquier sistema, para garantizar la segmentación adecuada y para impulsar la definición de interfaces entre niveles. Esta segmentación le permite tomar decisiones más discretas acerca de la arquitectura y del diseño al implementar cada nivel, y crear una aplicación más fácil de mantener.

Los niveles pueden describirse tal y como se explica a continuación:

  • Los Servicios de usuarios se encargan de la interacción de clientes con el sistema y proporcionan un puente común a la lógica empresarial básica encapsulada por componentes del nivel de Servicios empresariales. Tradicionalmente, los Servicios de usuarios suelen asociarse a los usuarios interactivos. No obstante, también llevan a cabo el procesamiento inicial de peticiones programables de otros sistemas, en las que no participa una interfaz de usuario visible. La autenticación y la autorización, cuya naturaleza exacta varía en función del tipo de cliente, suelen realizarse en el nivel de Servicios de usuarios.

  • Los Servicios empresariales proporcionan la funcionalidad básica del sistema y encapsulan la lógica empresarial. Son independientes del canal de entrega, de los sistemas de servidor y de los orígenes de datos. Esto ofrece la estabilidad y la flexibilidad necesarias para desarrollar el sistema de forma que admita canales y sistemas de servidor nuevos y diferentes. Normalmente, el procesamiento de una petición empresarial concreta requiere la participación de varios componentes en colaboración del nivel de Servicios empresariales.

  • Los Servicios de datos proporcionan acceso a datos (alojados en los límites del sistema) y a otros sistemas (de servidor) a través de interfaces genéricas que resultan sencillas de utilizar desde componentes del nivel de Servicios empresariales. Los Servicios de datos compendian la diversidad de sistemas de servidor y orígenes de datos, y encapsulan reglas de acceso y formatos de datos específicos.

La clasificación lógica de los tipos de servicios de un sistema puede corresponderse con la posible distribución física de los componentes que implementan los servicios, aunque es relativamente independiente de la misma.

También es importante tener en cuenta que los niveles lógicos pueden identificarse en cualquier nivel de agregación; es decir, pueden identificarse para el sistema de forma global (en el contexto de su entorno e interacciones externas) y para cualquier subsistema contenido en ellos. Por ejemplo, cada nodo remoto que aloja un servicio Web se compone de Servicios de usuarios (que se ocupan de las peticiones y los mensajes entrantes), Servicios empresariales y Servicios de datos.

Modelos físicos de implementación

Los tres niveles de servicios lógicos descritos anteriormente no suponen la existencia de un número específico de niveles físicos. Los tres servicios lógicos pueden estar ubicados físicamente en el mismo equipo o distribuidos en diversos equipos.

El servidor Web como servidor de aplicaciones

Un patrón de implementación habitual de las aplicaciones Web .NET está dirigido a la búsqueda de componentes empresariales y de acceso a datos en el servidor Web. De este modo se reducen al mínimo los saltos de red, lo que puede mejorar el rendimiento. Este modelo se muestra en la ilustración 2.1.

imagen

Ilustración 2.1

El servidor Web como servidor de aplicaciones

Nivel de aplicaciones remoto

El nivel de aplicaciones remoto es un patrón de implementación habitual, en concreto para los escenarios de Internet en los que el nivel Web es independiente en una red perimetral (también denominada DMZ, zona desmilitarizada y subred protegida) y está separado de los usuarios finales y del nivel de aplicaciones remoto por servidores de seguridad de filtrado de paquetes. El nivel de aplicaciones remoto se muestra en la ilustración 2.2.

imagen

Ilustración 2.2

La introducción de un nivel de aplicaciones remoto

Tecnologías de implementación

Las aplicaciones Web .NET suelen implementar uno o varios de los servicios lógicos mediante el uso de las siguientes tecnologías:

  • ASP.NET

  • Aplicación de Servicios Empresariales

  • Servicios Web

  • .NET Remoting

  • ADO.NET y Microsoft® SQL Server™ 2000

  • Seguridad del protocolo Internet (IPSec)

  • Secure Sockets Layer (SSL)

ASP.NET

ASP.NET suele utilizarse para implementar Servicios de usuarios. ASP.NET proporciona una arquitectura conectable que puede utilizarse para crear páginas Web. Para obtener más información acerca de ASP.NET, consulte los siguientes recursos:

Servicios Empresariales

La aplicación de Servicios Empresariales proporciona servicios de infraestructura a las aplicaciones. Entre ellos, figuran las transacciones distribuidas y servicios de administración de recursos como la agrupación de objetos para componentes de .NET. Para obtener más información acerca de la aplicación de Servicios Empresariales, consulte los siguientes recursos:

Servicios Web

Los servicios Web permiten el intercambio de datos y la invocación remota de lógica de aplicaciones mediante intercambios de mensajes basados en SOAP para transmitir datos por servidores de seguridad y entre sistemas heterogéneos. Para obtener más información acerca de los servicios Web, consulte los siguientes recursos:

.NET Remoting

.NET Remoting proporciona un marco de trabajo para el acceso a objetos distribuidos a través de los límites de procesos y equipos. Para obtener más información acerca de .NET Remoting, consulte los siguientes recursos:

ADO.NET y SQL Server 2000

ADO.NET proporciona servicios de acceso a datos. Su diseño es específico para aplicaciones Web distribuidas y ofrece compatibilidad para los escenarios inconexos que están intrínsicamente asociados a las aplicaciones Web. Para obtener más información acerca de ADO.NET, consulte los siguientes recursos:

SQL Server proporciona seguridad integrada que utiliza los mecanismos de autenticación del sistema operativo (Kerberos o NTLM). La autorización la proporcionan los inicios de sesión y los permisos granulares que se pueden aplicar a cada uno de los objetos de base de datos. Para obtener más información acerca de SQL Server 2000, consulte los siguientes recursos:

Seguridad del protocolo Internet (IPSec)

IPSec ofrece cifrado punto a punto de nivel de transporte y servicios de autenticación. Para obtener más información acerca de IPSec, consulte los siguientes recursos:

Secure Sockets Layer (SSL)

SSL ofrece un canal de comunicación punto a punto seguro. Los datos enviados por el canal se cifran. Para obtener más información acerca de SSL, consulte los siguientes recursos:

Arquitectura de seguridad

La ilustración 2.3 muestra el modelo de niveles de aplicaciones remoto junto con el conjunto de servicios de seguridad proporcionados por las diversas tecnologías que se presentaron anteriormente. La autenticación y la autorización tienen lugar en muchos puntos independientes de todos los niveles. Estos servicios los proporcionan principalmente los Servicios de Internet Information Server (IIS), ASP.NET, la aplicación de Servicios Empresariales y SQL Server. Los canales de comunicación segura se aplican también en todos los niveles y se extienden desde el explorador o dispositivo cliente directamente hasta la base de datos. Los canales se protegen con una combinación de Secure Sockets Layer (SSL) o IPSec.

imagen

Arquitectura de seguridad

Seguridad en los niveles

Las características de autenticación, autorización y comunicación segura proporcionadas por las tecnologías mencionadas anteriormente aparecen resumidas en la tabla 2.1.

Tabla 2.1: Características de seguridad

Tecnología

Autenticación

Autorización

Comunicación segura

IIS

Anónima

Básica

Implícita

Integrada en Windows (Kerberos/NTLM)

Certificados

Restricciones de direcciones IP/DNS

Permisos Web

Permisos NTFS; listas de control de acceso (ACL) de Windows en archivos solicitados

SSL

ASP.NET

Ninguna (personalizada)

Windows

Formularios

Passport

Autorización de archivos

Autorización de direcciones URL

Permisos de principales

Funciones de .NET

.

Servicios Web

Windows

Ninguna (personalizada)

Autenticación de mensajes

Autorización de archivos

Autorización de direcciones URL

Permisos de principales

Funciones de .NET

Cifrado SSL y de mensajes

Remoting

Windows

Autorización de archivos

Autorización de direcciones URL

Permisos de principales

Funciones de .NET

Cifrado SSL y de mensajes

Servicios
Empresariales

Windows

Funciones de Servicios Empresariales (COM+)

Permisos NTFS

Cifrado de llamada a procedimiento remoto (RPC)

SQL Server 2000

Windows (Kerberos/NTLM)

Autenticación de SQL

Inicios de sesión en el servidor

Inicios de sesión en la base de datos

Funciones fijas de base de datos

Funciones definidas por el usuario

Funciones de aplicación

Permisos de objetos

SSL

Windows 2000

Kerberos NTLM

ACL de Windows

IPSec

Autenticación

.NET Framework en Windows 2000 proporciona las siguientes opciones de autenticación:

  • Modos de autenticación de ASP.NET

  • Autenticación de la aplicación de Servicios Empresariales

  • Autenticación de SQL Server

Modos de autenticación de ASP.NET

La autenticación de ASP.NET incluye Windows, Formularios, Passport y Ninguna.

  • Autenticación de Windows. Con este modo de autenticación, ASP.NET depende de IIS para la autenticación de usuarios y la creación de un testigo de acceso de Windows para representar la identidad autenticada. IIS ofrece los siguientes mecanismos de autenticación:

  • Autenticación básica. La autenticación básica requiere que el usuario proporcione credenciales en forma de nombre de usuario y contraseña para probar su identidad. Se trata de una propuesta de estándar de Internet basada en RFC 2617: http://www.faqs.org/rfcs/rfc2617.html. Tanto Netscape Navigator como Microsoft Internet Explorer admiten la autenticación básica. Las credenciales del usuario se transmiten del explorador al servidor Web en un formato codificado en Base64 no cifrado. Puesto que el servidor Web obtiene las credenciales del usuario sin cifrar, puede emitir llamadas remotas (por ejemplo, para obtener acceso a equipos y recursos remotos) con las credenciales del usuario.

    Nota

    La autenticación básica debe utilizarse únicamente de forma conjunta con un canal seguro (que se suele establecer mediante SSL). De lo contrario, los nombres de usuario y las contraseñas podrían robarse fácilmente con software de supervisión de redes. Si utiliza la autenticación básica, deberá utilizar SSL en todas las páginas (y no sólo en páginas de inicio de sesión) porque las credenciales se transmiten en todas las peticiones posteriores. Para obtener más información acerca de cómo utilizar la autenticación básica con SSL, consulte el capítulo 8, "Seguridad de ASP.NET".

  • Autenticación implícita. La autenticación implícita, que se introdujo con IIS 5.0, es parecida a la autenticación básica, excepto en que en lugar de transmitir las credenciales del usuario sin cifrar del explorador al servidor Web, se transmite un hash de las credenciales. Como consecuencia, es más segura, aunque requiere un cliente Internet Explorer 5.0 o posterior y una configuración específica de servidor.

  • Autenticación de Windows integrada. La autenticación de Windows integrada (Kerberos o NTLM en función de la configuración de cliente y servidor) utiliza un intercambio criptográfico con el explorador Web Internet Explorer del usuario para confirmar la identidad del usuario. Sólo es compatible con Internet Explorer (no con Netscape Navigator) y, por lo tanto, suele utilizarse solamente en escenarios de intranet, en los que se puede controlar el software de cliente. La utiliza únicamente el servidor Web cuando se deshabilita el acceso anónimo o cuando se deniega el acceso anónimo mediante permisos de sistema de archivos de Windows.

  • Autenticación de certificados. La autenticación de certificados utiliza certificados de cliente para confirmar la identidad de los usuarios. El certificado de cliente se transmite del explorador del usuario (o aplicación cliente) al servidor Web. (En el caso de los servicios Web, el cliente de servicios Web transmite el certificado mediante la propiedad ClientCertificates del objeto HttpWebRequest.) A continuación, el servidor Web extrae la identidad del usuario del certificado. Este enfoque depende de la instalación de un certificado de cliente en el equipo del usuario y, por lo tanto, suele utilizarse casi siempre en escenarios de intranet o extranet en los que la población de usuarios se conoce bien y está controlada. Tras la recepción de un certificado de cliente, IIS puede asignar el certificado a una cuenta de Windows.

  • Autenticación anónima. Si no necesita autenticar los clientes (o implementa un esquema de autenticación personalizado), puede configurar IIS para que utilice la autenticación anónima. En este caso, el servidor Web crea un testigo de acceso de Windows para representar a todos los usuarios anónimos con la misma cuenta anónima (o de invitado). La cuenta anónima predeterminada es IUSR_NOMBREEQUIPO, en la que NOMBREEQUIPO es el nombre NetBIOS del equipo que se especificó durante la instalación.

  • Autenticación de Passport. En este modo de autenticación, ASP.NET utiliza los servicios de autenticación centralizados de Microsoft Passport. ASP.NET proporciona una práctica funcionalidad de empaquetador expuesta por el Kit de desarrollo de software (SDK) de Microsoft Passport, que debe estar instalado en el servidor Web.

  • Autenticación mediante Formularios. Este enfoque utiliza la redirección de cliente para enviar usuarios no autenticados a un formulario HTML especificado que les permite introducir sus credenciales (normalmente el nombre de usuario y la contraseña). A continuación, se validan las credenciales y se genera y devuelve al cliente un vale de autenticación. El vale de autenticación mantiene la identidad del usuario y, opcionalmente, una lista de funciones de las que es miembro el usuario durante toda la sesión del mismo.La autenticación mediante Formularios se utiliza en ocasiones sólo para la personalización de sitios Web. En este caso, no necesitará escribir demasiado código personalizado, puesto que ASP.NET realiza la mayor parte del proceso de forma automática con una configuración sencilla. En los escenarios de personalización, la cookie sólo necesita contener el nombre de usuario.

    Nota

    La autenticación mediante Formularios envía el nombre de usuario y la contraseña al servidor Web en texto sin formato. Por lo tanto, deberá utilizar la autenticación mediante Formularios conjuntamente con un canal protegido con SSL. Para mantener la protección de la cookie de autenticación transmitida en peticiones posteriores, deberá considerar la posibilidad de utilizar SSL en todas las páginas de la aplicación y no sólo la página de inicio de sesión.

  • Ninguna. Indica que no desea autenticar usuarios o que utiliza un protocolo de autenticación personalizado.

Más información

Para obtener más información acerca de la autenticación de ASP.NET, consulte el capítulo 8, "Seguridad de ASP.NET".

Autenticación de la aplicación de Servicios Empresariales

La autenticación de la aplicación de Servicios Empresariales se lleva a cabo mediante la infraestructura de transporte de llamada a procedimiento remoto (RPC) subyacente, que a su vez utiliza la Interfaz del proveedor de servicios de seguridad (SSPI, Security Service Provider Interface) del sistema operativo. Para autenticar los clientes de aplicaciones de Servicios Empresariales, puede utilizarse la autenticación Kerberos o NTLM.

Un componente revisado puede estar alojado en una aplicación de biblioteca o de servidor. Las aplicaciones de biblioteca se alojan en procesos de cliente y, por lo tanto, asumen la identidad del cliente. Las aplicaciones de servidor se ejecutan en procesos de servidor independientes con su propia identidad. Para obtener más información acerca de las identidades, consulte la sección "Identidades y principales" más adelante en este capítulo.

Las llamadas entrantes a un componente revisado pueden autenticarse en los siguientes niveles:

  • Predeterminado: se utiliza el nivel de autenticación predeterminado para el paquete de seguridad.

  • Ninguno: no se lleva a cabo ninguna autenticación.

  • Conexión: la autenticación se realiza sólo cuando se establece la conexión.

  • Llamada: la autenticación se lleva a cabo al inicio de cada llamada a procedimiento remoto.

  • Paquete: autentica y verifica la recepción de todos los datos de llamada.

  • Integridad de paquete: autentica y verifica que no se ha modificado ningún dato durante la transmisión.

  • Privacidad de paquete: autentica y cifra el paquete, incluidos los datos y la identidad y la firma del remitente.

Más información

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

Autenticación de SQL Server

SQL Server puede autenticar usuarios mediante la autenticación de Windows (NTLM o Kerberos) o utilizar su propio esquema de autenticación integrado, que se denomina autenticación de SQL. Están disponibles estas dos opciones:

  • SQL Server y Windows. Los clientes pueden conectarse a una instancia de Microsoft SQL Server mediante la autenticación de SQL Server o la autenticación de Windows. Se denomina en ocasiones autenticación de modo mixto.

  • Sólo Windows. El usuario debe conectarse a la instancia de Microsoft SQL Server mediante la autenticación de Windows.

Más información

Las ventajas relativas de cada enfoque se tratan en el capítulo 12, "Seguridad del acceso a datos".

Autorización

.NET Framework en Windows 2000 proporciona las siguientes opciones de autorización:

  • Opciones de autorización de ASP.NET

  • Autorización de la aplicación de Servicios Empresariales

  • Autorización de SQL Server

Opciones de autorización de ASP.NET

Las opciones de autorización de ASP.NET pueden utilizarlas las aplicaciones Web ASP.NET, los servicios Web y los componentes remotos. ASP.NET proporciona las siguientes opciones de autorización:

  • Autorización de direcciones URL. Se trata de un mecanismo de autorización establecido por opciones de configuración de archivos de configuración de equipos y aplicaciones. La autorización de direcciones URL permite restringir el acceso a determinados archivos y carpetas del espacio de nombres del Identificador de recursos uniforme (URI) de la aplicación. Por ejemplo, puede denegar o permitir el acceso de forma selectiva de determinados usuarios a carpetas o archivos específicos (indicados por medio de una dirección URL). También puede restringir el acceso en función de la pertenencia a funciones del usuario y el tipo de verbo HTTP utilizado para emitir una petición (GET, POST, etc.).

    La autorización de direcciones URL requiere una identidad autenticada. Para obtenerla, puede utilizarse un esquema de autenticación de Windows o basado en vales.

  • Autorización de archivos. La autorización de archivos se aplica solamente si se utiliza uno de los mecanismos de autenticación de Windows proporcionados por IIS para autenticar llamadores y si ASP.NET se ha configurado para utilizar la autenticación de Windows.
    Puede utilizarla para restringir el acceso a archivos específicos de un servidor Web. Los permisos de acceso los determinan las listas de control de acceso de Windows adjuntas a los archivos.

  • Peticiones de permisos de principales. Las peticiones de permisos de principales pueden utilizarse (mediante declaraciones o programación) como mecanismo de control de acceso adicional específico. Permiten controlar el acceso a clases, métodos o bloques de código individuales en función de la identidad y la pertenencia a grupos de cada usuario.

  • Funciones de .NET. Las funciones de .NET sirven para agrupar usuarios que tienen los mismos permisos en la aplicación. Conceptualmente, se parecen a las implementaciones anteriores basadas en funciones, como por ejemplo, los grupos de Windows y las funciones de COM+. No obstante, a diferencia de estos enfoques previos, las funciones de .NET no requieren identidades de Windows autenticadas y pueden utilizarse con esquemas de autenticación basados en vales tales como la autenticación mediante Formularios.

    Las funciones de .NET pueden servir para controlar el acceso a recursos y operaciones y pueden configurarse mediante declaraciones y mediante programación.

Más información

Para obtener más información acerca de la autorización de ASP.NET, consulte el capítulo 8, "Seguridad de ASP.NET".

Autorización de la aplicación de Servicios Empresariales

El acceso a la funcionalidad de los componentes revisados de aplicaciones de Servicios Empresariales depende de la pertenencia a funciones de los Servicios Empresariales. Estas funciones son distintas de las funciones de .NET y pueden contener cuentas de grupo o de usuario de Windows. La pertenencia a funciones se define en el catálogo COM+ y se administra con la herramienta Servicios de componente.

Más información

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

Autorización de SQL Server

SQL Server acepta permisos específicos que pueden aplicarse a objetos de base de datos individuales. Los permisos pueden estar basados en la pertenencia a funciones (SQL Server proporciona funciones fijas de base de datos, funciones definidas por el usuario y funciones de aplicación) o se puede conceder permiso a cuentas de grupo y de usuario individuales de Windows.

Más información

Para obtener más información acerca de la autorización de SQL Server, consulte el capítulo 12, "Seguridad del acceso a datos".

Guardianes y puertas

El término guardián se utiliza en el resto del documento para identificar la tecnología de la que depende una puerta. Una puerta representa un punto de control de acceso (que protege un recurso) de una aplicación. Por ejemplo, un recurso podría ser una operación (representada por un método de un objeto) o un recurso de base de datos o de sistema de archivos.

Todas las tecnologías básicas mencionadas anteriormente proporcionan guardianes para la autorización de acceso. Las peticiones deben pasar por distintas puertas antes de permitírseles el acceso a la operación o al recurso solicitado. A continuación, se describen las puertas por las que deben pasar las solicitudes.

  • IIS proporciona una puerta cuando se autentican usuarios (es decir, cuando de deshabilita la autenticación anónima). Los permisos Web de IIS pueden utilizarse como mecanismo de control de acceso para restringir la capacidad de acceso de los usuarios Web a carpetas y archivos específicos. A diferencia de los permisos de archivos NTFS, los permisos Web se aplican a todos los usuarios Web, en lugar de a usuarios o grupos individuales. Los permisos de archivos NTFS ofrecen todavía más restricciones para recursos Web tales como las páginas Web, los archivos de imagen, etc. Estas restricciones se aplican a usuarios o grupos individuales.

IIS comprueba primero los permisos Web y después los permisos de archivos NTFS. El usuario debe estar autorizado por ambos mecanismos para poder obtener acceso al archivo o carpeta. Si se produce un error en la comprobación de permisos Web, IIS devuelve una respuesta HTTP 403 - Acceso prohibido, mientras que si se produce un error en la comprobación de permisos NTFS, IIS devuelve HTTP 401 - Acceso denegado.

  • ASP.NET proporciona varias puertas configurables y programables. Entre ellas figuran la autorización de direcciones URL, la autorización de archivos, las peticiones de permisos de principales y las funciones de .NET.

  • El guardián de la aplicación de Servicios Empresariales utiliza funciones de Servicios Empresariales para autorizar el acceso a la funcionalidad empresarial.

  • SQL Server 2000 incluye varias puertas con inicios de sesión en el servidor, inicios de sesión en la base de datos y permisos de objetos de base de datos.

  • Windows 2000 incluye puertas que utilizan ACL conectadas a recursos seguros.

En resumen, los guardianes llevan a cabo la autorización en función de la identidad del usuario o del servicio que llama a la puerta e intenta obtener acceso a un recurso específico. La ventaja del uso de varias puertas reside en un mayor nivel de seguridad gracias a las múltiples líneas de defensa que proporciona. La tabla 2.2 resume el conjunto de guardianes e identifica para cada uno de ellos las puertas de las que se encargan.

Tabla 2.2: Responsabilidades de los guardianes y las puertas que proporcionan

Guardián

Puertas

Sistema operativo Windows

Derechos de inicio de sesión (positivo y negativo, como por ejemplo “Denegar el inicio de sesión localmente”
Otros privilegios (por ejemplo "Actuar como parte del sistema operativo)
Controles de acceso de recursos protegidos como el registro y el sistema de archivos Los controles de acceso utilizan ACL conectadas a los recursos seguros que especifican los usuarios que pueden o no pueden tener acceso al recurso y también los tipos de operaciones que pueden realizar.
Filtrado TCP/IP
Seguridad IP

IIS

Autenticación (anónima, básica, implícita, integrada, certificados)
Restricciones de direcciones IP y nombres de dominio (pueden utilizarse como línea de defensa adicional, pero no se debe depender de ellas debido a la facilidad con que se pueden falsificar las direcciones IP)
Permisos Web
Permisos NTFS

ASP.NET

Autorización de direcciones URL
Autorización de archivos
Peticiones de permisos de principales
Funciones de .NET

Servicios Empresariales

Autenticación de Windows (NTLM / Kerberos)
Funciones de Servicios Empresariales (COM+)
Niveles de suplantación

Servicios Web

Utiliza puertas proporcionadas por IIS y ASP.NET.

Remoting

Utiliza puertas proporcionadas por el host. En caso de estar alojado en ASP.NET, utiliza las puertas proporcionadas por IIS y ASP.NET. Si está alojado en un servicio de Windows, deberá desarrollar una solución personalizada.

ADO.NET

Cadenas de conexión. Las credenciales pueden ser explícitas o puede utilizar autenticación de Windows (por ejemplo, si se conecta a SQL Server).

SQL Server

Inicios de sesión en el servidor
Inicios de sesión en la base de datos
Permisos de objetos de base de datos

Al usar las distintas puertas en todos los niveles de la aplicación, puede filtrar usuarios que deben poder tener acceso a los recursos de servidor. El alcance del acceso se ve reducido por la presencia de puertas sucesivas que se vuelven cada vez más granulares a medida que la petición pasa por la aplicación a los recursos de servidor.

Examine el ejemplo de aplicación basado en Internet con IIS que se muestra en la ilustración 2.4.

imagen

Ilustración 2.4
Filtrado de usuarios con guardianes

La ilustración 2.4 demuestra lo siguiente:

  • Puede deshabilitar la autenticación anónima en IIS. Como consecuencia, sólo se permite el acceso de cuentas que puede autenticar IIS. De este modo, se podría reducir el número de posibles usuarios a 10.000.

  • A continuación, se utiliza la autorización de direcciones URL en ASP.NET, lo que podría disminuir el número de usuarios a 1.000.

  • La autorización de archivos podría reducir el acceso todavía más a 100 usuarios

  • Finalmente, el código de la aplicación Web podría permitir el acceso al recurso restringido solamente a 10 usuarios en función de la pertenencia a funciones específicas.

Identidades y principales

La seguridad de .NET se compone de capas superpuestas sobre la seguridad de Windows. El concepto de seguridad centrado en los usuarios, en Windows, se basa en el contexto de seguridad proporcionado por una sesión de inicio, mientras que la seguridad de .NET se basa en objetos IPrincipal e IIdentity.

En la programación de Windows, cuando se desea conocer el contexto de seguridad en el que se ejecuta el código, se consulta la identidad del propietario del proceso o del subproceso en ejecución. Con la programación de .NET, si desea consultar el contexto de seguridad del usuario actual, tendrá que recuperar el objeto IPrincipal actual de Thread.CurrentPrincipal.

.NET Framework utiliza objetos de identidad y de principal para representar a los usuarios mientras se ejecuta código de .NET; ambos tipos de objetos constituyen la espina dorsal de la autorización basada en funciones de .NET.

Los objetos de identidad y de principal implementan las interfaces IIdentity e IPrincipal respectivamente. Estas interfaces se definen en el espacio de nombres System.Security.Principal. Las interfaces comunes permiten a .NET Framework tratar a los objetos de identidad y de principal de modo polimórfico, independientemente de la información de implementación subyacente.

La interfaz IPrincipal le permite probar la pertenencia a funciones mediante un método IsInRole y proporciona además acceso a un objeto IIdentity asociado.

public interface IPrincipal
{
  bool IsInRole( string role );
  IIdentity Identity {get;}
}

La interfaz IIdentity proporciona información adicional de autenticación, como el nombre y el tipo de autenticación.

public interface IIdentity
{
  string authenticationType {get;}
  bool IsAuthenticated {get;}
  string Name {get;}
}

.NET Framework incluye varias implementaciones concretas de IPrincipal e IIdentity, tal y como se muestra en la ilustración 2.5, que se describen en las siguientes secciones.

imagen

Ilustración 2.5
Clases de implementación de IPrincipal e IIdentity

WindowsPrincipal y WindowsIdentity

La versión de .NET de un contexto de seguridad de Windows está dividida en dos clases:

  • WindowsPrincipal. Esta clase almacena las funciones asociadas con el usuario actual de Windows. La implementación WindowsPrincipal trata los grupos de Windows como funciones. El método IPrncipal.IsInRole devuelve "true" o "false" en función de la pertenencia del usuario a grupos de Windows.

  • WindowsIdentity. Esta clase almacena la parte de la identidad del contexto de seguridad del usuario actual y puede obtenerse mediante el método estático WindowsIdentity.GetCurrent(). Éste devuelve un objeto WindowsIdentity con una propiedad Token que a su vez devuelve, al testigo de acceso asociado con el subproceso en ejecución, un valor de tipo IntPtr que representa un identificador de Windows. Este testigo puede pasarse entonces a funciones nativas de la interfaz de programación de aplicaciones (API) de Win32®, como GetTokenInformation, SetTokenInformation, CheckTokenMembership, etc., para recuperar información de seguridad acerca del testigo.

Nota

el método estático WindowsIdentity.GetCurrent() devuelve la identidad del subproceso en ejecución, que podría tratarse o no de una suplantación. Se parece en este sentido a la API GetUserName de Win32.

GenericPrincipal y objetos de identidad asociados

Estas implementaciones son muy sencillas y las utilizan las aplicaciones que no usan la autenticación de Windows y cuando la aplicación no necesita representaciones complejas de un principal. Pueden crearse fácilmente mediante programación y, por lo tanto, deberá existir una cierto grado de confianza cuando una aplicación use un objeto GenericPrincipal.

Si va a basarse en el uso del método IsInRole de GenericPrincipal para tomar decisiones de autorización, deberá confiar en la aplicación que le envía el objeto GenericPrincipal. Esto contrasta con el uso de objetos WindowsPrincipal, con los que debe confiar en que el sistema operativo proporcione un objeto WindowsPrincipal válido con una identidad autenticada y nombres de grupo o de función válidos.

Los tipos siguientes de objeto de identidad pueden asociarse a la clase GenericPrincipal:

  • FormsIdentity. Esta clase representa a una identidad que se ha autenticado con la autenticación mediante Formularios. Contiene un FormsAuthenticationTicket que a su vez contiene información acerca de la sesión de autenticación del usuario.

  • PassportIdentity. Esta clase representa a una identidad que se ha autenticado mediante la autenticación de Passport y que contiene información de perfil de Passport.

  • GenericIdentity. Esta clase representa a un usuario lógico que no está asociado a ninguna tecnología de sistema operativo concreta y que se suele utilizar de forma conjunta con mecanismos de autenticación y autorización personalizados.

ASP.NET y HttpContext.User

Normalmente, Thread.CurrentPrincipal se comprueba en el código de .NET antes de tomar cualquier decisión de autorización. No obstante, ASP.NET proporciona el contexto de seguridad del usuario autenticado mediante HttpContext.User.

Esta propiedad acepta y devuelve una interfaz IPrincipal. La propiedad contiene un usuario autenticado para la petición actual. ASP.NET recupera HttpContext.User cuando toma decisiones de autorización.

Al utilizar la autenticación de Windows, el módulo de autenticación de Windows construye de forma automática un objeto WindowsPrincipal y lo almacena en HttpContext.User. Si utiliza otros mecanismos de autenticación, como Formularios o Passport, deberá construir un objeto GenericPrincipal y almacenarlo en HttpContext.User.

Identidades de ASP.NET

En cualquier punto de la ejecución de una aplicación Web ASP.NET, pueden estar presentes varias identidades durante una sola petición. Entre estas identidades, figuran:

  • HttpContext.User devuelve un objeto IPrincipal que contiene información de seguridad para la petición Web actual. Se trata del cliente Web autenticado.

  • WindowsIdentity.GetCurrent() devuelve la identidad del contexto de seguridad del subproceso de Win32 en ejecución. Esta identidad es siempre ASPNET de forma predeterminada, que es la cuenta predeterminada que se utiliza para ejecutar aplicaciones Web ASP.NET. No obstante, si la aplicación Web se ha configurado para la suplantación, la identidad representa al usuario autenticado (que es IUSR_EQUIPO, si está activada la autenticación anónima de IIS).

  • Thread.CurrentPrincipal devuelve el principal del subproceso de .NET en ejecución que se superpone al subproceso de Win32.

Más información

  • Para ver un análisis detallado de la identidad de ASP.NET para una combinación de configuraciones de aplicaciones Web (con y sin suplantación), consulte "Matriz de identidades de ASP.NET" en la sección "Referencia" de esta guía.

  • Para obtener más información acerca de cómo crear su propia implementación de IPrincipal, consulte el capítulo 8, "Seguridad de ASP.NET", y "Cómo implementar IPrincipal" en la sección "Referencia" de esta guía.

Remoting y Servicios Web

En la versión actual de .NET Framework, Remoting y los servicios Web no tienen su propio modelo de seguridad. Ambos heredan las características de seguridad de IIS y ASP.NET.

Aunque la arquitectura de remoting no tiene integrada la seguridad, sí que se diseñó teniendo en cuenta la seguridad. La incorporación de determinados niveles de seguridad en las aplicaciones de remoting depende del desarrollador o del administrador. El paso de objetos de principal a través de los límites de remoting depende de la ubicación del cliente y del objeto remoto. Por ejemplo:

  • Remoting en el mismo proceso. Cuando remoting se utiliza entre objetos del mismo dominio o dominios de aplicación o entre dominios independientes, la infraestructura de remoting copia en el contexto del receptor una referencia al objeto IPrincipal asociado con el contexto del llamador.

  • Remoting entre procesos. En este caso, los objetos IPrincipal no se transmiten de un proceso a otro. Las credenciales utilizadas para construir el objeto IPrincipal original deben transmitirse al proceso remoto, que puede estar ubicado en un equipo independiente. Esto permite al equipo remoto construir un objeto IPrincipal adecuado basado en las credenciales suministradas.

Conclusión

Este capítulo ha presentado el conjunto completo de opciones de autenticación y autorización proporcionadas por las distintas tecnologías relacionadas con .NET. Gracias al uso de varios guardianes en la aplicación Web .NET, podrá implementar una estrategia de seguridad defensiva avanzada. Para resumir:

  • Las aplicaciones ASP.NET pueden utilizar las características de seguridad existentes proporcionadas por Windows e IIS.

  • Puede utilizar una combinación de SSL e IPSec para proporcionar comunicaciones seguras entre las capas de una aplicación Web .NET, como por ejemplo, del explorador a la base de datos.

  • Utilice SSL para proteger las credenciales de texto no cifrado que se transmiten por la red al utilizar la autenticación básica o mediante Formularios.

  • .NET representa a los usuarios que se han identificado con la autenticación de Windows mediante una combinación de las clases WindowsPrincipal y WindowsIdentity.

  • Las clases GenericPrincipal y GenericIdentity o FormsIdentity sirven para representar a usuarios que se han identificado con esquemas de autenticación distintos de los de Windows, como la autenticación mediante Formularios.

  • Puede crear sus propias implementaciones de principal e identidad mediante la creación de clases que implementan IPrincipal e IIdentity.

  • En las aplicaciones Web ASP.NET, el objeto IPrincipal que representa al usuario autenticado se asocia a la petición Web HTTP actual mediante la propiedad HttpContext.User.

  • Las puertas son puntos de control de acceso de la aplicación a través de las cuales los usuarios autorizados pueden obtener acceso a recursos o servicios. Los guardianes se encargan de controlar el acceso a las puertas.

  • Utilice varios guardianes para proporcionar una estrategia defensiva avanzada.

El capítulo siguiente (Capítulo 3 - "Autenticación y autorización") proporciona información adicional para ayudarle a seleccionar la estrategia de autenticación y autorización más adecuada a su escenario de aplicaciones concreto.

Mostrar:
© 2015 Microsoft