Share via


Recepción de eventos de forma segura

Los consumidores temporales y permanentes tienen diferentes métodos para proteger la entrega de eventos.

En este tema se describen las secciones siguientes:

Protección de consumidores temporales

Los consumidores temporales se ejecutan hasta que se reinicia el sistema o se detiene WMI, pero no se pueden iniciar si se genera un evento específico. Por ejemplo, una llamada a SWbemServices.ExecNotificationQueryAsync crea un consumidor temporal.

Las llamadas a SWbemServices.ExecNotificationQuery o IWbemServices::ExecNotificationQuery crean consumidores de eventos temporales. Los consumidores temporales no pueden controlar quién proporciona eventos al receptor de eventos que crean.

Las llamadas a métodos ExecNotificationQuery se pueden realizar de forma sincrónica, semisincrónica o asincrónica. Por ejemplo, SWbemServices.ExecNotificationQuery es un método sincrónico al que se puede llamar de forma semisincrónica, en función de cómo esté establecido el parámetro iflags. SWbemServices.ExecNotificationQueryAsync es una llamada asincrónica.

Tenga en cuenta que es posible que la devolución de llamadas al receptor para las versiones asincrónicas de estas llamadas no se devuelva en el mismo nivel de autenticación que la llamada que el script ha realizado. Por lo tanto, se recomienda utilizar llamadas semisincrónicas en lugar de asincrónicas. Si necesita comunicación asincrónica, consulte Llamada a un método y Establecimiento de la seguridad en una llamada asincrónica.

Los suscriptores de scripting no pueden comprobar los derechos de acceso de un proveedor de eventos para proporcionar eventos al receptor creado por el script. Por lo tanto, se recomienda que las llamadas a SWbemServices.ExecNotificationQuery usen la forma semisincrónica de la llamada y utilicen una configuración de seguridad específica. Para más información, consulte Realización de una llamada semisincrónica con VBScript.

Protección de consumidores permanentes

Un consumidor permanente tiene una suscripción permanente a eventos de un proveedor de eventos que se conservarán después de reiniciar el sistema operativo. Un proveedor de eventos que admite consumidores permanentes es un proveedor de consumidores de eventos. Si el proveedor de eventos no se ejecuta cuando se produce un evento, WMI inicia el proveedor cuando necesita entregar eventos. WMI identifica a qué proveedor de consumidores se deben entregar los eventos, en función de la instancia __EventConsumerProviderRegistration, que asocia la instancia __Win32Provider del proveedor de consumidores a una clase de consumidores lógicos definida por el proveedor de consumidores. Para más información sobre el rol de los proveedores de consumidores, consulte Escritura de un proveedor de consumidores de eventos.

Los consumidores permanentes pueden controlar quién les envía eventos, y los proveedores de eventos pueden controlar quién accede a sus eventos.

Los scripts y aplicaciones clientes crean instancias de la clase de consumidor lógico como parte de una suscripción. La clase de consumidor lógico define qué información contiene el evento, qué puede hacer el cliente con el evento y cómo se entrega el evento.

Las clases de consumidores estándar de WMI proporcionan ejemplos del rol de las clases de consumidores lógicos. Para más información, consulte Supervisión y respuesta a eventos con consumidores estándar.

Protección de la suscripción permanente

Las suscripciones permanentes tienen mayor potencial para causar problemas de seguridad en WMI y, por lo tanto, tienen los siguientes requisitos de seguridad:

  • La instancia de consumidor lógico, las instancias __EventFilter y __FilterToConsumerBinding deben tener el mismo identificador de seguridad individual (SID) en la propiedad CreatorSID. Para más información, consulte el artículo sobre cómo mantener el mismo SID en todas las instancias de una suscripción permanente.

  • La cuenta que crea la suscripción debe ser una cuenta de dominio con privilegios de administrador local o la cuenta de grupo Administradores local. El uso del SID del grupo Administradores permite que la suscripción siga funcionando en el equipo local, incluso si está desconectada de la red. El uso de una cuenta de dominio permite la identificación exacta del usuario.

    Sin embargo, si el equipo no está conectado y la cuenta de creación es una cuenta de dominio, se produce un error en el consumidor porque WMI no puede comprobar la identidad de la cuenta. Para evitar errores de suscripción si el equipo está desconectado de la red, utilice el SID del grupo Administradores para una suscripción. En este caso, debe asegurarse de que la cuenta LocalSystem pueda acceder a los datos de pertenencia a grupos en el dominio. Algunos proveedores de consumidores de eventos tienen requisitos de seguridad especialmente elevados, ya que una suscripción no autorizada puede provocar grandes daños. Algunos ejemplos son los consumidores estándar, ActiveScriptEventConsumer y CommandLineEventConsumer.

  • Puede configurar la suscripción permanente para que solo acepte eventos de identidades de proveedor de eventos específicas. Establezca el descriptor de seguridad en la propiedad EventAccess de la instancia __EventFilter en las identidades del proveedor de eventos. WMI compara la identidad del proveedor de eventos con el descriptor de seguridad para determinar si el proveedor dispone del acceso WBEM_RIGHT_PUBLISH. Para más información, consulte Constantes de seguridad de WMI.

    Si el filtro permite el acceso a la identidad del proveedor de eventos, entonces también confía en el evento. Esto permite al consumidor que ha recibido el evento generar un evento delegado.

    Nota El valor predeterminado para el descriptor de seguridad en EventAccess es NULL, lo que permite el acceso a todos. Se recomienda limitar el acceso en la instancia de suscripción de __EventFilter para mejorar la seguridad de los eventos.

Configuración de un SD de solo administrador

En el ejemplo de código de C++ siguiente se crea un descriptor de seguridad de solo administrador en la instancia de __EventFilter. En este ejemplo se crea el descriptor de seguridad mediante el lenguaje de definición de descriptores de seguridad (SDDL). Para más información sobre WBEM_RIGHT_SUBSCRIBE, consulte Constantes de seguridad de WMI.

// Create SD that allows only administrators 
//    to send events to this filter. 
// The SDDL settings are O:BAG:BAD:(A;;0x80;;;BA)
// Set the EventAccess property in the 
//    IWbemClassObject of the __EventFilter instance. 
   long lMask = WBEM_RIGHT_PUBLISH;
     WCHAR wBuf[MAX_PATH];
     _ltow( lMask, wBuf, 16 );
 
HRESULT hRes = pEventFilterInstance->Put( L"EventAccess", 0,
    &_variant_t( L"O:BAG:BAD:(A;;0x80;;;BA)" ), NULL );

En el ejemplo código anterior se requiere la siguiente referencia e instrucciones #include.

#define _WIN32_DCOM
#include <wbemidl.h>
#include <comdef.h>

#pragma comment(lib, "wbemuuid.lib")

Suplantación de la identidad del proveedor de eventos

Es posible que un consumidor permanente tenga que suplantar al proveedor de eventos para procesar el evento. Los consumidores permanentes solo pueden suplantar al proveedor de eventos cuando existen las condiciones siguientes:

  • La instancia de __FilterToConsumerBinding tiene la propiedad MaintainSecurityContext establecida en True.
  • Un evento se entrega en el mismo contexto de seguridad en el que estaba el proveedor cuando generó el evento. Solo un consumidor implementado como DLL, un consumidor en proceso, puede recibir eventos en el contexto de seguridad del proveedor. Para más información sobre la seguridad de proveedores y consumidores en proceso, consulte Hospedaje y seguridad del proveedor.
  • El proveedor de eventos se ejecuta en un proceso que permite la suplantación.

La cuenta que ejecuta el proceso de consumidor debe tener acceso FULL_WRITE al repositorio de WMI (también conocido como repositorio de CIM). En la suscripción, las instancias __FilterToConsumerBinding, __EventConsumer y __EventFilter deben tener el mismo valor de identificador de seguridad individual (SID) en la propiedad CreatorSID. WMI almacena el SID en CreatorSID para cada instancia.

SID y suscripciones permanentes

Una suscripción permanente no funciona cuando el enlace, el consumidor y el filtro no han sido creados por el mismo usuario, lo que significa que __FilterToConsumerBinding, __EventConsumer y __EventFilter deben tener el mismo valor de identificador de seguridad individual (SID) en la propiedad CreatorSID. Instrumental de administración de Windows (WMI) almacena este valor.

Creación de suscripciones permanentes mediante cuentas de dominio

Se deben tener en cuenta varios problemas al usar cuentas de dominio para crear suscripciones permanentes. Cada suscripción permanente seguirá funcionando cuando ningún usuario haya iniciado sesión, lo que significa que funciona en la cuenta LocalSystem integrada.

Si un usuario de dominio es el creador de una suscripción permanente para consumidores confidenciales de seguridad (ActiveScriptEventConsumer, CommandLineEventConsumer), WMI comprueba si la propiedad CreatorSID de la clase __EventFilter, la clase __FilterToConsumerBinding y las instancias de consumidor pertenecen a un usuario que sea miembro del grupo Administradores local.

En el ejemplo de código siguiente se muestra cómo puede especificar la propiedad CreatorSID.

 instance of __EventFilter as $FILTER
    {
        // this is the Administrators SID in array of bytes format
        CreatorSID = {1,2,0,0,0,0,0,5,32,0,0,0,32,2,0,0};    
        // Add filter code here ...
    }

    instance of ActiveScriptEventConsumer as $CONSUMER
    {
       CreatorSID = {1,2,0,0,0,0,0,5,32,0,0,0,32,2,0,0};
       // Add consumer code here ...
    }

    instance of __FilterToConsumerBinding
    {
       CreatorSID = {1,2,0,0,0,0,0,5,32,0,0,0,32,2,0,0};
       Consumer = $CONSUMER;
       Filter = $FILTER;
       // Add binding code here ...
    }

Para situaciones entre dominios, agregue Usuarios autenticados al "Grupo de acceso de autorización de Windows".

Protección de eventos de WMI

Recepción de un evento de WMI