Notas de seguridad importantes para el motor de reglas de negocio
En este tema se resumen los problemas de seguridad conocidos de Microsoft BizTalk Server y los pasos que debe seguir para mitigar los riesgos de seguridad.
Entrada de esquema malintencionada que causa un ataque de denegación de servicio
Mientras se imponen hechos, cada regla se comprueba con respecto a todos los objetos que coinciden con los tipos admitidos de una directiva. Suponga que hay una regla en una directiva que utiliza uno de los elementos de un esquema pasado mediante un selector. Si la instancia de este elemento/atributo que coincide con el selector se repite miles de veces, cada una de esas instancias se impone, lo que causa una degradación en el rendimiento y, posiblemente, la posterior denegación de servicio.
Para mitigar este posible problema, necesita validar todas las entradas ambiguas que se pasan mientras se ejecuta una directiva.
El conjunto de reglas no valida objetos antes de imponer los hechos
Cualquier instancia de esquema pasada como un hecho al RuleSet no se valida con el esquema antes de declarar las reglas mediante selectores. Debe validar todas las entradas que se pasen mientras se ejecuta una directiva.
Comportamientos esperados del Compositor de reglas de negocio cuando está activa la seguridad de RuleStore
Puede habilitar la característica de seguridad basada en roles para el almacén de reglas mediante una llamada al método EnableAuthorization de la clase RuleStore . Cuando está activa esta característica de seguridad, los comportamientos esperados del Compositor de reglas de negocio son como se indica a continuación:
El modelo de objetos filtra conjuntos de reglas y vocabularios a los que el usuario no tiene acceso de lectura. Por lo tanto, no aparecen en el Compositor de reglas de negocio.
Si el usuario no tiene acceso de escritura a una directiva o a un vocabulario, cualquier intento de guardar hace que se produzca una excepción.
Tipos de usuario para el administrador de almacén de reglas
El administrador de almacén de reglas cuenta con el privilegio de definir un grupo de autorización para artefactos guardados en el almacén de reglas. Sin embargo, observe las siguientes diferencias entre dos tipos de usuario a los que puede pertenecer el administrador de almacén de reglas:
Cuando el administrador de almacén de reglas es un usuario de Windows, lo que quiere decir que se utiliza la autenticación de Windows para conectarse al almacén de reglas, el administrador de almacén de reglas puede definir un grupo de autorización cuyo usuario sea un grupo de Windows o un usuario de Windows.
Cuando el administrador de almacén de reglas es un usuario de SQL, lo que quiere decir que se utiliza la autenticación de SQL para conectarse al almacén de reglas, el administrador de almacén de reglas no puede definir un grupo de autorización cuyo usuario sea un grupo de Windows, pero sí puede definir uno cuyo usuario sea un usuario de Windows.
El usuario no puede asociar un grupo de autorización con un artefacto sin tener los derechos suficientes
Un creador de artefactos que no es ni un usuario dbo de SQL ni un miembro de RE_ADMIN_USERS, y no cuenta con el permiso MODIFY_DELETE para un artefacto, no puede asociar un nuevo grupo de autorización con el artefacto. El siguiente escenario es un ejemplo de este comportamiento:
El creador del conjunto de reglas no es dbo, no pertenece al grupo RE_ADMIN_USERS y no cuenta con el permiso MODIFY_DELETE después de que se haya creado el conjunto de reglas.
El creador crea un conjunto de reglas.
El miembro del grupo RE_ADMIN_USERS crea la autorización AG1 y da permiso MODIFY_DELETE a User2.
El creador asocia AG1 con el conjunto de reglas.
Se activa la autorización de almacén de reglas.
El miembro del grupo RE_ADMIN_USERS crea la autorización AG2 y da permiso READ_EXECUTE a User2.
El creador asocia AG2 con el conjunto de reglas. Aunque el creador no tiene derechos suficientes para hacerlo, no aparece ningún mensaje de error.
Se produce un error en el intento de lectura del conjunto de reglas por parte de User2.