Compartir a través de

  • Artículo

Seguridad de diálogo de Service Broker

La seguridad de diálogo proporciona cifrado, autenticación remota y autorización remota para una conversación específica. Cuando una conversación emplea seguridad de diálogo, Service Broker cifra todos los mensajes que se envían fuera de una instancia de SQL Server. Las conversaciones de Service Broker utilizan seguridad de diálogo de forma predeterminada.

La seguridad de diálogo de Service Broker permite que una aplicación utilice autenticación, autorización o cifrado en una conversación individual de diálogo (o en un diálogo). De forma predeterminada, todas las conversaciones de diálogo utilizan la seguridad de diálogo. Cuando inicia un diálogo, puede permitir explícitamente que continúe sin seguridad de diálogo; para ello, debe incluir la cláusula ENCRYPTION = OFF en la instrucción BEGIN DIALOG CONVERSATION. Sin embargo, si existe un enlace de servicio remoto para el servicio al que se destina la conversación, el diálogo utiliza seguridad incluso cuando ENCRYPTION = OFF.

En el caso de un diálogo que utiliza seguridad, Service Broker cifra todos los mensajes que se envían fuera de una instancia de SQL Server. Los mensajes que permanecen en una misma instancia de SQL Server no se cifran en ningún caso. En la seguridad de diálogo, sólo la base de datos que aloja el servicio iniciador y la base de datos que aloja el servicio de destino deben tener acceso a los certificados que se utilizan para la seguridad. Es decir, una instancia que realiza el reenvío de mensajes no tiene que tener la capacidad de descifrar los mensajes que reenvía.

Service Broker proporciona dos tipos de seguridad de diálogo, seguridad completa y seguridad anónima. En las conversaciones que utilizan seguridad de diálogo, Service Broker proporciona autorización remota para asignar el extremo remoto de la conversación a un usuario local.

Los mensajes se cifran en la red cuando la conversación utiliza seguridad completa o seguridad anónima. Sin embargo, los derechos efectivos en la base de datos de destino y la estrategia utilizada para cifrar mensajes son ligeramente distintos en los dos enfoques.

Si la conversación utiliza seguridad completa o seguridad anónima, el cuerpo del mensaje está cifrado con una clave de sesión simétrica que se genera para la conversación específica. Únicamente las claves se cifran con cifrado de clave privada mediante el certificado proporcionado por la seguridad de diálogo. Service Broker también realiza una comprobación de integridad de mensajes para ayudar a detectar alteraciones o daños en los mensajes.

SQL Server crea una clave de sesión para una conversación que utilice seguridad de diálogo. Para proteger la clave de sesión mientras está almacenada en la base de datos, Service Broker la cifra con la clave maestra de la base de datos. Si la clave maestra de la base de datos no está disponible, los mensajes de la conversación permanecen en transmission_status con un error hasta que se cree una clave maestra para la base de datos o hasta que se agote el tiempo de la conversación. Por tanto, las dos bases de datos que participan en la conversación deben contener claves maestras, incluso cuando las bases de datos están alojadas en la misma instancia. Si la base de datos iniciadora no contiene una clave maestra, el diálogo generará errores. Si la base de datos de destino no contiene una clave maestra, los mensajes permanecerán en la cola de transmisión de la base de datos iniciadora. El último error de transmisión de estos mensajes indica el motivo por el que los mensajes no se pueden entregar. Utilice el parámetro ENCRYPTION = OFF para crear un diálogo no cifrado o bien utilice el comando siguiente para crear una clave maestra de base de datos:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>'

Para mayor comodidad, Service Broker permite que las conversaciones seguras que permanecen en una única base de datos continúen independientemente de que la base de datos contenga una clave maestra. Aunque dos bases de datos se puedan mover a instancias de SQL Server distintas durante la vigencia de una conversación, una conversación de una única base de datos siempre permanecerá en esa base de datos. Por tanto, la conversación podrá continuar.

Seguridad completa

La seguridad completa ayuda a evitar que el servicio iniciador envíe mensajes a una base de datos sin confianza, así como a evitar que el servicio de destino reciba mensajes de una base de datos sin confianza. Service Broker cifra los mensajes transmitidos a través de la red cuando la conversación utiliza seguridad completa.

La seguridad completa proporciona identificación para el servicio iniciador y para el servicio de destino. Esta seguridad requiere que el servicio iniciador confíe en el servicio de destino y que el servicio de destino confíe en el servicio iniciador. Por ejemplo, un servicio que realiza un pedido de piezas de un proveedor puede requerir que la aplicación de pedidos confíe en el servicio de proveedor y viceversa.

Los administradores de base de datos establecen la confianza mediante el intercambio de certificados que contiene claves públicas. En el caso de la seguridad de diálogo completa, cada extremo de la conversación contiene una clave privada para un usuario local y una clave pública para un usuario remoto. La base de datos que aloja al servicio iniciador contiene un enlace de servicio remoto. Este enlace de servicio remoto especifica el usuario local que posee el certificado que corresponde a la clave privada en la base de datos remota. Por tanto, las operaciones en nombre del servicio iniciador se ejecutan como el usuario designado en la base de datos de destino.

La base de datos de destino contiene un usuario. Este usuario posee un certificado que corresponde a una clave privada propiedad del usuario que posee el servicio iniciador. Por tanto, las operaciones en nombre del servicio de destino se ejecutan en la base de datos iniciadora como el usuario que posee el servicio iniciador.

Para los diálogos que utilizan seguridad completa, cada extremo de la conversación genera una clave de sesión. El primer mensaje en cada dirección contiene la clave de sesión, cifrada con una clave de intercambio de claves, como se describe en Certificados y Service Broker.

Seguridad anónima

La seguridad anónima ayuda a evitar que el servicio iniciador envíe mensajes a una base de datos sin confianza. Service Broker cifra los mensajes transmitidos a través de la red cuando la conversación utiliza seguridad anónima.

La seguridad anónima identifica el servicio de destino en el servicio iniciador, pero no identifica el servicio iniciador en el servicio de destino.

Por ejemplo, una aplicación que envía pedidos de trabajo puede necesitar garantizar que el destinatario del pedido de trabajo es el destino deseado, pero puede que la base de datos de destino no necesite proporcionar ningún privilegio especial a un servicio que envía pedidos de trabajo. En este caso, la base de datos que contiene el servicio iniciador debe contener un enlace de servicio remoto al servicio de destino.

Dado que el servicio de destino no puede comprobar la identidad del servicio iniciador, las operaciones en nombre del servicio iniciador se ejecutan como un miembro de la función fija de base de datos public en la base de datos de destino. La base de datos de destino no recibe ninguna información sobre el usuario que inició la conversación. La base de datos de destino no necesita contener ningún certificado para el usuario que inicia la conversación.

En los diálogos que utilizan seguridad anónima, ambos extremos de la conversación utilizan la clave de sesión generada por la base de datos iniciadora. La base de datos de destino no devuelve ninguna clave de sesión a la base de datos iniciadora.

La autorización remota de Service Broker controla el acceso remoto a un servicio individual. La autorización remota determina el contexto de seguridad en el que se envían los mensajes entrantes en una instancia de SQL Server a un servicio.

Service Broker siempre utiliza la autorización remota para una conversación segura que no tiene lugar íntegramente en una instancia de SQL Server. La seguridad de diálogo que se configura para la conversación determina el contexto de seguridad que Service Broker utiliza para la autorización remota.

Service Broker no utiliza la autorización remota cuando la conversación permanece en una instancia de SQL Server, incluso si la autorización remota está configurada. En el caso de una conversación en una única instancia, las entidades de seguridad de SQL Server ya están disponibles para SQL Server, por lo que no es necesario utilizar la autorización remota para determinar el contexto de seguridad correcto para operaciones de Service Broker. Sin embargo, como se ha descrito anteriormente en este tema, Service Broker crea una clave de sesión para que la conversación pueda continuar si una de las bases de datos se mueve a otra instancia durante la conversación.

En el caso de una conversación que utilice seguridad anónima, la conexión se ejecuta como un miembro de la función fija de base de datos public de la base de datos de destino. En este caso, la función fija de base de datos public debe tener permiso para enviar un mensaje al servicio. Sin embargo, la función no necesita otros permisos en la base de datos.

En el caso de una conversación que utiliza seguridad completa, la conexión en cada extremo de la conversación actúa con los permisos del usuario que se especifica en el enlace de servicio remoto. Por ejemplo, si un enlace de servicio remoto asocia el nombre de servicio InventoryService con el usuario InventoryServiceRemoteUser, SQL Server utiliza el contexto de seguridad de InventoryServiceRemoteUser para colocar mensajes para la aplicación InventoryService en la cola del servicio de destino.

Para mejorar la seguridad, el usuario que posee la clave privada de un servicio suele ser un usuario distinto del especificado para la activación. Un usuario que posee una clave privada sólo necesita permiso para agregar un mensaje a la cola, es decir, el permiso SEND para el servicio que utiliza la cola. Por otro lado, el usuario que se especifica para la activación tiene los permisos necesarios para realizar el trabajo solicitado y enviar una respuesta. En el ejemplo anterior, InventoryServiceRemoteUser no necesita permisos para consultar la tabla de inventario ni para enviar un mensaje de respuesta. El usuario sólo necesita permisos para enviar un mensaje a la cola que utiliza InventoryService. La activación de procedimientos almacenados se produce en una sesión distinta con las credenciales que especifica la cola. No es necesario compartir ninguna credencial entre la sesión que pone en cola el mensaje y la sesión que lo procesa.

Crear un diálogo seguro

Cuando Service Broker establece un diálogo entre dos bases de datos, el servicio iniciador debe establecer un contexto de usuario en la base de datos de destino para poder colocar mensajes en la cola de destino. Este contexto de usuario determina si el servicio de inicio tiene permiso para abrir un diálogo con el destino.

La manera más flexible de llevar esto a cabo consiste en crear un certificado y un enlace de servicio remoto. Para obtener más información acerca de cómo crear un certificado, vea CREATE CERTIFICATE (Transact-SQL). Para obtener más información acerca de cómo crear un enlace de servicio remoto, vea CREATE REMOTE SERVICE BINDING (Transact-SQL).

Una alternativa a la creación de un certificado y un enlace de servicio remoto es utilizar la seguridad de SQL Server para establecer una relación de confianza entre las dos bases de datos. El propietario del servicio de inicio suplanta a un usuario en el servicio de destino. Es posible que sea necesario establecer la propiedad de base de datos TRUSTWORTHY en la base de datos de inicio en ON y conceder permiso de autenticación a un usuario en la base de datos de destino. Para obtener más información, vea Extender la suplantación de la base de datos mediante EXECUTE AS.

[!NOTA]

Si el contexto de seguridad no está configurado correctamente, los mensajes enviados en el diálogo permanecerán en sys.transmission_queue en el servicio de inicio con el siguiente mensaje de error en la columna transmission_status: La entidad de seguridad de servidor '%.*ls' no puede tener acceso a la base de datos '%.*ls' en el contexto de seguridad actual.