Diseño de Aplicaciones - Directivas de Seguridad, Administración Operativa y Comunicaciones Cap III

Diseño de aplicaciones y servicios http://msdn.microsoft.com/es-es/library/ms978357(printer).
aspx
©2009 Microsoft Corporation. All rights reserved.
Diseño de aplicaciones y servicios

Publicado: 26 de junio de 2006
Patterns & Practices

Microsoft Corporation
Diciembre de 2002
http://msdn.microsoft.com/practices/ [ http://msdn.microsoft.com/practices/default.aspx ]
Resumen: en este capítulo se describen las directivas relativas a la seguridad, administración operativa y
comunicaciones que afectan al diseño de una aplicación o un servicio .NET distribuidos.
Las directivas de organización definen las reglas que determinan la forma en que se protege una aplicación, el
modo en que se administra, así como la forma en que los distintos componentes de una aplicación se
comunican entre sí y con los servicios externos. Las directivas afectan al diseño de cada capa de la aplicación
o servicio, tal como se muestra en la figura 3.1.
Figura 3.1. Efecto de las directivas organizativas en el diseño de aplicaciones
Las directivas no sólo se determinan a nivel organizativo, sino que también se pueden establecer dentro de
las organizaciones. En ciertos casos, resulta útil recurrir al concepto de zonas: todas las aplicaciones, servicios
o incluso niveles de la aplicación se encuentran en la misma zona si comparten un subconjunto de las
directivas. Por ejemplo, un centro de datos de Internet puede tener un conjunto de directivas distinto al del
resto de infraestructura de una compañía y definir una zona especial con unas restricciones de seguridad más
estrictas que las de otras partes de la aplicación. De este modo, las aplicaciones y servicios de este centro de
datos se encontrarán en una zona diferente a la de las aplicaciones y servicios de la intranet. El conocimiento
de las directivas de cada componente, lo que permite definir las zonas en las que éste se ejecutará,
constituye un aspecto fundamental a la hora de determinar dónde se implementarán los componentes.
Este es el capítulo 3 de Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios. Comience
1 de 32 08/10/2009 05:31 p.m.

Diseño de aplicaciones y servicios http://msdn.microsoft.com/es-es/library/ms978357(printer).aspx
por aquí [ http://msdn.microsoft.com/es-es/library/ms978340.aspx ] para obtener una visión general

completa.
En esta página
Diseño de la directiva de seguridad

Diseño de la directiva de administración operativa
Diseño de la directiva de comunicaciones
Próximamente
Diseño de la directiva de seguridad
La directiva de seguridad se ocupa de la autenticación, autorización, comunicación segura, auditoría y

administración de perfiles, tal como muestra la figura 3.2.
Figura 3.2. Aspectos de la directiva de seguridad
Principios generales sobre seguridad
Existen ciertos principios generales sobre seguridad que se deben tener en cuenta a la hora de desarrollar una
directiva de seguridad. Tenga en cuenta las siguientes directrices:
Siempre que sea posible, debe recurrir a sistemas de seguridad que se hayan comprobado y
demostrado su eficacia en lugar de generar su propia solución personalizada. Utilice los
algoritmos, técnicas e infraestructura suministrada con la plataforma que se hayan probado
dentro del sector, así como tecnologías compatibles y comprobadas por los proveedores. Si decide
realizar un desarrollo personalizado de la infraestructura de seguridad, valide su enfoque y
técnicas mediante auditoría con expertos y organizaciones que se dedican a la revisión de la
seguridad, antes y después de su implementación.
Nunca confíe en las aportaciones externas. Deberá validar todos los datos que introduzcan los
usuarios o envíen otros servicios.
Considere por principio que los sistemas externos no son seguros. Si su aplicación recibe datos
confidenciales sin cifrar desde un sistema externo, asuma que dicha información no es segura.
Aplique el principio del menor privilegio. No habilite más atributos en las cuentas de servicios que
los que resulten estrictamente necesarios para la aplicación. Obtenga acceso a los recursos con
cuentas que tengan los mínimos permisos necesarios.
Reduzca el área de superficie. El riesgo se incrementa según aumenta el número de componentes

y datos que haya expuesto a través de la aplicación y, por lo tanto, deberá exponer únicamente la
funcionalidad que crea que otros van a utilizar.
Establezca como predeterminado un modo seguro. No habilite servicios, tecnologías y derechos

de cuenta que no sean absolutamente necesarios. Cuando implemente la aplicación en equipos
cliente o servidor, la configuración predeterminada de ésta deberá ser segura.
No confíe en la seguridad a través del ocultamiento. El cifrado de los datos implica disponer de
claves y de un algoritmo de cifrado demostrado. El almacenamiento de los datos seguros evitará
el acceso a ésta en cualquier circunstancia. No se puede considerar seguridad la mezcla de
diversas cadenas, el almacenamiento de la información en rutas de archivo inesperadas y demás
técnicas similares.
Siga los principios de STRIDE. (STRIDE responde a las siglas inglesas de Simulación, Alteración,
Repudio, Revelación de información, Denegación de servicio y Elevación de privilegios). Todas
estas son clases de vulnerabilidades de la seguridad contra los que un sistema se debe proteger.
Si desea obtener más información sobre STRIDE, consulte "Designing for Securability" (en inglés)
en MSDN en http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7
2 de 32 08/10/2009 05:31 p.m.

/html/vxcondesigningforsecurability.asp [ http://msdn.microsoft.com/library
/default.asp.aspx?url=/library/en-us/vsent7/html/vxcondesigningforsecurability.asp ] .
Realice la comprobación desde la misma puerta. No permita que los procesos vayan más allá del
lugar para el que los usuarios están autorizados.
Bloquee su sistema interna y externamente: los usuarios y operadores internos pueden

representar un riesgo igual que los intrusos externos.
Autenticación
La autenticación se define como identificación segura, que básicamente quiere decir que dispone de un
mecanismo para identificar con seguridad a los usuarios que se adecua a los requisitos de seguridad de su
aplicación
La autenticación se debe implementar en la capa de la interfaz de usuario para proporcionar funciones de

autorización, auditoría y personalización. Esto generalmente requiere que el usuario escriba sus credenciales
(como por ejemplo, nombre y contraseña) para demostrar su identidad. Entre otros tipos de credenciales se
incluyen las lecturas biométricas, tarjetas inteligentes, claves físicas, certificados digitales, etc.
Si su aplicación se expone como servicio, probablemente desee autenticar también en ciertas interfaces de
servicio para asegurarse de que se compromete en un intercambio con un socio conocido y de confianza, así
como que otros servicios externos no simulan su aplicación para hacer creer que quien llama es otra persona.
Nota
Para obtener más información sobre la autenticación de llamadores con Microsoft® ASP.NET, consulte
"Autenticación en ASP.NET: Directrices de seguridad para .NET [ http://www.microsoft.com/spanish
/msdn/articulos/archivo/261001/voices/authaspdotnet.asp ] " en MSDN
En su diseño, debe perseguir como objetivo disponer de una lógica empresarial que sea transparente en el
proceso de autenticación. Por ejemplo, no es aconsejable tener un parámetro adicional en los métodos de
componentes sólo para pasar información del usuario, a menos que la función empresarial lo requiera.
Flujo de la identidad entre los niveles
Cuanto más lejos del usuario se encuentra una parte de la funcionalidad, menos significativa se vuelve la
identidad de éste. En una solución basada en servicios, puede que algunas actividades ni siquiera las inicie
un usuario. El objetivo de su diseño debe ser reducir la relevancia del usuario llamador cuanto más lejos de la
interfaz de usuario esté la actividad.
Puede que necesite establecer un flujo de las identidades de los llamadores originales (usuarios o servicios) a
través de las capas de la aplicación para realizar la autorización o auditoría. La identidad puede ser la de un
llamador original (usuario o servicio), o bien una cuenta de servicio de un nivel de aplicación. Para establecer
el flujo de la identidad, puede permitir que el mecanismo de comunicación establezca el flujo del contexto de
seguridad (por ejemplo, mediante el uso de la delegación de Kerberos junto con la interacción remota de
DCOM), puede pasar símbolos (tokens) o vales de autenticación, o bien el Id. o las credenciales del usuario.
Considere los siguientes escenarios:
El llamador y la aplicación a la que se llama no comparten el subsistema de seguridad de la

plataforma o un mecanismo de autenticación común. En este escenario, no puede "fluir" un
contexto de seguridad existente; deberá volver a autenticar pasando las credenciales apropiadas.
El llamador y la aplicación a la que se llama se encuentran en dominios de Microsoft Windows®

de confianza, o bien la aplicación realiza la autorización basada en identidades de Windows o
utiliza funciones de Microsoft .NET Enterprise Services. En este escenario, necesitará elegir un
mecanismo de comunicación que establezca el flujo de vales de Kerberos o símbolos de NTLM.
DCOM-RPC proporciona esta capacidad. Mediante el uso de la información que proporciona el
canal, puede volver a crear su principal personalizado y adjuntarlo al subproceso basado en la
información de la autenticación. Tenga en cuenta que los símbolos de NTLM sólo se pueden
utilizar a través de un solo salto de red para la autenticación y que la delegación de Kerberos
requiere directivas en los niveles de equipo, usuario y dominio. Si desea obtener más
información, consulte "Diseño de la directiva de comunicaciones" en este mismo capítulo, o bien,
los siguientes artículos:
Windows 2000 Kerberos Delegation [ http://msdn.microsoft.com/library

/default.asp.aspx?url=/library/en-us/secauthn/security/microsoft_kerberos.asp ]
Impersonating and Reverting [ http://msdn.microsoft.com/library
3 de 32 08/10/2009 05:31 p.m.

/default.asp.aspx?url=/library/en-us/cpguide/html/cpconImpersonatingReverting.asp
]
El llamador y la aplicación a la que se llama comparten un mecanismo de autenticación que no

pertenece a Windows como, por ejemplo, una solución con un inicio de sesión único o un servicio
Web centralizado que autentica a los usuarios. En este escenario, establece el flujo de símbolos o
tokens que proporciona el servicio de autenticación. Debe pasar estos símbolos en mecanismos
fuera de banda (no en parámetros de funciones) como, por ejemplo, en encabezados SOAP. El
mecanismo de autenticación debe autenticar al usuario cuando se le presenta un símbolo válido;
lo que implica que los símbolos que autentica no tienen afinidad con el equipo de origen.
Asimismo, se debe asegurar de que los símbolos se pueden autenticar en una ventana de tiempo
suficientemente amplia, especialmente en transacciones de ejecución larga. Los símbolos se
producen a menudo con un hash de las credenciales del usuario y un valor salt. Para obtener la
definición del valor salt, consulte el glosario sobre seguridad [ http://msdn.microsoft.com/library
/default.asp.aspx?url=/library/en-us/secgloss/security/n_gly.asp ] en MSDN
El llamador y la aplicación a la que se llama se ejecutan en el mismo contexto. En este escenario,

Microsoft .NET realiza la llamada, manteniendo el objeto CurrentPrincipal existente en el
subproceso. Este es el caso de todas las actividades dentro del mismo dominio de aplicación y
para las llamadas a las aplicaciones basadas en Enterprise Services con la activación de
biblioteca.
Autenticación con otros servicios
Puede que su aplicación necesite invocar diferentes servicios en nombre de un determinado usuario. Los
esquemas de servidor de inicio de sesión único asignan símbolos y/o credenciales de un usuario determinado
para un conjunto de servicios o almacenes de datos. Por ejemplo, su aplicación podría autenticar a un usuario
llamado "Jose", quien podría obtener acceso a un almacén de datos heredados en el que iniciase sesión como
"Pepe". Se recomienda que diseñe la aplicación o servicio de forma que tenga acceso a otros almacenes de
datos y otros servicios mediante cuentas de servicio (por ejemplo, "SalesApplication") en lugar de representar
al usuario original; sin embargo, los estrictos requisitos de seguridad que impone la organización pueden
hacer imposible esta opción. El desarrollo de características de asignación de cuentas puede resultar
complejo, especialmente si necesita administrar credenciales, ya que, por lo general, las cuentas de usuario
se deben mantener sincronizadas. No obstante, se pueden utilizar con gran eficacia algunos mecanismos de
asignación de cuentas, como por ejemplo la asignación de los certificados de cliente a cuentas de Windows
mediante el uso de Servicios de Internet Information Services (IIS) de Microsoft.
Si necesita representar cuentas de usuario con su propio código, el proceso actual deberá poder realizar una
llamada a LogonUser, lo que en Windows 2000 requiere que la cuenta de usuario de proceso tenga privilegios
"que actúen como parte del sistema operativo". Se trata de un privilegio muy fuerte y plantea un gran riesgo
si el proceso se ve en peligro. No se recomienda que utilice este privilegio para las identidades de las
aplicaciones basadas en ASP.NET o Enterprise Services, excepto en casos excepcionales.
Mecanismos de autenticación personalizada
Puede que necesite un mecanismo de autenticación personalizada en su aplicación si ha comprobado que no

puede aprovechar un mecanismo de autenticación proporcionado por la plataforma o por terceros. El uso de
un mecanismo de autenticación personalizada implica poder almacenar cuentas de usuario, así como tener un
algoritmo para comprobar si el sistema autentica las credenciales que se proporcionan. Cuando implemente
su propia autenticación de usuario, tenga en cuenta las siguientes directrices generales:
Implemente la autenticación de usuario en un objeto Identity personalizado. Deberá disponer de

un constructor que tome las credenciales de usuario y establezca el indicador interno de
IIdentity.IsAuthenticated según el resultado. También puede tener un constructor que tome un
símbolo de autenticación.
No almacene las contraseñas de usuario. En su lugar, almacene un hash de las credenciales del
usuario junto con los valores salt en la base de datos. Cuando autentique, aplique el mismo
algoritmo a las credenciales que proporciona el usuario. Si la cadena resultante coincide con la
que ha almacenado en la base de datos, el usuario habrá suministrado las credenciales correctas.
Realice una auditoría de los intentos de autenticación que han producido errores.
Agregue un atributo StrongNameIdentityPermission a los métodos cuando desee asegurarse de

que únicamente los ensamblados de la aplicación puedan crear e invocar su objeto de identidad.
Exponga el símbolo de autenticación como propiedad del objeto Identity. El símbolo de

autenticación debe ser un hash que incluya el nombre de usuario y otros datos. Incluya datos de
origen (como, por ejemplo, el nombre del equipo o el ensamblado de llamada) si desea impedir
4 de 32 08/10/2009 05:31 p.m.

que el símbolo se utilice en otro lugar. Para limitar la validez del símbolo a un cierto límite de
tiempo, puede agregar una marca de hora al valor en hash. La complejidad del valor hash y del
cifrado dependerá del grado de riesgo que tenga el símbolo.
Autenticación en la capa de presentación
Los componentes de la interfaz de usuario deben autenticar al usuario si la aplicación necesita realizar la
autorización, auditoría o personalización. Existe una amplia gama de mecanismos de autenticación
disponibles para las interfaces de usuario basadas en Web. Para elegir la más adecuada a su escenario,
consulte "Autenticación en ASP.NET: Directrices de seguridad para .NET" en MSDN
(http://www.microsoft.com/spain/msdn/articulos/archivo/261001/voices/authaspdotnet.asp [
http://www.microsoft.com/spanish/msdn/articulos/archivo/261001/voices/authaspdotnet.asp ] ). Las
aplicaciones basadas en ASP.NET establecen el principal actual en el evento OnAuthenticate de Global.asax.
Las interfaces de usuario basadas en Windows generalmente confían en un mecanismo de autenticación

personalizado (en el que la aplicación solicita un nombre de usuario y una contraseña), o bien autentican al
usuario con el inicio de sesión de Windows. Si utiliza un mecanismo de autenticación personalizado, deberá
implementar su propia interfaz de usuario para permitir al usuario iniciar sesión, así como establecer el
Principal correcto en el subproceso principal y en cualquier subproceso que cree la aplicación.
Los componentes del proceso de usuario no realizan autenticación; confían en el contexto de seguridad que se
establece al inicio de la aplicación, tal como se ha descrito anteriormente (por ejemplo, en el evento
OnAuthenticate de una aplicación basada en ASP.NET).
Los componentes de proceso de usuarios se deben ejecutar en el mismo contexto de usuario que la propia
interfaz de usuario, de forma que todas las tareas de autenticación se deleguen a la interfaz de usuario o
incluso a la infraestructura de procesamiento. Por ejemplo, en ASP.NET cualquier solicitud de una página
ASPX provoca que IIS solicite las credenciales de autenticación, o bien que ASP.NET redirija al usuario a una
página de autenticación basada en formularios. Esta operación se realiza con transparencia en cualquier capa
de proceso de usuario y no interrumpe el flujo de estado, ni siquiera cuando caduca y se debe volver a
establecer una sesión autenticada.
Autenticación en los componentes empresariales
Los componentes empresariales deben autenticar al llamador o delegar la autenticación a una interfaz de
servicios. El llamador puede ser de distintos tipos, por ejemplo:
Un componente de interfaz de usuario
Un componente de proceso de usuario
Un flujo de trabajo empresarial (por ejemplo, una programación XLANG de Microsoft BizTalk
Server®).
Otro componente de proceso empresarial
La identidad del llamador puede ser:
Un usuario particular.
Una cuenta de servicio que represente la identidad en tiempo de ejecución de una determinada
parte de la aplicación o de un sistema externo. Por ejemplo, podría autenticar una llamada que
provenga del nivel de IU Web.
Un socio externo para el que tiene una "cuenta de servicio" especial.
Si los componentes empresariales autentican a los llamadores, deberá considerar cómo se pueden autenticar
las tres identidades de llamadores anteriores y de qué modo afectan a la autorización.
Autenticación en los componentes de acceso a datos
Los componentes de acceso a datos están diseñados para que los utilicen otros componentes de la aplicación
o servicio. Generalmente, no están ideados para la exposición para las llamadas desde secuencias de
comandos o desde otras aplicaciones, de modo que puede diseñarlos para que se basen en el contexto de
seguridad establecido por el llamador (el objeto Principal del subproceso) o en el mecanismo de autenticación
de la estrategia remota.
Los componentes de acceso a datos pueden autenticar con la base de datos de dos formas principales:
Mediante el uso de cuentas de servicios.
5 de 32 08/10/2009 05:31 p.m.

Representando al llamador.
En este caso, utiliza una cuenta de servicios, o un conjunto limitado de ellas, que representa funciones o el
tipo de usuario. En la mayor parte de los casos, será únicamente una cuenta de servicios, aunque puede
utilizar más si necesita un control más estricto en la autorización. Por ejemplo, en la aplicación de
procesamiento de pedidos puede tener acceso a la base de datos como "TheOrderApplication", o bien iniciar
sesión de forma selectiva como "OrderProcessingManager" u "OrderProcessingClerk" de acuerdo con la función
de la identidad del llamador.
Utilice cuentas de servicios si:
Se conecta al origen de datos subyacente de un entorno en el que la representación del llamador

inicial no esté disponible (por ejemplo, BizTalk Server).
Dispone de un control de cambios muy limitado sobre las cuentas que pueden iniciar sesión en el
otro sistema (por ejemplo, conectarse a un sistema de administración de bases de datos
relacionales, que administra estrictamente el administrador de la base de datos).
El almacén de datos al que tiene acceso dispone de un mecanismo de autenticación diferente al

del resto de la aplicación (por ejemplo, inicia sesión en un servicio Web a través de Internet).
El acceso al almacén de datos a través de un gran número de cuentas niega la agrupación de

conexiones y, por lo tanto, reduce el rendimiento y la escalabilidad.
No utilice cuentas de servicios si:
No dispone de una forma segura de almacenar y mantener las credenciales del servicio.
Necesita tener acceso al almacén de datos con recursos del usuario específicos debido a las
directivas de seguridad (por ejemplo, si necesita tener acceso a los datos u objetos en Microsoft
SQL Server™ en nombre de los usuarios).
El almacén de datos realiza la auditoría de actividades y estas auditorías se deben asignar a

usuarios individuales.
Estará representando al llamador cuando tenga acceso a un almacén de datos con un conjunto de cuentas
que se asignan una a una con la base de usuarios de la aplicación. Por ejemplo, si "Juan" inicia sesión en la
aplicación y los componentes de acceso a datos tienen acceso a una base de datos, estará representando a
Juan si inicia sesión en esta base de datos con las credenciales de Juan.
Necesita la representación del llamador si:
El almacén de datos realiza la autorización basada en el usuario con sesión iniciada.
El almacén de datos necesita realizar la auditoría de las actividades de cada usuario final
individual.
Se utilizan normalmente dos mecanismos de implementación para representar a los llamadores:
Servicios de representación de plataforma. Windows 2000 y versiones posteriores ofrecen la

representación de usuario mediante Kerberos a través de la red. Esto significa que si Juan tiene
acceso a su aplicación Web, y usted ha utilizado la autenticación de Windows, podrá representar a
Juan a través de la red hasta su base de datos.
La representación generalmente sólo se admite si dispone del mismo mecanismo de autenticación

a través de toda la red o un mecanismo de autenticación estándar compatible (como, por
ejemplo, Kerberos).
En Windows 2000, el nivel de representación proporcionado por la plataforma a través de varios

saltos de red se denomina delegación. Para poder delegar el contexto de seguridad, el dominio,
equipo y cuenta de usuario deben estar habilitados para la delegación. Windows .NET Server
proporciona delegación de restricción, que agrega una mayor flexibilidad de administración.
Soluciones de servidor de inicio de sesión único. Los mecanismos de servidor de inicio de sesión
único le proporcionarán las credenciales (por ejemplo, nombre de usuario y contraseña) de un
usuario para iniciar sesión en un origen de datos cuando les proporciona pruebas de que ha
autenticado a ese usuario mediante otro mecanismo. Este tipo de enfoque es una forma de
"representación débil", ya que requiere una asignación que generalmente no puede propagar más
6 de 32 08/10/2009 05:31 p.m.

de un salto lógico.
Para obtener directrices generales sobre la conexión a SQL Server desde las aplicaciones distribuidas, consulte
".NET Data Access Architecture Guide [ http://msdn.microsoft.com/library/default.asp.aspx?url=/library
/en-us/dnbda/html/daag.asp ] " en MSDN
Nota
Las consideraciones para la implementación de autenticación en los agentes de servicios son similares a las
relacionadas con los componentes de acceso a datos anteriormente descritos.
Autenticación en los componentes de entidad empresarial
Los componentes de entidad empresarial se ofrecen a menudo para el desarrollo personalizado como un SDK
o un modelo de objeto para la aplicación para su utilización desde una secuencia de comandos o desde el
sistema de desarrollo de Microsoft Visual Basic® en los clientes.
Si no hay otros componentes de la aplicación o secuencias de comandos personalizadas que vayan a utilizar
sus entidades empresariales, éstas no necesitan presentar un límite de autenticación. En este caso, se deben
basar en el contexto de seguridad actual (el objeto Principal conectado al subproceso actual) para la
autenticación.
Si está pensando en exponer las entidades empresariales para permitir la secuencia de comandos
personalizada o el consumo desde otras aplicaciones, puede que deba proporcionar un componente adicional
que ayude al cliente a "iniciar sesión" desde el código y establecer el contexto de seguridad que requieren
estos objetos si no se basa en la autenticación de plataforma. No debe diseñar entidades empresariales que
se basen en en la posesión de un contexto de seguridad de Windows para un usuario humano determinado si
las entidades empresariales se invocarán por mecanismos que no son de representación (por ejemplo, un
proceso empresarial que se inicia asincrónicamente).
Autorización
El aspecto de la autorización de la directiva de seguridad se ocupa de la identificación de las acciones

permitidas para cada principal de seguridad autenticado. En otras palabras, la directiva de seguridad
determina quién puede hacer qué. Para determinar la directiva de autorización, deberá tener en cuenta dos
factores principales:
Los permisos y derechos de usuario.
La seguridad de acceso al código.
Los permisos y derechos de usuario determinan lo que se permite hacer en una cuenta de usuario en el
contexto de la aplicación. Técnicamente, el término "permisos" se refiere a las acciones permitidas en un
recurso (como por ejemplo, un archivo o una tabla de base de datos), mientras que los "derechos" hacen
referencia a las tareas del sistema que se permite realizar al usuario (como por ejemplo, configurar la hora del
sistema o apagar el equipo). Los permisos y derechos de usuario se pueden asignar de forma individual para
cada usuario, si bien resultan más fáciles de administrar cuando los usuarios se organizan de una manera
lógica en grupos o funciones. La mayor parte de los recursos tienen algún tipo de lista de permisos
relacionada, en la que se indican los permisos asignados a los usuarios para ese determinado recurso. Por
ejemplo, en el entorno de Windows, los recursos se aseguran mediante el uso de una lista de control de
acceso (ACL), que muestra los permisos asignados a los principales de seguridad en el recurso, así como
cuáles son esos permisos. Los permisos son generalmente acumulativos, por lo que un usuario que tiene
permiso de "lectura" en un archivo y que se encuentra en un grupo que tiene permiso de "modificación" en
ese mismo archivo, tendrá un permiso de red de "modificación". La excepción a esta regla ocurre cuando se
asigna un permiso de "denegación". Si a un usuario, o a cualquiera de los grupos de los que este usuario es
miembro, se le deniega explícitamente el acceso a un recurso, no podrá tener acceso a dicho recurso,
independientemente de los permisos que se hayan asignado a cualquier otro usuario o grupo.
La seguridad de acceso al código, que presentó por primera vez .NET, ofrece a los desarrolladores y
administradores una dimensión adicional de control de acceso, así como la posibilidad de comprobar de nuevo
la configuración de seguridad correcta. A diferencia de los permisos y derechos de usuario, la seguridad de
acceso al código se ocupa de lo que puede hacer un ensamblado. Por ejemplo, un ensamblado de .NET se
podría configurar de tal modo que el código no pueda tener acceso a los recursos del sistema de archivos y
cualquier código que intente hacerlo desencadenará una excepción de infracción de acceso. Puede establecer
zonas de confianza que apliquen directivas de seguridad de acceso al código diferentes de acuerdo con una
serie de factores.
Debe incluir los resultados en la siguiente matriz en el diseño de control de acceso:
7 de 32 08/10/2009 05:31 p.m.

Seguridad de acceso de usuario
La seguridad de acceso de usuario se utiliza para determinar lo que puede hacer la identidad actual. Se puede
comprobar lo que puede hacer un llamador mediante numerosos mecanismos. En aplicaciones con una
interfaz de usuario, puede que la lógica empresarial represente al llamador, pero en la mayor parte de los
servidores y especialmente en los servicios sin interfaces de usuario, el código generalmente utilizará una
cuenta de "servicios" determinada.
En lugar de utilizar la cuenta en la que el proceso actual se está ejecutando, puede establecer su propia
identidad de manera manual en un subproceso que se esté ejecutando si modifica el objeto Principal.
Lo que el usuario puede hacer al entorno y a la plataforma se controla normalmente mediante las ACL, que se
contrastan con la identidad de Windows del proceso o subproceso actual. Los recursos que generalmente se
contrastan con la identidad de Windows son archivos NTFS, API del sistema, componentes (COM+) de .NET
Enterprise Services y servicios configurados para la autenticación de Windows.
Windows proporciona una gran variedad de características de grupo, derechos de usuario y administración de
seguridad. Ciertos servicios pueden implementar su propia abstracción sobre estas características como, por
ejemplo, la autorización basada en funciones en Enterprise Services. Por ejemplo, Enterprise Services realiza
la autorización en relación a funciones, donde cada función es en realidad una ACL.
.NET proporciona un marco amplio y extensible para la administración de la seguridad de acceso de usuario,
incluidas identidades, permisos y la noción de un principal y funciones
Para asegurarse de que los usuarios en una determinada función llaman a un método específico, establezca
un atributo en el método de clase, como se muestra en el siguiente código.
[PrincipalPermission(SecurityAction.Demand, role="Managers")]
public void PlaceOrder(DataSet Order)
{
// Este código no se ejecutará si el principal conectado
// al subproceso devuelve falso cuando se invoca a IsInRole
// con "Managers" como argumento
}
Para obtener más información, consulte "Constructor PrincipalPermissionAttribute" [

http://msdn.microsoft.com/library/default.asp.aspx?url=/library/en-us/cpref
/html/frlrfsystemsecuritypermissionsprincipalpermissionattributeclassctortopic.asp?frame=true ] en .NET
Framework SDK en MSDN (en inglés).
Si su componente se basa en la implementación en Enterprise Services y autentica a los usuarios a través de

Windows, puede utilizar la administración de funciones de Enterprise Services tal como se muestra en el
siguiente código.
[SecurityRole("HelpDesk")]
public DataSet GetCancelledOrders(System.Guid CustomerID)
{ //… }
Si tiene acceso a los componentes de forma remota, el uso de la administración de funciones de Enterprise
Services requiere que este acceso se realice a través del canal DCOM-RPC.
Seguridad de acceso al código
La seguridad de acceso al código se ocupa de lo que el ensamblado puede realizar, si bien también puede
decidir personalmente si el código se ejecuta o no, dependiendo del código que intente tener acceso a él. Por
ejemplo, esto evita que sus objetos puedan ser llamados desde secuencias de comandos que alguien con
suficientes privilegios pueda ejecutar sin su conocimiento. Tenga en cuenta que la directiva de seguridad de
acceso al código no funcionará a través de .NET Remoting: todas las comprobaciones se realizarán cuando se
invoque desde el mismo dominio de la aplicación.
Puede comprobar el acceso al código según los siguientes factores:
El directorio de instalación de la aplicación.
El hash criptográfico del ensamblado.
8 de 32 08/10/2009 05:31 p.m.

La firma digital del publicador del ensamblado.
El sitio desde el cual se origina el ensamblado.
El nombre seguro criptográfico del ensamblado.
La dirección URL desde la que se origina el ensamblado.
La zona desde la que se origina el ensamblado.
Las directivas de seguridad se pueden aplicar para la empresa, el equipo, el usuario y la aplicación. Las zonas
definidas por .NET son: Internet, intranet, Mi PC, NoZone, segura y no segura. Si desea obtener más
información sobre estos elementos, consulte los siguientes artículos en MSDN Library:
Code Access Security [ http://msdn.microsoft.com/library/en-us/cpguide

/html/cpconcodeaccesssecurity.asp ]
Introduction to Code Access Security [ http://msdn.microsoft.com/library/en-us/cpguide

/html/cpconintroductiontocodeaccesssecurity.asp ]
SecurityZone Enumeration [ http://msdn.microsoft.com/library/en-us/cpref

/html/frlrfSystemSecuritySecurityZoneClassTopic.asp ]
Implementación de comprobaciones de autorización complejas
En ciertos casos, la aplicación deberá realizar comprobaciones de autorización complejas. Por ejemplo,
considere el siguiente conjunto de condiciones: "Permitir que se realice este pedido si el llamador se
encuentra en la función de Vendedor, o si se trata de un servicio que llama desde un socio y el pedido no
sobrepasa 1000 dólares, o bien si el llamador tiene una función de Administrador o superior". Esta directiva
de autorización requiere unas combinaciones de permisos mediante AND, OR, y "menor que" y "mayor que",
además del conocimiento del precio del pedido que se realiza. Estos tipos de comprobaciones de autorización
se realizan mejor en el código de su propia aplicación como comprobaciones mediante programación y
requieren un desarrollo considerable para separarlas como reglas puras. En otros escenarios más sencillos,
puede implementar la lógica de la autorización de forma declarativa mediante el uso de atributos o
parámetros de configuración.
Diseño de esquemas de autorización de nivel de aplicación personalizados
Disponer de un esquema de autorización personalizado constituye un requisito habitual cuando un

subconjunto de la autorización de la aplicación la administran los usuarios y no los operadores, y los datos de
la autorización se almacenan en su base de datos o en otro almacén externo. En estos casos, su aplicación
generalmente proporcionará una interfaz de usuario para la administración de seguridad y un esquema de
base de datos para administrar la pertenencia a funciones. Cuando desarrolle esta clase de marco, tenga en
cuenta las siguientes directrices:
Exponga toda la lógica de autorización a través de un objeto principal. Su principal se creará con
una identidad particular como argumento de constructor. Compruebe la propiedad
IsAuthenticated de la identidad y utilice el nombre de su identidad para ubicar los datos de
autorización correctos. Exponer la lógica de autorización a través de la función IsInRole permite a
la aplicación utilizar atributos de PrincipalPermission, al tiempo que ofrece un modelo de
desarrollo coherente que le permitirá utilizar otros esquemas de autenticación y autorización en el
futuro. Para obtener un ejemplo de este uso, consulte "Creating WindowsIdentity and
WindowsPrincipals Objects [ http://msdn.microsoft.com/library/en-us/cpguide
/html/cpconcreatingwindowsidentitywindowsprincipalobjects.asp ] " en MSDN
Autentique la comunicación con el almacén de datos de autorización. Asegúrese de que el

almacén de datos de autorización no se vea afectado y de que únicamente las cuentas apropiadas
pueden leer y escribir estos datos. Su aplicación debe tener acceso a este almacén con una
cuenta de sólo lectura y únicamente las partes de la aplicación que modifican estos datos deben
tener acceso de lectura y escritura.
Cuando no utilice la autenticación de Windows, separe las credenciales de usuario y los

identificadores de autenticación del esquema de datos de autorización. Sus datos de autorización
deben hacer referencia internamente a los usuarios mediante un Id. privado. Esto le permite
modificar los esquemas de autenticación en el futuro, al tiempo que permite que las reglas de
autorización se utilicen desde aplicaciones con distintos mecanismos de autenticación y que los
usuarios puedan modificar sus Id. de usuario.
Almacene en caché para el rendimiento. Puede elegir almacenar en caché la información de
9 de 32 08/10/2009 05:31 p.m.

autorización (por ejemplo, la pertenencia a funciones) en el objeto principal en lugar de tener

acceso al almacén en cada ocasión. Si almacena en caché los datos de autorización, deberá firmar
o utilizar un hash para asegurarse de que no han sido alterados.
Proporcione capacidades sin conexión para los clientes desconectados. Esto puede implicar la
incrustación de la lógica de autorización con el propio cliente o el almacenamiento en caché local
de una copia firmada digitalmente.
Diseñe la lógica del almacén de datos de autorización para que sea acoplable. Esto le permitirá
elegir distintas ubicaciones y productos sin modificar el diseño del marco.
Establezca el acceso al código llamando a los atributos de ensamblado mediante un atributo

StrongNameIdentityPermission [ http://msdn.microsoft.com/library/en-us/cpref
/html/frlrfSystemSecurityPermissionsStrongNameIdentityPermissionAttributeClassTopic.asp ] si
desea asegurarse de que únicamente los ensamblados de la aplicación pueden crear e invocar su
objeto principal.
Nota
Windows .NET Server proporciona nuevas características que ayudan a simplificar la implementación de la
funcionalidad de autorización personalizada.
Usuarios, funciones y aplicaciones y servicios de confianza
Las aplicaciones y servicios que interactúan generalmente tienen cuentas de usuario y definiciones de
funciones independientes, a menos que se implementen en una organización en la que los usuarios y grupos
se puedan definir para toda la organización. Incluso en este caso, no debe confiar en la definición de
funciones y usuarios de otro servicio, sino en las definiciones de funciones y usuarios de su organización y en
las definidas para su servicio.
Cuando controle servicios que interactúan, se recomienda que autentique y autorice a los llamadores con una
granularidad que abarque todo el servicio. Por ejemplo, su servicio puede interactuar con otros servicios en
organizaciones de socios, en cuyo caso resultará útil definir funciones como, por ejemplo, "Standard Partner"
y "Premier Partner". El uso de funciones para realizar la autorización de servicios externos y socios permitirá a
su aplicación crecer y funcionar con numerosos socios en el futuro sin afectar al código o diseño.
Si su servicio comparte cuentas de usuario con servicios de llamada y requiere realizar la autorización en la
granularidad de usuario, la información de usuario se debe incluir como parte de los datos empresariales
intercambiados. Si necesita asegurarse de que un determinado usuario ha enviado los datos empresariales,
deberá incluir un símbolo de autenticación o firmar el documento para mostrar que provino del usuario o de
un servicio en el que confía.
Establecimiento del contexto de seguridad en los límites del sistema
Un principal personalizado en un determinado subproceso no establece un flujo a través de los procesos o los
canales remotos, por lo que normalmente deberá establecer personalmente el sistema de seguridad en los
límites del sistema.
Para establecer un principal personalizado en el subproceso actual deberá:
Crear el objeto Identity adecuado, pasando las credenciales, el símbolo de usuario o el Id. de
usuario (u otro tipo de identificador) al constructor. Si dispone de una implementación
personalizada del objeto Identity, deberá mantener un indicador interno que muestre si la
identidad se ha autenticado.
Crear su objeto principal, pasando la instancia de identidad como un argumento para el

constructor. El objeto principal deberá conservar este objeto Identity para poder devolverlo
cuando se llame a Iprincipal:Identity.
Los principales de Windows establecen un flujo con interacción remota si utiliza DCOM-RPC como canal
remoto.
Si desea obtener más información sobre los objetos Principal e Identity de .NET y ejemplos de código que
muestren este patrón para principales personalizados y de Windows, consulte "Principal and Identity Objects
[ http://msdn.microsoft.com/library/en-us/cpguide/html/cpconprincipalidentityobjects.asp ] " en MSDN
Autorización en componentes de interfaz de usuario
Los componentes de interfaz de usuario muestran los datos a los usuarios y reciben datos de ellos. Ejecute la
autorización en este nivel si necesita:
10 de 32 08/10/2009 05:31 p.m.

Ocultar o mostrar determinados campos de datos al usuario.
Habilitar o deshabilitar controles para la intervención del usuario.
Si el usuario no debe ver una determinada información, la opción más segura consiste en no pasar esa
información a los componentes de la presentación en primer lugar.
Lo normal es realizar algún nivel de representación de la interfaz de usuario raíz o menú para que el usuario
sólo pueda ver los elementos Web, las entradas de menú o los paneles sobre los que pueda actuar según las
funciones que tengan.
Normalmente un archivo .exe de interfaz de usuario inicia la aplicación. Debe establecer permisos de acceso
al código en los ensamblados de la interfaz de usuario si no desea que ésta (o los componentes locales a los
que llama) tenga acceso a recursos importantes como, por ejemplo, archivos.
Deberá considerar el contexto de seguridad en el que se ejecutarán los componentes de presentación de la

aplicación y comprobarlos en un entorno adecuadamente restringido.
Autorización en componentes de proceso de usuario
Los componentes de proceso de usuario administran datos y controlan el flujo entre los procesos de usuario.
Deberá ejecutar la autorización en este nivel si necesita:
Controlar si un usuario puede iniciar un proceso de interacción de interfaz de usuario.
Agregar y eliminar "pasos" o componentes de interfaz de usuario completos en un flujo de

interacción de usuario según quién lo ejecute. Por ejemplo, un vendedor podría ver datos
únicamente de su región, por lo que no sería necesario mostrarle un paso del asistente en el que
tenga que elegir la región de un informe de ventas.
Lo ideal sería que el cuadro de diálogo principal fuera activo y ocultara o deshabilitara los elementos de la
interfaz de usuario necesarios para iniciar un cuadro de diálogo que un usuario no está autorizado a utilizar.
Si el cuadro de diálogo principal es el cuadro de diálogo "raíz", esto implicaría ocultar de forma activa las
entradas de menú apropiadas, los elementos Web de escritorios digitales, etc.
Puede establecer la autorización de forma declarativa para los procesos de usuario si agrega atributos
PrincipalPermission a las clases o métodos que los implementan.
Los componentes de proceso de usuario normalmente sólo se emplean desde los componentes de interfaz de
usuario. Puede utilizar la seguridad de acceso al código para restringir quién los llama. Asimismo, puede
utilizar la seguridad de acceso al código para restringir la forma en que los componentes de proceso de
usuario interactúan entre sí. Este enfoque resulta de especial relevancia en los escenarios de portales en los
que es fundamental que un proceso de usuario que se implementa como complemento no pueda obtener
información para la que no está autorizado desde los procesos y elementos de otro usuario.
Autorización en componentes empresariales
Tenga en cuenta las siguientes recomendaciones para la autorización en componentes empresariales:
Procure que la autorización de procesos empresariales sea independiente del contexto de usuario,
especialmente si va a utilizar numerosos mecanismos de comunicación como colas y servicios
Web, que impedirán que el proceso represente al llamador.
Utilice seguridad basada en funciones siempre que sea posible en lugar de confiar en cuentas de
usuario. Esto proporciona una mejor escalabilidad, facilita la administración y evita problemas con
los nombres de usuario que admiten numerosas representaciones canónicas. Puede definir
funciones para los componentes facilitados como servicios en una aplicación basada en Enterprise
Services, o bien, utilizar grupos de Windows o funciones personalizadas para los componentes
.NET que no se ejecutan en Enterprise Services.
Si decora un método con el atributo PrincipalPermission, compruebe siempre el tipo de

autenticación especificado por el objeto Identity. El objeto PrincipalPermissionAttribute de .NET
asegura que su principal es una función, pero no especifica un mecanismo de autenticación.
Autorización en agentes e interfaces de servicios
Los agentes de servicios son la puerta de enlace a través de la cual se realizan las llamadas a los servicios
externos, así que debe agregar funcionalidad de autorización para estos componentes siempre que desee
evitar que determinados usuarios o funciones tengan acceso a ellos. Tenga en cuenta que el servicio externo
también puede implementar sus propias comprobaciones de autorización adicionales.
11 de 32 08/10/2009 05:31 p.m.

Puede implementar autorización en componentes de la interfaz de servicio mediante el uso de la

autenticación de IIS y ASP.NET para los servicios Web, o bien a través de las ACL de Windows si la interfaz de
servicio se expone a través de Microsoft Message Queue Server.
Autorización en componentes de acceso a datos
Los componentes de acceso a datos son los últimos componentes que exponen la funcionalidad empresarial
antes de los datos de la aplicación, por lo que deben realizar todas las comprobaciones de autorización
minuciosas que sean necesarias. Ejecute la autorización en este nivel si necesita:
Compartir componentes de acceso a datos con desarrolladores de procesos empresariales en los

que no confíe plenamente.
Proteger el acceso a las funciones importantes expuestas por los almacenes de datos.
Debido a que los componentes de acceso a datos exponen una interfaz minuciosa en los sistemas
subyacentes, la seguridad sólo se puede administrar en un nivel detallado y no tiene en cuenta la agregación
necesaria para una determinada operación de proceso empresarial. De este modo, si implementa
comprobaciones de autorización en este nivel, la concesión o denegación de permisos para ejecutar un
proceso empresarial de alto nivel en una identidad puede implicar también la modificación de los permisos
para los componentes de acceso a datos.
Para realizar la autorización, puede basarse en las funciones de Enterprise Services y en los atributos
PrincipalPermission de .NET si utiliza la autenticación de Windows, o bien en las funciones y atributos de .NET
si no se basa en un contexto de seguridad de Windows.
Si establece un flujo del mismo contexto de usuario a su almacén de datos, puede utilizar la funcionalidad de
autorización de la base de datos (por ejemplo, para otorgar o revocar el acceso a los procedimientos
almacenados). Esto se podrá realizar únicamente si:
Utiliza un conjunto de cuentas de servicio para tener acceso a la base de datos que representa
distintas combinaciones de funciones.
Representa a los llamadores hasta su base de datos.
Nota
El flujo de contextos de usuarios representados hasta la base de datos afecta al rendimiento y escalabilidad
debido a que las conexiones están agrupadas por usuario. Por otra parte, los procesos empresariales que se
inician asincrónicamente no representarán automáticamente al usuario de origen y, por tanto, no estará
disponible un principal de Windows (a menos que tenga acceso al nombre y contraseña del usuario, que en la
mayor parte de los diseños sería menos seguro y nada deseable).
Como los componentes de acceso a datos generalmente sólo se llaman por otros componentes de la
aplicación, resultan ideales para restringir los llamadores al conjunto de ensamblados necesario:
normalmente, una combinación de ensamblados con componentes de la capa de interfaz de usuario,
componentes de procesos empresariales y entidades empresariales (si existen).
Autorización en componentes de entidad empresarial
Los componentes de entidad empresarial pueden exigir reglas de autorización de acuerdo con el contexto de
seguridad del llamador (tanto para los usuarios como para las cuentas de servicios). Por ejemplo, puede
asegurarse de que los usuarios en una función determinada no tienen acceso a la información privada de un
objeto Cliente. Para implementar esta funcionalidad, deberá:
Asegurarse de que los contextos de seguridad son coherentes en todos los niveles físicos de la
aplicación; distintos niveles físicos que utilizan entidades empresariales deben tener objetos
Principal equivalentes en el contexto de ejecución.
Realizar las comprobaciones adecuadas a través de los atributos PrincipalPermission y las

llamadas PrincipalPermision.Demand en las llamadas a entidades empresariales.
Puede exigir la autorización en los componentes de entidad empresarial para comprobaciones activas, pero la
comprobación final la deben realizar los componentes del proceso empresarial y los de acceso a datos allí
donde tiene lugar la operación. Tenga en cuenta que disponer de dos ubicaciones que exigen autorización
sobre una funcionalidad relacionada puede implicar un mayor mantenimiento a fin de conservar las directivas
de autorización sincronizadas.
Puede que desee restringir el acceso a los componentes de entidad empresarial desde el ámbito del acceso al
código. De este modo, le permite asegurarse de que sólo el código de confianza invocará las entidades
empresariales. Puede decidirse por esta opción para evitar que usuarios avanzados escriban secuencias de
comandos personalizadas en estos objetos a fin de obtener acceso a información no autorizada.
12 de 32 08/10/2009 05:31 p.m.

Comunicación segura
Además de autenticar usuarios y autorizar solicitudes, debe asegurarse de que la comunicación entre los
niveles de la aplicación es segura a fin de evitar ataques en los que los datos se "sondeen" o alteren mientras
se transmiten o se almacenan en una cola.
Las comunicaciones seguras implican proteger las transferencias de datos entre componentes y servicios
remotos.
La comunicación segura no implica el uso de un mecanismo de autorización, pero se puede asociar al empleo
de un mecanismo de autorización unidireccional o bidireccional que se asegura de que los extremos de la
comunicación son quienes afirman ser.
Dispone de las siguientes opciones para comunicaciones seguras
Asegurar todo el canal:
Secure Sockets Layer (SSL). Esta es la opción recomendada para los canales HTTP, se
trata de un estándar ampliamente aceptado y generalmente se acepta para abrir
puertos SSL en los servidores de seguridad. Esta opción se recomienda cuando se
expone una interfaz de servicio en Web.
IPSec. Este mecanismo resulta una buena elección cuando ambos extremos de la
comunicación son conocidos y están bajo su control. IPSec se utiliza principalmente
cuando se realizan llamadas entre servicios o niveles de aplicación físicos dentro de
un centro de datos o entre centros de datos de la misma organización.
El canal remoto personalizado realiza el cifrado. Este enfoque no se recomienda

normalmente. La programación de comunicaciones seguras resulta una tarea
compleja que requiere unos profundos conocimientos sobre seguridad y numerosas
comprobaciones.
Redes privadas virtuales (VPN). Una red virtual le permite establecer un transporte IP
punto a punto en Internet (u otras redes). Resulta idónea para proporcionar a un
conjunto de empleados o socios acceso a una red interna desde Internet. La
implementación de VPN requiere una gran compatibilidad de la infraestructura.
Asegurar los datos:
Firmar un mensaje. Esto permite reconocer si el mensaje ha sido alterado. Las firmas
se pueden utilizar para la autenticación en el mismo proceso.
Cifrar el mensaje completo. Esto hace que todo el mensaje resulte ilegible si los
paquetes de red se ven afectados. Cifrar un mensaje con los algoritmos adecuados
también permite reconocer si se ha alterado.
Cifrar las partes confidenciales del mensaje. Utilice esta opción sólo cuando una
pequeña parte del mensaje no se pueda exponer.
La firma digital generalmente implica calcular un valor hash de la parte firmada del mensaje, cifrar el hash
con la clave privada del firmante e incluir el hash cifrado en el encabezado. El receptor descifra la firma
recibida con el mensaje utilizando la clave pública del firmante y compara el hash resultante con el que
calcula de las partes firmadas del mensaje. Si los valores hash coinciden, significa que el mensaje no se ha
alterado. Si no coinciden, el mensaje se ha dañado, con lo que deberá realizar una auditoría del mensaje con
el error y la información del llamador y devolver una excepción.
Nota
Los mensajes con firma digital y hash se pueden seguir utilizando en un ataque repetitivo, en el que el mismo
mensaje se envía repetidamente al servidor. Puede que necesite generar una lógica de reducción de riesgos
adicional en la capa de mensajería para hacer frente a este tipo de ataques. Por ejemplo, puede agregar una
marca de hora al cuerpo del mensaje o diseñar el proceso de forma que los mensajes sean idempotentes.
Por ejemplo, con los servicios Web XML, puede implementar firmas digitales XML en SOAP si utiliza la clase
SignedXml y los encabezados SOAP. Para obtener más información sobre la clase SignedXml, consulte
"SignedXml Class [ http://msdn.microsoft.com/library/default.asp.aspx?url=/library/en-us/cpref
/html/frlrfSystemSecurityCryptographyXmlSignedXmlClassTopic.asp ] " en MSDN (en inglés). Si desea
obtener más información sobre los encabezados SOAP, consulte "Using SOAP Headers [
http://msdn.microsoft.com/library/default.asp.aspx?url=/library/en-us/cpguide
/html/cpconusingsoapheaders.asp?frame=true ] " en MSDN (en inglés).
13 de 32 08/10/2009 05:31 p.m.

La protección del canal de comunicación afectará al rendimiento, así que siempre que evalúe las técnicas
anteriormente descritas, deberá limitar la seguridad del canal a las áreas específicas que la requieran como,
por ejemplo, asegurar los URI de servicios Web específicos, determinadas páginas ASP.NET o las partes
confidenciales de los datos empresariales. Los distintos mecanismos tendrán implicaciones de rendimiento
diferentes según los datos que la aplicación intercambie, el número de extremos y el tipo de seguridad
necesaria.
Para obtener más información sobre los canales que admiten canales de comunicación segura, consulte
"Diseño de la directiva de comunicaciones" en este capítulo.
Comunicación segura en componentes de la interfaz de usuario
Los componentes de la interfaz de usuario únicamente se comunican con el usuario. Por lo general, deberá
evitar mostrar información confidencial sin una advertencia. Las contraseñas nunca se deben mostrar o
transmitir en texto sin formato. Para las aplicaciones Web, deberá utilizar SSL siempre que se intercambien
datos confidenciales con el usuario como, por ejemplo, cuando se envíen formularios de inicio de sesión o se
muestre información financiera personal.
Los componentes de proceso de usuario normalmente residen junto con los componentes de la interfaz de
usuario, por lo que no es necesario proteger el canal entre ellos.
Comunicación segura en agentes e interfaces de servicios
Es la función del agente de servicios establecer el mecanismo de seguridad del canal adecuado entre él
mismo y el servicio invocado. Por ejemplo, si los mensajes se deben firmar o si se requiere una conexión SSL,
el agente de servicios deberá implementar esta lógica para aislar estos requisitos de los componentes
empresariales y flujos de trabajo.
Una interfaz de servicios como, por ejemplo, un servicio Web XML puede exigir unas comunicaciones seguras
y rechazar aquellas conexiones y mensajes que no cumplan los requisitos. Tanto Message Queue Server como
los servicios Web XML facilitan el establecimiento de un canal de comunicación seguro. Si desea obtener más
información, consulte "Diseño de la directiva de comunicaciones" en este mismo capítulo.
Comunicación segura en componentes de acceso a datos
Los componentes de acceso a datos generalmente se basan en los componentes de ayuda para el acceso a
datos a la hora de realizar las conexiones con el almacén de datos. Son estos componentes los que deben
tratar cualquier clase de directiva de cifrado de la comunicación con el almacén de datos. Además,
determinados almacenes de datos pueden admitir diversos protocolos de comunicaciones (por ejemplo, SQL
Server admite canalizaciones con nombre, TCP/IP, IPX/SPX, entre otros). La directiva de comunicaciones de la
organización podría afectar a este aspecto del diseño si establece un protocolo concreto.
Los distintos orígenes de datos admiten diferentes tipos de seguridad de comunicación o incluso pueden no
admitir ninguno de forma nativa. En ocasiones deberá proteger la comunicación con el servicio a través de un
mecanismo de seguridad proporcionado por la plataforma o estándar, como por ejemplo SSL.
Los componentes de ayuda para el acceso a datos deben administrar los parámetros de la conexión a fin de
aplicar la seguridad de comunicación. Por ejemplo, los componentes de ayuda para el acceso a datos pueden
encapsular:
La lógica para elegir el proveedor de seguridad adecuado para SQL Server.
La implementación de mecanismos de cifrado SOAP.
El código para establecer una conexión a través de SSL.
Administración de perfiles
Los perfiles de usuario consisten en información sobre el usuario que puede utilizar la aplicación para
personalizar su comportamiento. Un perfil de usuario puede incluir preferencias de la interfaz de usuario (por
ejemplo, colores de fondo) y datos sobre el usuario (por ejemplo, la región en que se encuentra, información
sobre su tarjeta de crédito, etc). La información del perfil la puede exponer el objeto Principal como una
colección. Puede elegir almacenar en caché la información del perfil para las aplicaciones sin conexión. Si la
información del perfil contiene información confidencial, puede optar por cifrarla o utilizar un valor hash para
asegurarse de que no se podrá leer y de que no se ha modificado.
Auditoría
En muchos casos, necesitará implementar la funcionalidad de auditoría para realizar el seguimiento del
usuario y la actividad empresarial en la aplicación por motivos de seguridad. Para realizar la auditoría de las
actividades empresariales, necesita una ubicación de almacenamiento segura; de hecho, la auditoría se puede
considerar como un "registro seguro". Si implementa su propia solución de auditoría, se deberá asegurar de
que las entradas de auditoría no se puedan modificar o al menos permitan reconocer si han sido alteradas
(mediante el uso de firmas digitales) y de que la ubicación de almacenamiento sea segura (por ejemplo, no
14 de 32 08/10/2009 05:31 p.m.

se pueden modificar las cadenas de conexión o sustituir los archivos de almacenamiento). El mecanismo de
auditoría puede utilizar la firma de documentos, la autenticación de plataforma y la seguridad de acceso al
código para asegurarse de que no haya código malintencionado que registre entradas falsas.
La interfaz de auditoría en la aplicación se puede exponer como una función de utilidad o como un método del
objeto Principal de la aplicación si la acción auditada se debe correlacionar con el usuario.
Auditoría en la interfaz de usuario y en los componentes de proceso de usuario
La actividad que ocurre en los componentes de interfaz de usuario no se suele auditar. Una aplicación de
interfaz de usuario puede demandar la auditoría de eventos generales como, por ejemplo, inicio de sesión,
cierre de sesión, cambios de la contraseña y todas las excepciones de seguridad en general.
Como los componentes de proceso de usuario representan actividades de usuario (que se pueden detener,
abandonar, etc.) no es común auditarlos. Como siempre, puede que desee auditar excepciones relacionadas
con la seguridad.
Auditoría en componentes de procesos empresariales
Los procesos empresariales son objetivos prioritarios de la auditoría. Deseará saber quién realizó las
actividades empresariales clave y cuándo tuvieron lugar dichas actividades.
Si realiza la auditoría dentro del contexto de una transacción, a un administrador de recursos transaccional
como, por ejemplo, SQL Server, deseará que el componente de auditoría inicie una nueva transacción de
modo que los errores en el árbol de la transacción original no deshagan también la entrada de auditoría.
Auditoría en componentes de acceso a datos
Los componentes de acceso a datos constituyen la capa de lógica empresarial personalizada más cercana al
almacén de datos. Al igual que ocurría para la autorización minuciosa, la capa de los componentes de acceso
a datos es una ubicación idónea para implementar una auditoría minuciosa.
Los componentes de acceso a datos generalmente invocarán procedimientos almacenados que realmente
llevan a cabo el trabajo relacionado con los datos, por lo que puede que desee auditar también dentro de
RDBMS. Para obtener información sobre cómo implementar la auditoría en SQL Server, consulte "Auditoría de
la actividad en SQL Server [ http://msdn.microsoft.com/library/default.asp.aspx?url=/library/en-us/adminsql
/ad_security_2ard.asp ] " en SQL Server 2000 SDK en MSDN
Principio de la página
Diseño de la directiva de administración operativa
La directiva de administración operativa se ocupa de la ejecución constante y diaria de la aplicación y abarca

aspectos como la administración de excepciones, la supervisión, la supervisión empresarial, los metadatos, la
configuración y la ubicación del servicio, tal como se muestra en la figura 3.3.
Figura 3.3. Aspectos de la directiva de administración operativa
Administración de excepciones
La administración de excepciones incluye la detección y generación de excepciones, el diseño de éstas, el

flujo de información de las mismas y la publicación de información de las excepciones a diversos usuarios.
Todas las aplicaciones deben implementar algún tipo de control de las excepciones para detectar errores en
tiempo de ejecución. Las excepciones se deben detectar y resolver si es posible. Si no se puede resolver un
estado de error, la aplicación deberá mostrar un mensaje descriptivo para el usuario y proporcionar algún
medio para el registro o publicación de la información de la excepción para la depuración.
Nota
Para obtener más información sobre el control de excepciones en aplicaciones basadas en .NET, consulte
"Exception Management in .NET [ http://msdn.microsoft.com/library/default.asp.aspx?url=/library/en-us
/dnbda/html/exceptdotnet.asp ] " en MSDN
15 de 32 08/10/2009 05:31 p.m.

Para obtener un bloque de generación de referencia proporcionado por Microsoft para la administración de
excepciones que implementa el diseño descrito, consulte "Exception Management Application Block for .NET"
en MSDN
Detección y generación de excepciones
Su código deberá detectar excepciones si puede agregar relevancia a la información de la excepción o realizar
una decisión de flujo empresarial de acuerdo con el tipo de excepción y los datos. Se recomienda que detecte
excepciones en los límites de la capa para ajustarlas a tipos de excepciones que sean relevantes para los
llamadores. Puede generar una nueva excepción, y de manera opcional conservar la excepción detectada
original como un miembro InnerException del nuevo objeto de excepción que está generando.
Diseño de las clases de excepción
Las clases de excepción de la aplicación se deberán derivar de ApplicationException. Puede decidir generar su
propia clase de excepción que proporcione más características, como por ejemplo la disponibilidad para
agregar datos arbitrarios a la excepción. El bloque de aplicación de administración de excepciones para .NET
proporciona una clase base que puede utilizar que ofrece estas características adicionales.
Es habitual derivar a dos ramas principales de excepciones: excepciones empresariales y técnicas. Este
diseño facilita la detección y publicación del tipo de excepciones adecuado en diferentes partes de la
aplicación.
Flujo de la información de excepción
Las excepciones proporcionan un flujo de información ascendente. Las excepciones se deben poder serializar
para fluir en dirección ascendente a través de los niveles. Esto adquiere particular relevancia cuando se
alcanza una interfaz de servicios o de usuario con la que no desea establecer un flujo de la excepción
literalmente, sino más bien traducirla a algo que el llamador pueda procesar, y sin exponer información
confidencial empresarial o técnica acerca de su aplicación o servicio (como por ejemplo, una cadena de
conexión a una base de datos en caso de un error de conexión) que se pueda utilizar contra el sistema o la
organización.
Las excepciones establecerán un flujo únicamente si la comunicación es bidireccional. En el caso de Message

Queue Server y de mecanismos de comunicación unidireccionales, deberá implementar su propio mecanismo
para permitir que el llamador sepa que el mensaje ha producido un error. El cliente también debe ser capaz
de controlar los errores que impiden que los mensajes lleguen al servidor.
Publicación de la información de excepción
Si ocurre una excepción, deseará que su aplicación lo notifique a las personas adecuadas. El personal de
operaciones y soporte técnico debe conocer las excepciones técnicas y puede que los administradores y los
usuarios de la ayuda de escritorio también necesiten conocerlas. Cada tipo de audiencia necesitará
información del entorno adicional acerca de la excepción para realizar su función como, por ejemplo, los
objetos OrderIDs o los equipos origen.
Deberá publicar la información importante para cada audiencia a través de los canales que se comunican con
las herramientas que éstos utilizan. Esto significa que la aplicación puede publicar ciertos eventos de
Windows Management Instrumentation (WMI) en caso de un excepción técnica, ponerse en contacto con un
servicio Web de asistencia en caso de una excepción empresarial y registrar las excepciones en el registro de
eventos en todos los casos.
Para obtener código probado que implemente estas características, consulte "Exception Management
Application Block for .NET" en MSDN
Administración de excepciones en los componentes de interfaz de usuario
Los componentes de proceso de usuario deberán controlar las excepciones que provengan de los procesos
empresariales y de los componentes de acceso a datos y decidir si:
Vuelven a intentar la operación.
Exponen el problema al usuario.
Detienen, reinician o continúan con el flujo de la aplicación de la interfaz de usuario.
Puede que los componentes de proceso de usuario requieran ocultar las excepciones al usuario, dependiendo
de la operación. Si es necesario mostrar la excepción, el proceso de usuario probablemente bifurcará la
ejecución del control a alguna representación visual del error y no la propagará a su llamador (que puede ser
una página ASP.NET o un formulario de Windows, por ejemplo).
ASP.NET proporciona algunas capacidades de flujo de interfaz de usuario de estado de error básicas que
podrá aprovechar en tales aplicaciones. Para obtener más información, consulte "Exception Management in
.NET" en MSDN
16 de 32 08/10/2009 05:31 p.m.

Los componentes de interfaz de usuario deben publicar sus excepciones para ayudar a aislar los problemas,
especialmente en aplicaciones de cliente enriquecido. Resulta habitual publicar las excepciones en un servidor
central (por ejemplo, a través de servicios Web) y en un archivo local o un registro de eventos en el caso de
aplicaciones sin conexión.
Administración de excepciones en componentes de procesos empresariales
El control de excepciones en los componentes empresariales requiere normalmente que se detecten las
excepciones y errores devueltos por los objetos empresariales y se abstraigan en una excepción que pueda
entender el que realiza la llamada. Los componentes empresariales necesitan controlar las excepciones que
provienen de los componentes de acceso a datos. Entre estos se incluyen:
Excepciones técnicas (por ejemplo, un error en la conexión a la base de datos).
Excepciones empresariales (por ejemplo, la infracción de una restricción de clave externa).
Los componentes empresariales no deberán ocultar estas excepciones del código de llamada y deberán
propagar las excepciones que reciben. Microsoft recomienda la propagación de las excepciones tal cual, pero
puede elegir realizar ajustes, especialmente si sólo dispone de un tipo de cliente que se pueda beneficiar de
la información de excepción de los niveles más altos.
Los componentes empresariales deberán detectar nuevas excepciones cuando:
El llamador está intentando realizar una operación con datos insuficientes o incorrectos (por
ejemplo, una llamada al método Save en un objeto Customer para el que no se ha proporcionado
el nombre).
Se produce una infracción de restricción al realizar una operación.
Los componentes empresariales necesitan propagar todas las excepciones de componentes de acceso a datos;
por ejemplo, si:
Hay problemas técnicos en el acceso a datos o se producen errores en los componentes de acceso
a datos del servidor. La mayoría de estas excepciones se pueden propagar sin que se tengan que
volver a realizar ajustes.
Está utilizando un esquema de bloqueo optimista (esto es frecuente cuando las entidades
empresariales se utilizan desde las capas de interfaz del usuario) y una actualización
sobrescribiría los datos que se han actualizado desde la última lectura.
Por lo general, los componentes empresariales no deberían ocultar ninguna excepción procedente de las capas
que éstos llaman. La ocultación de excepciones podría llevar a errores a los procesos empresariales en
términos de estado transaccional y hacer creer al usuario que determinadas operaciones se han realizado
correctamente.
Las excepciones se deberán publicar en las capas empresariales, ya que es aquí donde se conoce el resultado
de una transacción y se definen los acuerdos de niveles de servicios internos.
Administración de excepciones en componentes de acceso a datos
Los componentes de acceso a datos normalmente necesitan controlar dos clases principales de excepciones:
Las excepciones derivadas de errores técnicos que se conectan a e invocan el almacén de datos.
Las excepciones empresariales que se derivan de procedimientos almacenados que implementan

la lógica empresarial basada en datos.
Si las actividades en ejecución son transaccionales, todas las excepciones cancelarán la transacción actual. Es
importante que los componentes de acceso a datos consideren explícitamente la transacción actual de
Enterprise Services en caso de que algo vaya mal.
El control de excepciones en los componentes de datos requiere con frecuencia la detección de excepciones y
errores devueltos por el origen de datos subyacente (o API de acceso a datos) y su asignación al esquema de
excepciones utilizado en el resto de la aplicación. Los componentes de acceso a datos deberían propagar
excepciones, ajustándolas a los tipos de excepciones que entienden sus clientes. Al ajustar las excepciones en
dos tipos de excepciones principales (empresariales y técnicas) mejora la estructura del control de
excepciones y la lógica de publicación de las mismas para los distintos llamadores posibles.
La funcionalidad para asignar las excepciones de orígenes de datos (por ejemplo, SqlExceptions, que
representa los errores de SQL Server producidos con RAISERROR en los procedimientos almacenados) al
esquema de excepciones de la aplicación basada en .NET se debería implementar en los componentes de
17 de 32 08/10/2009 05:31 p.m.

acceso a datos. El proceso de asignación puede incluir una o varias de las siguientes acciones:
Traducción o asignación de un código de error específico del servicio o HResult a una excepción
del tipo correspondiente en .NET.
Ajuste de una excepción .NET de bajo nivel con una excepción más importante.
Extracción de información detallada del error a través de la API de servicios y adición de

información en los campos adecuados de la excepción que se está creando.
Nota
Si la API de acceso a datos está diseñada para .NET (como lo está ADO.NET), la mayoría de esta traducción y
ajuste se realiza automáticamente, por lo que las operaciones de detección y regeneración no resultan
necesarias en los componentes de acceso a datos. ADO.NET, por ejemplo, genera una excepción SqlException
cuando SQL Server devuelve un error. Sin embargo, en la mayoría de los casos, debería ajustar estas
excepciones específicas de la API de acceso a datos en excepciones personalizadas que tengan más relevancia
en la aplicación.
Los componentes de acceso a datos deberían publicar sus excepciones escribiendo los detalles de las mismas
en un archivo de registro, enviando una alerta o publicando la excepción. Las excepciones técnicas y
empresariales se pueden publicar empleando distintos mecanismos (por ejemplo, podría enviar alertas a los
operadores a través de WMI cuando se produce un problema técnico, aunque registre excepciones
empresariales en una base de datos o registro de errores específico de la aplicación).
Administración de excepciones en componentes de entidades empresariales
Las entidades empresariales se pueden llamar desde la interfaz de usuario o los componentes de procesos
empresariales, por lo que es importante que produzca y propague excepciones que pueden emplear ambos.
En los casos especiales en los que las entidades empresariales se exponen para el uso de los desarrolladores
de secuencias de comandos como en un SDK en un sistema de mayor tamaño, puede elegir ajustar todas las
excepciones en los tipos de excepciones más descriptivos que contengan la excepción original como un
miembro InnerException.
Supervisión
Necesita instrumentar la aplicación de forma que proporcione al personal de operaciones información sobre el
mantenimiento de la aplicación, compatibilidad con los acuerdos de nivel de servicios (SLA), así como
administración de la escalabilidad y capacidad. Para obtener instrucciones detalladas sobre la forma de
agregar instrumentación a la aplicación, consulte "Monitoring in .NET Distributed Application Design [
http://msdn.microsoft.com/library/en-us/dnbda/html/monitordotnet.asp ] " en MSDN
Su aplicación se puede beneficiar de los siguientes tipos de supervisión:
Supervisión del mantenimiento: ¿se ejecutan correctamente los componentes? ¿Se producen
bloqueos transitorios, cuelgues, salidas de procesos, colas bloqueadas y demás?
Compatibilidad con SLA: ¿se ejecutan los procesos empresariales dentro de los parámetros
esperados? ¿Cumplen las expectativas esperadas los servicios que integra? ¿Cumple la aplicación
o servicio las expectativas de respuesta y rendimiento del llamador?
Administración de la escala: ¿está correctamente diseñado el equipo, batería de servidores o red

en los que se están implementando los componentes para la tarea que deben realizar? ¿Se puede
predecir el rendimiento de los recursos disponibles?
Supervisión empresarial: ¿puede mejorar la eficacia de los procesos empresariales? ¿Se pueden
tomar decisiones fundamentales con tiempo? ¿Cuáles son los cuellos de botella en un proceso
empresarial eficaz?
Estas diversas preguntas se pueden responder supervisando las partes adecuadas de la aplicación o servicio.
No todos los tipos de supervisión necesitan estar activos a todas horas. Por ejemplo, puede que decida
supervisar los factores empresariales antes de planear la próxima versión de la aplicación.
Supervisión empresarial
Este tipo de supervisión tiene como objetivo proporcionar una capacidad reactiva para aquellos que dirigen la
empresa en relación al mantenimiento de la empresa, compatibilidad con SLA a nivel de empresa y
administración de la capacidad organizativa. En lugar de indicarle los errores de la red, este tipo de
supervisión ofrece una perspectiva con respecto a la estructura empresarial y a la eficacia de los procesos. Por
ejemplo, puede determinar que procesos empresariales se detengan durante días cada vez que un
18 de 32 08/10/2009 05:31 p.m.

determinado socio forme parte del envío y control.
La supervisión empresarial es un componente de la inteligencia empresarial, pero no sustituye otras técnicas

como, por ejemplo el análisis OLAP y extracción de datos, que derivan sus datos de los procesos ETL (extraer,
transformar, cargar) de los almacenes del servicio o aplicación para informar de decisiones activas basadas en
tendencias de datos pasados. El principal factor diferenciador es que la métrica empresarial es transitoria y
puede incluso que no se refleje en los datos de las aplicaciones.
Supervisión en componentes de proceso de usuario
Los componentes de proceso de usuario pueden proporcionar interesantes estadísticas empresariales para
mejorar el diseño de la IU de la aplicación e interactuar de forma eficiente con los usuarios. Estos son
ejemplos de indicadores que se pueden obtener de componentes de procesos de usuarios:
Duración media total para un proceso de usuario determinado.
Si los procesos de usuario tienden a detenerse cada cierto punto, normalmente indica que la
interfaz de usuario podría proporcionar información empresarial más completa o instrucciones
más claras.
Los procesos de usuario que se han iniciado y no han terminado nunca, así como la etapa en la
que pasó al estado incompleto. Puede que sea capaz de utilizar esta información para diseñar
interfaces que permitan al usuario decidir si desean iniciar el proceso en una etapa posterior.
Supervisión en los componentes de procesos empresariales y flujos de trabajo
La supervisión del mantenimiento de los componentes empresariales y flujos de trabajo resulta fundamental,
ya que es donde se conoce en última instancia el resultado de la transacción y donde se canalizan los
problemas de compensaciones, servicios y almacén de datos. Debería instrumentar las clases según se
describe en "Monitoring in .NET Distributed Application Design [ http://msdn.microsoft.com/library/en-us
/dnbda/html/monitordotnet.asp ] " en MSDN
La mayoría de la supervisión a nivel empresarial (si no toda) se realiza normalmente en las capas
empresariales. Si las capas empresariales se implementan con Enterprise Services (COM+), puede utilizar
AppMetrics para COM+ de XTremesoft (http://www.xtremesoft.com/) [ http://www.xtremesoft.com
/default.aspx ] (en inglés). Para la supervisión de flujos de trabajo de BizTalk, también puede utilizar BizTalk
Document Tracking. XTremesoft también ofrece un producto denominado AppMetrics para BizTalk Server.
Para obtener más información sobre el seguimiento de documentos en BizTalk Server, consulte "Using BizTalk
Document Tracking [ http://msdn.microsoft.com/library/en-us/biztalks/htm/lat_track_docs_gsra.asp ] " en
MSDN
Los componentes de acceso a datos participan en transacciones y se comunican con los componentes de la
API de acceso a datos que controla la conexión con los servicios de datos. Estos componentes son candidatos
importantes para la supervisión para realizar el seguimiento de la duración de operaciones de datos de larga
ejecución, duración del objeto, rendimiento y latencia de la actividad, uso de la memoria, así como otros
indicadores técnicos del mantenimiento.
Las cancelaciones de transacciones resultan costosas para la aplicación en general. La supervisión de estos
componentes y disponer de una buena directiva de publicación de excepciones le ayudará a aislar
componentes que tiendan a producir errores desde una perspectiva técnica o de lógica empresarial.
Cada vez que se conecta a una base de datos, debe también supervisar el uso de la conexión, las estadísticas
de agrupación de conexiones, así como las estadísticas de seguridad de conexión.
También es frecuente supervisar el tiempo de respuesta de los datos externos si SLA está asociado al uso de
datos u origen de datos externos.
Para obtener instrucciones detalladas sobre la forma de agregar capacidades de supervisión a los
componentes, consulte "Monitoring in .NET Distributed Application Design [ http://msdn.microsoft.com
/library/en-us/dnbda/html/monitordotnet.asp ] " en MSDN
Si implementa las capas empresariales con Enterprise Services, puede utilizar AppMetrics para COM+ de
XTremesoft, o bien utilizar las clases de instrumentación según se describe en "Monitoring in .NET Distributed
Application Design".
Configuración
Las aplicaciones requieren datos de configuración para funcionar técnicamente. Los valores que modifican el
comportamiento de las directivas (seguridad, administración operativa y comunicaciones) se consideran datos
de configuración.
Los datos de configuración se conservan en los archivos de configuración de .NET a nivel de usuario, equipo y
19 de 32 08/10/2009 05:31 p.m.

aplicación. La configuración personalizada almacenada aquí se puede definir con cualquier esquema y se
puede tener fácil acceso mediante el uso de la clase ConfigurationSettings en su aplicación.
Es muy importante tener en cuenta la confidencialidad de seguridad de la conexión; por ejemplo, no debe
almacenar cadenas de conexión SQL en texto no cifrado en los archivos de configuración XML, especialmente
si contienen credenciales SQL. Debería limitar el acceso a la información de seguridad a los operadores
adecuados y a fin de disponer de una mayor seguridad, debería considerar la firma digital de la información
para asegurarse de que los datos de configuración no se han modificado.
Los datos de configuración se pueden almacenar en varios lugares, cada uno de ellos con sus ventajas e
inconvenientes:
Archivos de configuración XML: el almacenamiento de los datos de configuración aquí permite a

los clientes de su aplicación trabajar sin conexión y este modelo resulta fácil de implementar. Con
aplicaciones de cliente enriquecido, este enfoque puede suponer un aumento en los costos de
administración de los cambios, ya que requiere que todos los clientes dispongan de la misma
información de configuración. En los entornos de servidor, resulta fácil incluir los cambios de
configuración a través del servidor Application Center o los servicios de directorio de Microsoft
Active Directory, o bien mediante la copia de los archivos por lotes. Tenga en cuenta que la carga
de nuevo de los datos de configuración de la aplicación requiere un reinicio de AppDomain. No
obstante, ASP.NET reiniciará AppDomain cuando detecte un cambio en los archivos de
configuración. Los archivos de configuración de la aplicación se almacenan en texto sin formato,
lo que puede resultar un riesgo de seguridad inaceptable. Por ejemplo, en la mayoría de los casos
no debería almacenar las cadenas de conexión que contengan nombres de usuario y contraseñas
en los archivos de configuración de la aplicación.
SQL Server o el almacén de datos de la aplicación: se trata de la ubicación de almacenamiento

normal para los datos de configuración administrados por la aplicación, pero aún más para los
metadatos de las aplicaciones. Si almacena aquí la configuración, se recomienda que guarde los
metadatos en una base de datos de SQL Server distinta de la de los datos empresariales. El
acceso a la base de datos supone a menudo una mejora en el rendimiento, por lo que debería
considerar el almacenamiento en caché.
Active Directory: dentro de una organización, puede decidir almacenar los metadatos de la
aplicación en Active Directory. De este modo, los clientes del dominio pueden disponer de los
metadatos. También puede asegurar la información en Active Directory con ACL de Windows,
asegurando que sólo los usuarios y las cuentas de servicio autorizadas podrán tener acceso al
mismo.
Cadenas del constructor: si utiliza componentes basados en Enterprise Services, puede agregar
datos de configuración a la cadena del constructor para los componentes.
Otras ubicaciones para casos especiales: éstas incluyen el Registro de Windows, el almacén de
Windows Local Security Authority (LSA) y las implementaciones personalizadas. Se utilizan en
casos muy especiales y agregan requisitos para los privilegios de aplicaciones en el equipo y los
mecanismos de implementación.
Soluciones de administración de configuración de terceros que pueden proporcionar también

características de control de versiones e implementación.
El acceso a los datos de configuración y metadatos a menudo pueden producir, especialmente si los datos
están almacenados de forma remota. Para evitar esto, puede almacenar en la memoria caché los datos y
metadatos de la configuración administrada por la aplicación. Sin embargo, necesita asegurarse de que no se
abre una brecha en la seguridad al exponer información confidencial en el código de aplicación incorrecto. Si
almacena en caché los datos de configuración, resulta útil especificar las velocidades y frecuencias de
actualización para que los datos en caché se actualicen a horas predeterminadas en lugar de a intervalos
relativos (por ejemplo, exigir que la caché de configuración se actualice cada hora a la hora, no "una hora
desde la última actualización"). De este modo, ayuda a que los operadores entiendan en qué datos de
configuración se basan las aplicaciones en un punto del tiempo especificado.
Configuración en las capas de presentación
Los componentes de proceso de usuario generalmente requieren los siguientes valores de configuración:
Información de la ubicación para llegar a los componentes de procesos empresariales y los

componentes
Datos de conexión (como una cadena de conexión o una ruta de archivo) para el recurso que
controla los datos de procesos de usuario persistentes para procesos de larga ejecución.
20 de 32 08/10/2009 05:31 p.m.

Configuración en agentes de servicios
Los agentes de servicios necesitan disponer de información de configuración para conectarse al servicio
externo a través de los servicios Web, colas de mensajes u otros medios. El esquema y los datos de
configuración dependen del servicio específico al que se está teniendo acceso.
Configuración en los componentes de acceso a datos
Los componentes de acceso a datos normalmente necesitan lo siguiente:
Necesitan tener la capacidad de asignar nombres de orígenes de datos lógicos a parámetros de la

conexión física (por ejemplo, para asignar la base de datos "Ventas" a una cadena de conexión
real).
Si los componentes de acceso a datos realizan un enrutamiento dinámico de datos, necesitará

contar con datos de configuración que expresen los parámetros (por ejemplo, región del cliente),
algoritmos (por ejemplo, hash) y destinos del enrutamiento (por ejemplo, cadenas de conexión
para las bases de datos). Es común incluir la lógica del enrutamiento dinámico de datos en un
componente de utilidad distinto.
Metadatos
Para que su aplicación sea más flexible en relación a los cambios en las condiciones de tiempo de ejecución,
puede que desee proporcionarle información sobre él mismo. El diseño de la aplicación para que utilice
metadatos en determinados lugares puede facilitar el mantenimiento y permitir su adaptación al cambio sin
costosos procesos de implementación o modificaciones en el desarrollo.
Hay dos momentos principales en los que puede utilizar metadatos en la aplicación:
Tiempo de diseño: por ejemplo, puede utilizar información sobre la base de datos para generar
código, procedimientos almacenados, clases .NET o incluso componentes de la interfaz de usuario
para patrones que se repitan con frecuencia. El uso de metadatos durante el desarrollo ahorra
tiempo de desarrollo reactivo, disminuye la necesidad de comunicación entre los equipos, se
concentra y "mantiene" conjuntos de habilidades especiales y aplica los estándares de diseño,
nomenclatura e implementación. Los componentes resultantes se comportan de forma más
predecible y tienden menos a errores, con lo que aumenta la productividad del desarrollador. Sin
embargo, este enfoque requiere conocimientos especializados y un esfuerzo inicial adicional de
desarrollo al crear las plantillas y el código que los combina con los metadatos.
Tiempo de ejecución: la aplicación puede ser más fácil de mantener si aprovecha la ventana de
los metadatos adecuados para los aspectos de cambio más frecuentes. Por ejemplo, puede que
decida adoptar encabezados para una lista de IU o cuadrícula de metadatos, para que sean
modificables en la aplicación. La aplicación también puede beneficiarse de los metadatos cuando
establezca relaciones entre los componentes o cuando se procesen patrones predecibles, como
reglas de validación. Sin embargo, el uso de metadatos en tiempo de ejecución suele ser más
costoso en términos de rendimiento, por lo que debería probar y crear un perfil del diseño de la
aplicación al principio del ciclo de vida de la aplicación. Puede diseñar los componentes para
exponer los metadatos sobre ellos mismos, pero debería hacerlo así sólo si la aplicación lo va a
utilizar; de lo contrario, los metadatos podrían ser una brecha en la seguridad.
Puede evitar los problemas de rendimiento al utilizar los metadatos en tiempo de ejecución utilizando
técnicas avanzadas como la generación de código sobre la marcha y la compilación utilizando las clases de
reflejo de .NET mientras se está ejecutando la aplicación. Esta técnica de diseño es compleja y únicamente se
recomienda para los casos más complejos debido a las habilidades necesarias y a las implicaciones de
seguridad de la compilación del código en tiempo de ejecución y al almacenamiento de los metadatos. La
personalización en tiempo de ejecución se puede lograr más fácilmente en la mayoría de los casos con las
secuencias de comandos de .NET. Para obtener más información sobre las secuencias de comandos de .NET,
consulte "Script Happens .NET [ http://msdn.microsoft.com/library/en-us/dnclinic
/html/scripting06112001.asp ] " en MSDN
Los metadatos se pueden almacenar en varias ubicaciones tal como se ha mencionado anteriormente en el
apartado "Configuración". Para almacenes centralizados, puede utilizar bases de datos de SQL Server o Active
Directory. Si desea distribuir los metadatos entre los ensamblados, puede implementarlo en los archivos XML
o incluso en los atributos de .NET.
Para obtener una buena base conceptual sobre el uso de metadatos en el diseño de software (una técnica
denominada a veces metaprogramación, que está relacionada con la programación basada en la intención),
lea Generative Programming: Methods, Tools and Applications por Krzysztof Czarnecki y Ulrich Eisenecker
(ISBN: 0201309777).
21 de 32 08/10/2009 05:31 p.m.

A continuación, se muestran los posibles usos de los metadatos.
Metadatos en los componentes de interfaz de usuario
Normalmente los metadatos se utilizan en las interfaces de usuario para especificar los encabezados de
columna, el texto de ayuda del usuario, mensajes de error, jerarquías de menú, así como otros tipos de
información que normalmente no afectan a los datos empresariales de la aplicación.
Si su aplicación requiere algún nivel de personalización, lo normal es utilizar metadatos para administrar las
opciones de personalización simples. En el caso de personalizaciones más complejas, se recomienda utilizar
secuencias de comandos .NET.
Metadatos en los componentes de procesos de usuario
Si crea modelos de los procesos de usuario de una forma sistemática, puede que encuentre que los siguientes
metadatos le ayudarán a crear un diseño con una mejor capacidad de mantenimiento:
Los procesos de usuario que existen y los elementos de menú que los desencadenan.
El estado empresarial interno que es necesario para el proceso de IU y los valores

predeterminados.
Una representación del comportamiento del proceso de usuario como, por ejemplo, el
componente de la IU que se mostrará cuando el cliente haga clic en "Confirmar compra".
Metadatos en los componentes empresariales
Los procesos empresariales se pueden beneficiar del uso de metadatos para crear modelos de patrones o
reglas sencillas. Por ejemplo, se puede implementar un patrón de canalización como un motor que utilice los
metadatos para determinar las clases y métodos que llamará en cada secuencia, tal como muestran las
canalizaciones de compra de Microsoft Commerce Server 2002. También puede utilizar metadatos para
ayudar a los componentes de llamada a identificar los métodos de compensación para determinadas
actividades empresariales.
Metadatos en los componentes de acceso a datos
Si el componte de acceso a datos expone una interfaz que proporciona la funcionalidad de creación, lectura,
actualización y eliminación (CRUD), sería útil exponer el esquema de los datos y metadatos devueltos que
utiliza. De forma similar, resulta útil exponer esquemas XSD de parámetros de entrada y salida complejos
para acciones o consultas especiales.
Los componentes de acceso a datos se pueden basar en metadatos en lugar de código de procedimiento para
realizar las transformaciones y asignaciones de datos. Puede utilizar los documentos XSL para transformar un
esquema XML en otro, utilizar un enfoque basado en reglas para realizar la asignación o utilizar los esquemas
de anotación SQLXML para asignar los documentos XML a datos en la base de datos subyacente. El enfoque
basado en metadatos puede resultar especialmente útil si esta asignación tiende a cambiar con frecuencia.
Metadatos en los componentes de entidades empresariales
Se recomienda que exponga metadatos de entidades empresariales a los consumidores, especialmente en los
componentes de interfaz de usuario, donde resulta útil disponer de información sobre las entidades
empresariales disponibles para ayudar en tareas como:
Rellenar encabezados de columna en tablas.
Mostrar descripciones de atributos para información sobre herramientas y descripción de la

interfaz de usuario.
Utilizar relaciones entre las entidades lógicas de la aplicación para permitir que la interfaz de
usuario las exponga y permita su exploración.
Validar valores de datos de entidades empresariales, para que la interfaz de usuario pueda de
forma activa aplicarlas (por ejemplo, el número máximo de direcciones por cliente o los formatos
de datos).
Puede exponer metadatos en forma de documentos XSD o XML con un esquema personalizado.
También se recomienda que cambie con frecuencia las reglas de validación como metadatos. Al diseñar las
reglas de validación como metadatos le permite cambiarlas sin que se vea afectada la implementación o
cambio de distribución de los componentes de entidades empresariales. Esto resulta especialmente
importante ya que las entidades empresariales puede que se utilicen desde los escritorios de clientes donde
la administración de cambios resulta costosa. Las reglas de validación para las entidades se podrían expresar
22 de 32 08/10/2009 05:31 p.m.

en un esquema XSD implementado con la aplicación.
Ubicación de servicios
En las llamadas a servicios remotos, es necesario determinar dónde están situados los objetos y servicios
externos de .NET que pueden procesar su solicitud y cómo tener acceso a ellos. Esto resulta especialmente
importante a la hora de utilizar servicios Web alojados por otras organizaciones o terceros.
Localización de ensamblados locales
.NET ofrece características extensivas que le permiten especificar los ensamblados a los que se puede vincular
en tiempo de ejecución. Para obtener información técnica más detallada sobre la forma en que .NET localiza
ensamblados locales cuando crea objetos, consulte "How the Runtime Locates Assemblies [
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconhowruntimelocatesassemblies.asp ] " en MSDN
Localización de las clases para .NET Remoting
.NET Remoting le permite realizar llamadas a objetos ubicados en otro dominio de aplicación, proceso o
equipo. Puede exponer los objetos que se van a utilizar por el sistema remoto y localizar los objetos que
desea llamar de forma remota especificando la información de configuración o escribiendo código en la
aplicación. Asimismo necesita que su aplicación conozca los canales que va a utilizar para la comunicación
remota.
Para obtener más información sobre el uso de la configuración de .NET Remoting para exponer tipos, buscar
tipos y registrar canales, consulte "Registering Remote Objects Using Configuration Files [
http://msdn.microsoft.com/library/en-us/cpguide
/html/cpconregisteringremoteobjectsusingconfigurationfiles.asp ] " en MSDN
Localización de colas de Message Queue Server para mensajería asincrónica
Para enviar un mensaje de la cola de mensajes Message Queue Server, necesita conocer a qué cola lo están
enviando. La forma en que hace referencia a las colas de Message Queue Server varía según la configuración
de Message Queue Server y si se está enviando mensajes por Internet.
Si Message Queue Server se ha instalado en la configuración de un dominio, puede localizar las colas por
nombre, identificador u otros atributos. Con MSMQ 2.0 (en Windows 2000), esta capacidad requiere que los
clientes y servidores en cola hagan referencia al mismo controlador de dominio que mantiene un registro de
colas existentes en Active Directory. En las configuraciones de dominio, puede especificar una etiqueta o
FormatName para identificar la cola.
Si ha instalado Message Queue Server en una configuración de grupo de trabajo del remitente, necesita
especificar la ruta completa de la cola. Para obtener más información sobre el uso de Message Queue Server,
consulte los siguientes artículos de MSDN:
MessageQueue.Path Property [ http://msdn.microsoft.com/library/en-us/cpref

/html/frlrfSystemMessagingMessageQueueClassPathTopic.asp ]
MessageQueue.QueueName Property [ http://msdn.microsoft.com/library/en-us/cpref

/html/frlrfSystemMessagingMessageQueueClassQueueNameTopic.asp ]
Localización de servicios Web en Internet y dentro de una organización
El URI para un servicio Web XML se puede recuperar dinámicamente en tiempo de ejecución desde el archivo
de configuración de la aplicación. Este enfoque mejora la capacidad de mantenimiento de la aplicación. Para
obtener más información sobre el almacenamiento de la información de la ubicación de servicios Web en el
archivo de configuración, consulte "Web References [ http://msdn.microsoft.com/library/en-us/vsintro7
/html/vxconWebReferences.asp ] " en MSDN
Existe una iniciativa industrial denominada UDDI (Descripción, descubrimiento e integración universales) para
ayudar a los servicios y empresas a encontrar otros servicios y exponer los servicios y sus interfaces a
llamadores interesados. UDDI está basado en estándares como SOAP, WSDL y DNS, lo que lo convierte
intrínsecamente en independiente de la plataforma. PUede utilizar un registro UDDI internacional para
exponer su servicio a socios y servicios externos. Asimismo, puede realizar una implementación de la
especificación UDDI en su empresa para ayudar a localizar e integrar servicios internos.
Microsoft proporciona servicios de UDDI de forma nativa con Microsoft Windows .NET Server. Para obtener
más información sobre esta característica, consulte el sitio Web de Windows .NET Server [
http://www.microsoft.com/windows.netserver/developers/default.mspx ] (http://www.microsoft.com
/windows.netserver/developers/default.mspx) (en inglés). Si no dispone de Microsoft .NET Server, también
puede utilizar Microsoft UDDI SDK [ http://www.microsoft.com/downloads
/release.asp.aspx?ReleaseID=35940 ] (en inglés) para instalar UDDI en un equipo local.
Para obtener más información sobre UDDI, consulte el sitio Web de UDDI [ http://www.uddi.org/default.aspx
] (en inglés) y los siguientes artículos de MSDN:
23 de 32 08/10/2009 05:31 p.m.

UDDI: Un servicio Web acerca de XML [ http://www.microsoft.com/spanish/msdn/articulos

/archivo/160301/voices/xml12182000.asp ]
Uso de UDDI en tiempo de ejecución [ http://www.microsoft.com/spanish/msdn/articulos/archivo

/280202/voices/Runtimeuddi1.asp ]
Diseño de la directiva de comunicaciones
La directiva de comunicaciones define la forma en que los componentes de la aplicación se comunicarán entre
sí. Esta directiva trata cuestiones como la sincronización de la comunicación, el formato y el protocolo, tal
como se muestra en la figura 3.4.
Figura 3.4. Aspectos de la directiva de comunicaciones
Elección del modelo de comunicación correcto
Debe considerar minuciosamente si los componentes de la aplicación se comunicarán a través de mensajes o

utilizando un enfoque conectado totalmente acoplado como DCOM o .NET Remoting. La comunicación
conectada resulta más fácil de diseñar e implementar, pero tiene limitaciones en términos de escalabilidad,
disponibilidad y administración.
Separación de la comunicación entre aplicaciones y dentro de la misma aplicación
La comunicación entre aplicaciones (es decir, la comunicación con servicios externos) se debería implementar
con un modelo basado en mensajes como los servicios Web XML basados en SOAP o Microsoft Message Queue
Server. Internamente, los componentes de la aplicación pueden requerir un mecanismos de comunicación
que proporcione un alto rendimiento y capacidades específicas como el flujo del contexto de seguridad o
transacciones. Puede lograr esto mediante el uso de los modelos de comunicación conectada como DCOM. Sin
embargo, cuando no es necesario el flujo de identidad o transacción, puede utilizar los servicios Web XML
entre las capas de la aplicación. Se recomienda que utilice un mecanismo de comunicación basado en
mensajes siempre que sea posible en la aplicación. Esto incluye la comunicación entre las capas de interfaz
de usuario, procesos empresariales y la interfaz de usuario y entre las interfaces de servicios y las capas
empresariales.
Nota
Los servicios Web XML no admiten actualmente el flujo de identidades o transacciones basado en estándares.
Global XML Web Services Architecture (GXA) tratará estos problemas mediante la definición de
especificaciones para las transacciones y seguridad. Encontrará más información sobre GXA en
http://msdn.microsoft.com/library/en-us/dnglobspec/html/wsspecsover.asp [ http://msdn.microsoft.com
/library/en-us/dnglobspec/html/wsspecsover.asp ] (en inglés).
Los distintos requisitos y limitaciones de la comunicación entre aplicaciones y dentro de la aplicación guiarán
en la mayoría de las decisiones tecnológicas. En muchos casos, puede que no sea un problema de
mantenimiento tener los componentes bien acoplados que se generan, implementan y administran como una
unidad. Sin embargo, en muchos casos puede que sea útil ver las distintas capas de aplicaciones como
servicios y esforzarse por tener el mismo poco acoplamiento entre capas de aplicaciones que se encuentran
entre servicios no relacionados. La figura 3.5 muestra este concepto.
24 de 32 08/10/2009 05:31 p.m.

Figura 3.5. Implementación de la comunicación entre las capas de presentación y empresarial

utilizando el bus de mensaje
En la figura 3.5 se muestra que la aplicación está diseñada como un servicio (1) al que se tiene acceso a
través de un bus de mensaje (2). La capa de presentación (3) utiliza la misma comunicación que otros
servicios de llamada (4), con posibilidades también de invocar directamente otros servicios (6). Los agentes
de servicios (5) invocan otros servicios utilizando también el bus de mensaje (6). La comunicación con los
componentes de datos se implementa de forma más realista mediante el empleo de otros mecanismos de
comunicación (7), a menos que los datos necesiten exponerse en los casos de datos a datos o de procesos a
datos, en cuyo caso los orígenes de datos también se podría tener acceso a ellos a través del bus de mensaje.
El uso del mismo bus de comunicación entre las capas y servicios produce un diseño más modular del
sistema, mientras que otros servicios pueden elegir partes más minuciosas de funcionalidad con los que
integrarse. También produce un nivel más alto de independencia entre los equipos y las plataformas
utilizadas para cada capa.
La visualización de capas como servicios puede resultar una visión convincente a largo plazo para un sistema,
pero puede suponer varios retos en cuando al diseño:
Las capas empresariales se pueden basar en tener un contexto com información de seguridad que
proporciona la interfaz de usuario, que puede que no esté disponible al intentar invocar la misma
lógica de una aplicación.
El bus de mensaje o comunicación debe admitir todos los requisitos de la comunicación dentro de
la aplicación, como un flujo de transacciones, transferencia eficiente de grandes nóminas, alto
rendimiento y baja latencia y transferencia de variada información de excepciones. Los estándares
están evolucionando en todas estas áreas, pero el modelo de desarrollo todavía requiere que su
uso no sea transparente.
Resulta difícil diseñar el mismo nivel de resistencia y disponibilidad entre la IU y las capas
empresariales como el nivel esperado entre servicios. La comunicación entre la interfaz de usuario
y los niveles empresariales es probablemente el mejor lugar para diseñar la comunicación basada
en los mismos estándares utilizados entre servicios. La comunicación entre los niveles
empresariales y datos de una aplicación sigue siendo territorio para mecanismos de comunicación
eficientes pero no genéricos.
Si su objetivo es tener un diseño de aplicación más tradicional y si la integración de servicios constituye sólo
un pequeño aspecto de la arquitectura global, puede que desee utilizar los servicios Web, intercambios de
25 de 32 08/10/2009 05:31 p.m.

mensajes basados en estándares con la finalidad de la integración sólo y utilizar DCOM o .NET Remoting para
la comunicación dentro de la aplicación, tal como muestra la figura 3.6.
Figura 3.6. Uso del bus de mensajes sólo para la integración
En la figura 3.6, los niveles de presentación, empresarial y de datos se comunican entre sí a través de
mecanismos de comunicación eficaces pero probablemente no estándares. El uso de la comunicación basada
en mensajes y en estándares sólo se utiliza para la integración, donde las interfaces de servicios aceptan las
llamadas de posibles llamadores externos (3 y 4) y agentes de servicios realizan las llamadas a otros servicios
(5 y 6).
La comunicación basada en mensajes, especialmente cuando se implementa asincrónicamente en un

transporte de almacenamiento y reenvío, ofrece la mejor alternativa de comunicación para la integración, pero
lo que se obtiene no es gratuito: debe considerar muchos problemas de diseño antes de poder implementarlo
correctamente.
Ventajas de la comunicación basada en mensajes asíncronos
El uso de un mecanismo de comunicación basada en mensajes asíncronos ofrece las siguientes ventajas:
Escalabilidad y disponibilidad: la comunicación basada en mensajes ofrece una mejor

escalabilidad y disponibilidad (ambos en términos de solidez y resistencia) para la aplicación y el
servicio. Con la comunicación basada en mensajes, puede utilizar mejor los recursos de hardware
y aislar la aplicación de los errores de software o infraestructura.
Transparencia de la ubicación: la comunicación basada en mensajes también proporciona una

auténtica transparencia de la funcionalidad remota, ya que no asume que hay presente una
conexión y que un mensaje siempre se puede enviar.
Similaridad con los modelos empresariales: los procesos empresariales reales se modela
principalmente de forma asincrónica, en términos de intercambios entre partes y usuarios. El uso
de comunicaciones basadas en mensaje puede proporcionar una asignación más limpia entre los
requisitos y el comportamiento de la aplicación.
Aislamiento de SLA: es más fácil definir y mantener SLAs en términos de intercambios de

mensajes. El uso de la comunicación basada en mensajes también permite aislar cuellos de
botella internos en los procesos empresariales internos o servicios externos de SLAs de
rendimiento que desea garantizar a sus usuarios.
Transport agnostic: una aplicación o servicio diseñado correctamente para la comunicación

basada en mensajes puede beneficiarse fácilmente de las nuevas tecnologías de mensajería a
medida que surgen.
26 de 32 08/10/2009 05:31 p.m.

Desventajas de la comunicación basada en mensajes
La comunicación basada en mensajes escasea. A medida que lea esta lista de consideraciones sobre el diseño,
tenga en cuenta las ventajas mencionadas anteriormente: el esfuerzo en el diseño de las comunicaciones
basadas en mensajes merece la pena durante la duración del servicio o aplicación. Las desventajas de la
comunicación basada en mensajes son:
Resultado determinista: en un escenario conectado, sabrá si la solicitud se realizó correctamente

o no al final de la misma. En la comunicación basada en mensajes, necesita tener en cuenta
estados adicionales en los que no se han recibido mensajes de devolución. Esto significa que
debe administrar el estado de conversación además de la lógica normal empresarial (por ejemplo,
puede que tenga que registrar mensajes enviados para su procesamiento posterior en el caso de
que no se reciba una respuesta).
Correlación de mensajes: debido a que no hay no un emparejamiento automático de los mensajes

enviados y recibidos, necesitará implementar un mecanismo de correlación que identifique que
un determinado mensaje incluye una instancia concreta de una conversación o proceso
empresarial. Puede implementar esta correlación en el transporte de mensajería (por ejemplo,
estableciendo los identificadores de la correlación en los mensajes de Message Queue Server) o
en los datos empresariales. La implementación de la correlación en los datos empresariales le
ayudará a cambiar con mayor facilidad el transporte de mensajería y lograr más fácilmente la
idempotencia de los procesos empresariales.
Retraso de los mensajes: los mensajes pueden llegar más tarde de lo esperado. Debe
implementar la lógica empresarial de modo que pueda tratar mensajes que nunca llegan.
También deberá diseñar la lógica de recepción de mensajes para asegurarse de que el mensaje
sigue siendo válido cuando se recibe. Por ejemplo, si está recibiendo un pedido, podría especificar
un tiempo de inactividad tras el cual el pedido no se procesará. Considere el caso en el que los
precios del catálogo han cambiado entre el envío del pedido por el llamador y el recibo del
mensaje. En este caso, necesitará especificar si el pedido se procesa con los nuevos precios, los
precios de ese momento o no se procesa directamente. Puede resultar útil en algunos casos para
el mensaje incluir datos de referencia esenciales en los que se basa (como, por ejemplo, los
precios de los productos) de modo que la lógica empresarial pueda realmente comparar y tomar
decisiones más minuciosas sobre lo que debe hacer con el mensaje.
Flujo de transacciones: la comunicación basada en mensajes implica un modelo de transacción

distinto. Si está utilizando un transporte transaccional (como colas transaccionales de Message
Queue Server), una confirmación de transacción asegurará que se realiza la operación enviar. No
podrá enviar un mensaje transaccional y recibir su respuesta en el contexto de una sola
transacción atómica. Esto significa que necesitará administrar conversaciones que incluyan varios
intercambios en una transacción de ejecución larga y exponer las actividades de compensación
adecuadas.
Mensajes repetidos: la lógica necesitará controlar un caso especial en el que los mensajes pueden
llegar más de una vez. Puede implementarla mediante el diseño de los procesos y la lógica de
forma que sean idempotentes al recibir el mismo mensaje más de una vez. Por ejemplo, en un
servicio de procesamiento de pagos que carga los fondos de la cuenta de un cliente y los abona
en la cuenta del proveedor, debe evitar transferir el importe de una compra en particular varias
veces si el mensaje de solicitud de pago se recibe más de una vez. Puede evitar este problema
solicitando que se suministre un Id. de transacción con la solicitud de pago e ignorar las
siguientes solicitudes con el mismo Id. de transacción. También puede lograr la idempotencia
mediante la especificación de los datos anteriores y nuevos para las operaciones que actualizarán
la base de datos. En este caso, la recepción de un mensaje para cambiar el atributo de envío de
un pedido de No a Sí dos veces no es un problema (si la lógica empresarial lo determina así).
Secuencia de mensajes: si espera más de un mensaje entrante, puede que no reciba los
mensajes en la secuencia esperada. En este caso, puede controlar esto en el estado de
conversación o en la lógica empresarial. Puede obligar la secuencia en la lógica empresarial
haciendo que la conversación dependa de las confirmaciones. Por ejemplo, podría determinar que
todos los mensajes de actualización de pedidos tengan un Id. que haya proporcionado al emisor.
Esta técnica de diseño derrota algunas de las ventajas de la comunicación basada en mensajes,
por lo que deberá utilizarla únicamente cuando sea necesaria.
Escenarios para la comunicación basada en mensajes
Debería diseñar una interfaz para la aplicación o servicio que se va a basar en mensajes (como cuando se
utiliza SOAP) y se base en mecanismos de almacenamiento y reenvío asincrónico como Message Queue
27 de 32 08/10/2009 05:31 p.m.

Server cuando:
Esté implementando un sistema empresarial que representa una inversión media a largo plazo;
por ejemplo, al crear un servicio que se expondrá y será utilizado por los socios durante un
período largo de tiempo.
Está implementando sistemas a gran escala con características de alta escalabilidad.
Está generando un servicio que desea aislar de otros servicios que utiliza y de servicios en los que
se expone.
Espera que la comunicación de ambos puntos finales no estén disponibles esporádicamente,

como en el caso de aplicaciones o redes inalámbricas que se puedan utilizar sin conexión.
Sincronización
Es frecuente pensar en la comunicación basada en mensajes como modelo asincrónico. Por ejemplo, es
evidente que dos aplicaciones que se comunican entre sí a través de Message Queue Server lo están haciendo
utilizando mensajes. Sin embargo, la comunicación basada en mensajes también se puede encapsular en un
modelo de programación asincrónico (por ejemplo, utilizando servidores proxy de servicios Web generados
por Microsoft Visual Studio® .NET), en el que el cliente espera un mensaje de respuesta. En este caso, el
desarrollador de la aplicación puede beneficiarse de las ventajas de la comunicación basada en mensajes sin
tener que tratar las complejidades de la programación en un modelo asincrónico.
Para obtener más información, consulte "Architectural Options for Asynchronous Workflow" [
http://msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch12.asp ] en MSDN
Elección de tecnologías para las comunicaciones asincrónicas
Se pueden utilizar distintos enfoques para la comunicación asincrónica, incluidos los enfoques basados en
mensajes como Message Queue Server y XML Web Services y tecnologías conectadas como .NET Remoting y
DCOM. De estos enfoques, las tecnologías de cola ofrecen el nivel de flexibilidad y de variedad de
características más alto. Message Queue Server proporciona un transporte de mensajería de almacenamiento
y reenvío para su uso en aplicaciones. Además de la escalabilidad y disponibilidad, Message Queue Server
proporciona varias opciones de desarrollo para ayudar al desarrollo e implementación de la aplicación en
distintos escenarios
Message Queue Server proporciona las siguientes opciones y características:
Mensajes con servicio de almacenamiento y reenvío por Internet.
Mensajería transaccional con exactamente garantía de entrega una vez del mensaje.
Almacenamiento basado en clúster para una alta disponibilidad.
Puede consultar más información sobre la siguiente versión de Message Queue Server en
http://www.microsoft.com/msmq/MSMQ3.0_whitepaper_draft.doc [ http://www.microsoft.com
/msmq/MSMQ3.0_whitepaper_draft.doc.aspx ]
Al utilizar Message Queue Server, necesitará determinar la tecnología del extremo y el formato del mensaje.
Se encuentran disponibles los siguientes extremos y formatos:
Al utilizar Message Queue Server, necesitará determinar la tecnología del extremo y el formato del mensaje.
Se encuentran disponibles los siguientes extremos y formatos:
Envío y recepción de extremos

Puede desarrollar código que utilice los objetos en el espacio de nombres System.Messaging, o
bien utilizar el servicio de desencadenadores de Message Queue Server para la escucha de los
mensajes. Si controla ambos extremos y no tiene ningún requisito para el formato de los
mensajes, puede utilizar Enterprise Services Queued Components, que encapsula totalmente el
desarrollo relacionado con Message Queue Server. Los extremos también pueden incluir
aplicaciones basadas en COM, puertos de BizTalk Server y puentes a MQSeries y otras tecnologías
de mensajería.
Formatos
Puede utilizar formatos de SOAP, binarios y de Microsoft ActiveX®. SOAP se utiliza para obtener
un máximo de interoperabilidad, el binario para obtener una eficacia en el tamaño de los
mensajes y ActiveX para la interoperabilidad con remitentes y agentes de escucha basados en
COM. Debido a que está basado en COM, los activadores de MSMQ requieren el uso del formato de
ActiveX. Queued Components envían mensajes en un formato DCE RPC opaco, que se mantiene
28 de 32 08/10/2009 05:31 p.m.

transparente para el desarrollador.
Enterprise Services Queued Components
Puede utilizar Enterprise Services Queued Components cuando:
Controle tanto el remitente como el receptor del mensaje.
El componente de recepción es un componente con servicio.
Es indiferente el formato del mensaje (será un formato binario RPC NDR opaco)
Queued Components cuenta con las siguientes ventajas:
Puede utilizar la autorización basada en funciones de Enterprise Services sin necesidad de

desarrollo adicional para firmar el mensaje en el remitente.
Puede utilizar el mecanismo de reintento integrado en Message Queue Server para asegurarse de
que los mensajes se ejecutan finalmente.
Puede utilizar las clases de excepciones para obtener la notificación de errores de forma que
pueda realizar acciones alternadas.
Los mensajes se pueden enviar tanto con los remitentes COM como .NET.
Puede fácilmente trabajar con transacciones de forma transparente con el modelo Enterprise
Services.
Desencadenadores de Message Queue Server
Los desencadenadores de Message Queue Server proporcionan un servicio de escucha. Utílicelos cuando:
No controle los remitentes
Necesite desencadenar un archivo .exe o componente COM cuando llegue un mensaje.
El formato del mensaje puede ser ActiveX.
Esté preparado para implementar la función del receptor como un componente basado en
.NETque se invocará utilizando la interoperabilidad COM.
Receptores personalizados
Escribir un receptor personalizado ofrece el máximo grado de control con respecto al formato,
comportamiento de reintentos, administración de excepciones, etc. Sin embargo, no se recomienda que
desarrolle su propio servicio de escucha ya que esto requiere habilidades en la administración de
comunicación asincrónica, subprocesamiento múltiple, seguridad y administración de excepciones. Si crea su
propio servicio de receptor, debería probarlo ampliamente antes de implementarlo.
Tecnologías asincrónicas alternativas
Como alternativa al uso de Message Queue Server, puede también crear un proxy de servicios Web XML con
Visual Studio .NET, en cuyo caso cada método expuesto por el servicio Web se puede llamar asincrónicamente
con el método Begin<nombre del método> y especificar una función de devolución de llamada.
También puede utilizar devolución de llamadas para implementar invocaciones a métodos asincrónicos a
través de los canales de .NET Remoting. Para obtener más información sobre la implementación de
operaciones asincrónicas con .NET Remoting, consulte la sección sobre el entorno remoto asincrónico en la
documentación de .NET Framework [ http://msdn.microsoft.com/library/en-us/cpguide
/html/cpconasynchronousremoting.asp ] en MSDN
Selección de tecnologías para las comunicaciones sincrónicas
.NET proporciona varias opciones para la comunicación sincrónica. Cada opción está definida como una
combinación de un extremo (por ejemplo, IIS), un protocolo (por ejemplo, HTTP) y un formato (por ejemplo,
SOAP). Cada combinación posible representa un canal a través del cual tiene lugar la comunicación. También
puede implementar los canales personalizados definiendo su propia combinación de extremo, protocolo y
formato.
Los canales tienen numerosos atributos, la importancia de cada depende de los componentes que se están
29 de 32 08/10/2009 05:31 p.m.

intercomunicando. Estos atributos incluyen:
Capacidad de flujo de contexto de transacciones.
Amplitud de alcance a distintos clientes en diferentes plataformas.
Capacidades de seguridad (autenticación, autorización y cifrado de canales).
Requisitos del protocolo sobre la infraestructura de redes.
Eficacia como función del tipo y tamaño de los datos que se transmiten.
Responder a las siguientes preguntas le ayudará a elegir una tecnología de comunicación sincrónica basada
en sus requisitos:
1. ¿Es necesario un flujo de transacciones o establecer un flujo del contexto de seguridad de Windows?
Si es así, utilice DCOM. Sus extremos se alojarán en Enterprise Services para beneficiarse de las
transacciones. El que realiza la llamada podrá conocer la identidad del llamador original del
componente mediante el uso de la clase SecurityCallContext.
Si no es así, vaya a la pregunta 2.
2. ¿Necesita un mayor alcance?

Si necesita exponer su servicio de una forma estándar para asegurarse el máximo alcance, puede
utilizar SOAP y HTTP para implementar los servicios Web XML. Puede exponer servicios Web de dos
formas en Windows 2000: con los archivos ASP.NET .asmx o el canal remoto HTTP/SOAP. Vaya a la
pregunta 4.
Si no es así, vaya a la pregunta 3.
3. ¿Es necesario autenticar al autor de llamada?

Si no necesita transacciones, flujo de seguridad o un amplio alcance puede utilizar los canales de .NET
Remoting. .NET Remoting se basa en IIS para realizar la autenticación del llamador cuando realiza la
llamada por HTTP, por lo que necesitará disponer de un extremo IIS si necesita la autenticación.
Si no necesita la autenticación, puede utilizar cualquier canal de .NET Remoting alojado en cualquier
proceso.
4. ¿Necesita implementar el código de fachada para exponer la funcionalidad empresarial?

Si necesita ajustar la lógica empresarial en una fachada adicional, para realizar una validación,
transformación o incluso un almacenamiento en caché adicional, puede utilizar los servicios Web de
ASP.NET para implementar fácilmente funciones que puede llamar SOAP.
Si no necesita una capa de fachada ampliada, puede exponer sus tipos directamente como servicios
Web. Tenga en cuenta que no puede exponer clases Enterprise Services directamente. Si los
componentes empresariales son Serviced Components, necesitará crear una capa de fachada con los
servicios Web de ASP.NET o las clases remotas en Windows 2000.
Nota
El uso de DCOM con los últimos arreglos le permitirá establecer comunicación a través de únicamente un
puerto conocido. Para obtener más información, consulte los siguientes artículos de Knowledge Base:
Q154596—HOWTO: Configure RPC Dynamic Port Allocation to Work with Firewall [

http://support.microsoft.com/support/kb/articles/q154/5/96.asp ]
Q312960—Cannot Set Fixed Endpoint for a COM+ Application [ http://support.microsoft.com

/default.aspx?scid=kb;en-us;q312960 ]
Para obtener más información sobre la decisión entre los servicios Web XML y .NET Remoting, consulte
"Choosing Communication Options in .NET [ http://msdn.microsoft.com/library/en-us/cpguide
/html/cpconchoosingcommunicationoptionsinnet.asp ] " (en inglés) en la documentación de .NET Framework
en MSDN
Las siguientes fuentes proporcionan más información sobre .NET Remoting:
Exposing Existing Code as a Web Service Using the .NET Framework
An Introduction to Microsoft .NET Remoting Framework [ http://msdn.microsoft.com/library

/en-us/dndotnet/html/introremoting.asp ]
Sitio Web de DotNetRemoting.cc [ http://www.dotnetremoting.cc/default.aspx ]
Performance Comparison: Exposing Existing Code as a Web Service [ http://msdn.microsoft.com

/library/en-us/dnbda/html/bdadotnetarch11.asp ]
30 de 32 08/10/2009 05:31 p.m.

Advanced .NET Remoting por Ingo Rammer (ISBN 1590590252)
Recomendaciones para comunicaciones
Al implementar el servicio y la aplicación, tenga en cuenta estas recomendaciones:
Corte las cadenas de llamadas con colas y cachés según sea necesario. De este modo, mejorará la
escalabilidad y disponibilidad de la solución en general.
Acerque los límites asincrónicos al usuario, interfaces de servicios y agentes de servicios, para
aislar el servicio de dependencias externas.
Si necesita exponer funcionalidad como operación sincrónica, evalúe si puede ajustar una
operación asincrónica internamente tal como se describe en el siguiente apartado.
Encapsulación de la comunicación asincrónica en solicitudes sincrónicas
El diseño de la aplicación debería impulsar el uso de las comunicaciones asincrónicas todo lo posible. Sin
embargo, en algunos casos, es razonable o inevitable que el cliente espere una respuesta sincrónica. Puede
que desee basarse en un diseño totalmente asincrónico solamente si el servicio al que llama no cumple las
expectativas en términos de tiempos de respuesta. Este patrón se aplica principalmente implementar agentes
de servicios.
Puede diseñar los componentes de modo que utilice las operaciones asincrónicas, sin embargo puede
proporcionar una interfaz sincrónica para los llamadores. El diseño básico para lograr esto es el siguiente:
1. El llamador envía una solicitud sincrónica a un componente.
2. El componente recibe la solicitud y, como mínimo, crea o identifica un Id. o cookie para identificar
inequívocamente esta solicitud, al que la entrada de base de datos le realiza una copia de seguridad
óptima.
3. El servidor envía una solicitud asincrónica al servicio.
4. El componente se establece en espera de un mensaje de respuesta, con un tiempo de espera
5. Si el componente recibe el mensaje a tiempo, genera la respuesta y la devuelve al llamador sincrónico.
6. Si el componente no recibe el mensaje a tiempo, devuelve una respuesta repetitiva con el Id. de
solicitud al llamador o una excepción que puede controlar el llamador. El componente de servidor se
debería entonces desactivar.
7. A continuación, tiene dos opciones para obtener el resultado en el llamador:
El llamador puede entonces invocar a un componente de servidor (quizás una función

distinta en el mismo componente) para obtener el resultado después de cierto tiempo
(segundos o minutos) basado en el Id. de solicitud. Si el llamador es un usuario humano,
es una práctica frecuente entretenerlo con alguna animación gráfica.
El servidor notifica al llamador empleando un mecanismo asincrónico, como una

notificación del usuario (correo electrónico, Windows Messenger o un mensaje de
localizador) o bien envía un mensaje de vuelta al cliente para que pueda visualizar el
resultado correcto. En este caso, la aplicación o el usuario debe tener un receptor de
mensajes como un correo electrónico o una ruta de mensaje a Message Queue Server. Si
utiliza Message Queue Server, debería correlacionar el mensaje de devolución con el Id. de
correlación.
Formato, esquema y protocolo de comunicaciones
El formato en que se envían y reciben datos y el esquema de los datos que intercambia son factores
importantes al diseñar la comunicación de la aplicación.
Los siguientes factores influyen en el formato y esquema:
¿Controla ambos extremos de la comunicación? Si es así, puede elegir formatos y protocolos que
optimicen el rendimiento y proporcionen características adicionales (como el flujo de seguridad o
transacción) a costa de la amplia interoperabilidad. Este es el caso cuando está comunicando las
capas de la aplicación y considera que todos los niveles están totalmente relacionados o
acoplados.
31 de 32 08/10/2009 05:31 p.m.

¿Desea que llamadores externos dentro y fuera de la organización puedan tener acceso al
servicio? Si es así, debería decidirse por estándares ampliamente aceptados de protocolos (como
TCP), formatos (por ejemplo SOAP) e incluso esquemas (por ejemplo, utilizar esquemas en
www.uddi.org), especialmente para interfaces y agentes de servicios. Si el servicio con el que se
pone en contacto o su propia comunicación no se basa en estándares, puede que necesite utilizar
puentes o capas de traducción adicionales entre los extremos.
Un vistazo al futuro
La comunicación de servicios basada en estándares de la industria está madurando rápidamente y Microsoft

está proporcionando instrumentos en su próxima generación de productos para facilitar aún más la exposición
y consumo de la funcionalidad empresarial a través de los mecanismos estándar.
Los siguientes vínculos proporcionan más información
Servicios Web COM+: La ruta de la casilla de verificación a los servicios Web XML [
http://msdn.microsoft.com/library/en-us/dndotnet/html/comwscheckb.asp ]
El entorno de aplicación de Windows Server 2003 [ http://www.microsoft.com/spain/servidores

/windowsserver2003/evaluation/overview/technologies/appsrvcs.mspx ]
Introducción a GXA: Global XML Web Services Architecture [ http://www.microsoft.com/spanish

/msdn/articulos/archivo/151102/voices/introd_gxa.asp ]
Confiabilidad de XML Web Services [ http://www.microsoft.com/latam/windowsserver2003

/evaluation/overview/standard.mspx ]
http://msdn.microsoft.com/webservices [ http://msdn.microsoft.com/webservices/ ]
http://www.gotdotnet.com/team/XMLwebservices/default.aspx [ http://www.gotdotnet.com
/team/XMLwebservices/default.aspx ]
http://www.gotdotnet.com/team/XML_wsspecs/ [ http://www.gotdotnet.com
/team/XML_wsspecs/ ]
http://discuss.develop.com/ [ http://discuss.develop.com/default.aspx ]
Próximamente
En este capítulo se describen las directivas de seguridad, administración operativa y comunicaciones. El

capítulo 4, "Implementación física y requisitos operativos [ http://msdn.microsoft.com/es-es/library
/ms978363.aspx ] ", describe las estrategias para la implementación de la aplicación en un entorno físico y
trata las distintas formas de obtener los requisitos operativos.
Comentarios y soporte
Si desea formular alguna pregunta, o realizar algún comentario o sugerencia sobre esta guía, envíe un
mensaje de correo electrónico a la siguiente dirección: devfdbck@microsoft.com.
32 de 32 08/10/2009 05:31 p.m.

Diseño de Aplicaciones - Directivas de Seguridad, Administración Operativa y Comunicaciones Cap III

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diseño de Aplicaciones - Directivas de Seguridad, Administración Operativa y Comunicaciones Cap III

Uploaded by

Copyright:

Available Formats

Diseño de aplicaciones y servicios http://msdn.microsoft.com/es-es/library/ms978357(printer).

©2009 Microsoft Corporation. All rights reserved.

Diseño de aplicaciones y servicios

Patterns & Practices

Figura 3.1. Efecto de las directivas organizativas en el diseño de aplicaciones

Este es el capítulo 3 de Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios. Comience

1 de 32 08/10/2009 05:31 p.m.

por aquí [ http://msdn.microsoft.com/es-es/library/ms978340.aspx ] para obtener una visión general

Diseño de la directiva de seguridad

Diseño de la directiva de seguridad

La directiva de seguridad se ocupa de la autenticación, autorización, comunicación segura, auditoría y

Figura 3.2. Aspectos de la directiva de seguridad

Principios generales sobre seguridad

Reduzca el área de superficie. El riesgo se incrementa según aumenta el número de componentes

Establezca como predeterminado un modo seguro. No habilite servicios, tecnologías y derechos

2 de 32 08/10/2009 05:31 p.m.

Bloquee su sistema interna y externamente: los usuarios y operadores internos pueden

La autenticación se debe implementar en la capa de la interfaz de usuario para proporcionar funciones de

Flujo de la identidad entre los niveles

Considere los siguientes escenarios:

El llamador y la aplicación a la que se llama no comparten el subsistema de seguridad de la

El llamador y la aplicación a la que se llama se encuentran en dominios de Microsoft Windows®

Windows 2000 Kerberos Delegation [ http://msdn.microsoft.com/library

Impersonating and Reverting [ http://msdn.microsoft.com/library

3 de 32 08/10/2009 05:31 p.m.

El llamador y la aplicación a la que se llama comparten un mecanismo de autenticación que no

El llamador y la aplicación a la que se llama se ejecutan en el mismo contexto. En este escenario,

Autenticación con otros servicios

Mecanismos de autenticación personalizada

Puede que necesite un mecanismo de autenticación personalizada en su aplicación si ha comprobado que no

Implemente la autenticación de usuario en un objeto Identity personalizado. Deberá disponer de

Agregue un atributo StrongNameIdentityPermission a los métodos cuando desee asegurarse de

Exponga el símbolo de autenticación como propiedad del objeto Identity. El símbolo de

4 de 32 08/10/2009 05:31 p.m.

Autenticación en la capa de presentación

Las interfaces de usuario basadas en Windows generalmente confían en un mecanismo de autenticación

Autenticación en los componentes empresariales

Un componente de interfaz de usuario

Un componente de proceso de usuario

Otro componente de proceso empresarial

La identidad del llamador puede ser:

Un socio externo para el que tiene una "cuenta de servicio" especial.

Autenticación en los componentes de acceso a datos

Mediante el uso de cuentas de servicios.

5 de 32 08/10/2009 05:31 p.m.

Utilice cuentas de servicios si:

Se conecta al origen de datos subyacente de un entorno en el que la representación del llamador

El almacén de datos al que tiene acceso dispone de un mecanismo de autenticación diferente al

El acceso al almacén de datos a través de un gran número de cuentas niega la agrupación de

No utilice cuentas de servicios si:

El almacén de datos realiza la auditoría de actividades y estas auditorías se deben asignar a

Necesita la representación del llamador si:

El almacén de datos realiza la autorización basada en el usuario con sesión iniciada.

Se utilizan normalmente dos mecanismos de implementación para representar a los llamadores:

Servicios de representación de plataforma. Windows 2000 y versiones posteriores ofrecen la

La representación generalmente sólo se admite si dispone del mismo mecanismo de autenticación

En Windows 2000, el nivel de representación proporcionado por la plataforma a través de varios

6 de 32 08/10/2009 05:31 p.m.

Autenticación en los componentes de entidad empresarial

El aspecto de la autorización de la directiva de seguridad se ocupa de la identificación de las acciones

Los permisos y derechos de usuario.

La seguridad de acceso al código.

Debe incluir los resultados en la siguiente matriz en el diseño de control de acceso: