Compartir a través de

  • Artículo

Certificados para la seguridad de diálogo

Cuando se inicia una conversación, Service Broker utiliza los enlaces de servicio remoto para encontrar el certificado que se utilizará. En este tema se describe la forma en que Service Broker determina el certificado que se utilizará en la conversación.

Service Broker busca en primer lugar un enlace de servicio remoto para la conversación y, a continuación, selecciona un certificado propiedad del usuario especificado en el enlace.

Para localizar un enlace, Service Broker busca en la base de datos un enlace que especifique el nombre del servicio de destino de la conversación.

Para seleccionar un certificado, Service Broker busca el certificado con la última fecha de caducidad propiedad del usuario especificado en el enlace de servicio remoto. Service Broker no tiene en cuenta los certificados que aún no son válidos, los que han caducado ni los que no están marcados como disponibles para iniciar un diálogo. Para obtener más información sobre los certificados, vea CREATE CERTIFICATE (Transact-SQL).

Si no existe ningún enlace de servicio remoto o el usuario del enlace de servicio remoto no posee un certificado válido para iniciar el diálogo, Service Broker no podrá cifrar mensajes para la conversación. Si no existe ningún enlace y la base de datos contiene un servicio de configuración del broker, Service Broker solicita un enlace mediante este servicio. Si no hay ningún servicio de configuración del broker en la base de datos o este servicio no proporciona ningún enlace de servicio remoto, la conversación se retrasa si el cifrado está activado o continúa si el cifrado está desactivado. Para obtener más información, vea Determinar el tipo de seguridad de diálogo.

La seguridad de diálogo de Service Broker utiliza certificados para la autorización remota. Cuando un diálogo utiliza la seguridad de diálogo, el primer mensaje enviado por cada participante en la conversación contiene información de encabezado cifrada con la clave privada del usuario que envía el mensaje e información de encabezado cifrada con la clave pública del usuario que lo recibe. El contenido del mensaje se cifra con una clave de sesión. La propia clave de sesión está cifrada y sólo puede recuperarse con la clave privada del usuario que recibe el mensaje.

Si el destinatario del mensaje puede descifrar correctamente el mensaje, significa que el destinatario posee las claves correspondientes y confirma la identidad de cada participante en la conversación. La instalación de un certificado en una base de datos crea una relación de confianza con la base de datos que aloja la clave privada.

De hecho, cuando se cifra un encabezado con la clave privada del usuario local, la pregunta que se plantea es si la base de datos remota confía en la base de datos local. La base de datos remota sólo puede descifrar el encabezado si contiene la clave pública correspondiente. Cuando se cifra un encabezado con la clave pública del usuario de la base de datos remota, la pregunta que se plantea es si la base de datos local confía en la base de datos remota. La base de datos remota sólo puede descifrar el encabezado si contiene la clave privada correspondiente. Para mayor seguridad y eficacia, Service Broker hace estas dos preguntas al mismo tiempo. Sin embargo, el mensaje se estructura de forma que quién recibe el mensaje debe poder contestar afirmativamente a ambas preguntas para responder al mensaje correctamente.

El razonamiento de esta estrategia es sencillo. Si la base de datos remota puede descifrar un encabezado cifrado con una clave privada en la base de datos local, la base de datos remota contiene la clave pública correspondiente y la base de datos remota confía en la base de datos local. Si la base de datos remota puede descifrar un encabezado cifrado con una clave pública en la base de datos local, la base de datos remota contiene la clave privada correspondiente y la base de datos local confía en la base de datos remota. Mientras las claves privadas permanezcan en secreto, sólo las dos bases de datos implicadas en la conversación podrán intercambiar correctamente mensajes de la conversación.

Nota

Instale sólo certificados que provengan de fuentes de confianza. No distribuya claves privadas.

La seguridad de diálogo completa comprueba la identidad en ambas direcciones durante el primer intercambio de mensajes. En el caso de conversaciones que utilizan seguridad de diálogo anónima, el iniciador comprueba que la base de datos de destino contiene la clave privada esperada. Sin embargo, con esta seguridad, la base de datos de destino no comprueba la identidad del iniciador; en su lugar, la base de datos que aloja el servicio de destino debe permitir que la función fija de base de datos public envíe mensajes al servicio.

Los mensajes se deben intercambiar en ambas direcciones antes de que la base de datos local considere que la identidad de la base de datos remota está confirmada. La comprobación sólo se puede producir si la base de datos local contiene la clave pública correcta para el certificado de la base de datos remota.

En el primer mensaje enviado por cada extremo de la conversación, Service Broker incluye los siguientes encabezados:

  • Un encabezado de seguridad del par de servicio que contiene la información de los certificados utilizados en el mensaje. El encabezado de seguridad del par de servicio está firmado con la clave privada del usuario que posee el servicio.

  • Una clave de intercambio de claves que cifra la clave de sesión de 128 bits utilizada para cifrar el cuerpo del mensaje. La clave de intercambio de claves está cifrada con la clave pública del usuario remoto.

En el caso de los diálogos que utilizan la seguridad anónima, el encabezado de seguridad del par de servicio permanece sin cifrar. El propio mensaje sigue estando cifrado y la clave de intercambio de claves está cifrada con la clave pública de la entidad de seguridad de la base de datos de destino. En este caso, el primer mensaje que se devuelve no contiene ninguna clave de intercambio de clase, encabezado de seguridad del par de servicio ni clave de sesión cifrada.

Cuando el propio Service Broker genera un mensaje en respuesta a un mensaje entrante (por ejemplo, un error o un reconocimiento), ese mensaje utiliza la clave de sesión del mensaje entrante independientemente de si el diálogo utiliza seguridad completa o seguridad anónima.