Compartilhar via

Receber eventos com segurança

  • Artigo

Consumidores temporários e permanentes têm métodos diferentes para proteger a entrega de eventos.

As seguintes seções serão abordadas neste tópico:

Proteger consumidores temporários

Um consumidor temporário é executado até que o sistema seja reinicializado ou o WMI seja interrompido, mas não poderá ser iniciado se um evento específico for gerado. Por exemplo, uma chamada para SWbemServices.ExecNotificationQueryAsync cria um consumidor temporário.

As chamadas SWbemServices.ExecNotificationQuery ou IWbemServices::ExecNotificationQuery criam consumidores de eventos temporários. Consumidores temporários não podem controlar quem fornece eventos para o coletor de eventos que eles criam.

Chamadas para métodos ExecNotificationQuery podem ser feitas de maneira síncrona, semissíncrona ou assíncrona. Por exemplo, SWbemServices.ExecNotificationQuery é um método síncrono que pode ser chamado de semissíncrono dependendo de como o parâmetro iflags é definido. SWbemServices.ExecNotificationQueryAsync é uma chamada assíncrona.

Lembre-se de que o retorno de chamada para o coletor das versões assíncronas dessas chamadas pode não ser retornado no mesmo nível de autenticação que a chamada feita pelo script. Portanto, é recomendável usar chamadas semissíncronas em vez de assíncronas. Se precisar de comunicação assíncrona, confira Chamar um método e Definir a segurança em uma chamada assíncrona.

Assinantes de script não podem verificar os direitos de acesso de um provedor de eventos para fornecer eventos ao coletor criado pelo script. Portanto, é recomendável que chamadas para SWbemServices.ExecNotificationQuery usem a forma semissíncrona da chamada e usem configurações de segurança específicas. Para saber mais, confira Fazer uma chamada semissíncrona com VBScript.

Proteger consumidores permanentes

Um consumidor permanente tem uma assinatura permanente de eventos de um provedor de eventos que persistirá após a reinicialização do sistema operacional. Um provedor de eventos com suporte para consumidores permanentes é um provedor de consumidores de eventos. Se o provedor de eventos não estiver em execução quando ocorrer um evento, o WMI iniciará o provedor quando precisar entregar eventos. O WMI identifica a qual provedor de consumidores os eventos devem ser entregues com base na instância __EventConsumerProviderRegistration, que associa a instância do provedor de consumidores __Win32Provider a uma classe de consumidor lógico definida pelo provedor de consumidores. Para saber mais sobre a função dos provedores de consumidores, confira Escrever um provedor de consumidores de eventos.

Consumidores permanentes podem controlar quem envia eventos a eles e provedores de eventos podem controlar quem acessa seus eventos.

Scripts e aplicativos cliente criam instâncias da classe de consumidor lógico como parte de uma assinatura. A classe de consumidor lógico define quais informações o evento contém, o que o cliente pode fazer com o evento e como o evento é entregue.

As Classes de Consumidor Padrão do WMI oferecem exemplos da função das classes de consumidor lógico. Para obter mais informações, confira Monitoramento e resposta a eventos com consumidores padrão.

Proteger a assinatura permanente

Assinaturas permanentes têm maior potencial para causar problemas de segurança no WMI e, portanto, têm os seguintes requisitos de segurança:

  • A instância do consumidor lógico, o __EventFilter e as instâncias de __FilterToConsumerBinding precisam ter o mesmo SID (identificador de segurança) individual na propriedade CreatorSID. Para saber mais, confira Manter o mesmo SID em todas as instâncias de uma assinatura permanente.

  • A conta que cria a assinatura precisa ser uma conta de domínio com privilégios de administrador local ou a conta de grupo local Administradores. O uso do SID do grupo Administradores permite que a assinatura continue funcionando no computador local, mesmo que seja desconectada da rede. O uso de uma conta de domínio permite a identificação exata do usuário.

    No entanto, se o computador não estiver conectado e a conta responsável pela criação for uma conta de domínio, o consumidor falhará porque o WMI não poderá verificar a identidade da conta. Para evitar falhas de assinatura se o computador for desconectado da rede, use o SID do grupo Administradores para uma assinatura. Nesse caso, garanta que a conta LocalSystem possa acessar dados de associação de grupo no domínio. Alguns provedores de consumidores de eventos têm requisitos de segurança particularmente altos, uma vez que uma assinatura invasora pode causar muitos danos. São exemplos os consumidores padrão ActiveScriptEventConsumer e CommandLineEventConsumer.

  • Você pode configurar a assinatura permanente para aceitar apenas eventos de identidades específicas do provedor de eventos. Defina o descritor de segurança na propriedade EventAccess da instância __EventFilter para as identidades do provedor de eventos. O WMI compara a identidade do provedor de eventos com o descritor de segurança para determinar se o provedor tem acesso a WBEM_RIGHT_PUBLISH. Para saber mais, confira Constantes de segurança do WMI.

    Se o filtro permitir acesso à identidade do provedor de eventos, ele também confiará no evento. Isso permite que o consumidor que recebeu o evento gere um evento delegado.

    Observação O padrão para o descritor de segurança em EventAccess é NULL, que permite o acesso a todos. A limitação do acesso na instância da assinatura de __EventFilter é recomendada para uma melhor segurança de eventos.

Configurar um SD somente de administrator

O exemplo de código C++ a seguir cria um descritor de segurança somente de administrador na instância de __EventFilter. Este exemplo cria o descritor de segurança usando a SDDL (Security Descriptor Definition Language). Para saber mais sobre WBEM_RIGHT_SUBSCRIBE, confira Constantes de segurança do 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 );

O exemplo de código anterior requer a referência a seguir e instruções #include.

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

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

Representar a identidade do provedor de eventos

Um consumidor permanente pode precisar representar o provedor de eventos para processar o evento. Consumidores permanentes só poderão representar o provedor de eventos quando as seguintes condições existirem:

  • A instância de __FilterToConsumerBinding tem a propriedade MaintainSecurityContext definida como True.
  • Um evento é entregue no mesmo contexto de segurança em que o provedor estava quando gerou o evento. Somente um consumidor implementado como uma DLL, um consumidor em processo, pode receber eventos no contexto de segurança do provedor. Para saber mais sobre a segurança de provedores e consumidores em processo, confira Hospedagem e segurança de provedores.
  • O provedor de eventos está em execução em um processo que permite a representação.

A conta que executa o processo do consumidor precisa ter acesso FULL_WRITE ao repositório do WMI (também conhecido como repositório CIM). Na assinatura, as instâncias de __FilterToConsumerBinding, __EventConsumer e __EventFilter precisam ter o mesmo valor de SID (identificador de segurança) individual na propriedade CreatorSID. O WMI armazena o SID no CreatorSID de cada instância.

SIDs e assinaturas permanentes

Uma assinatura permanente não funciona quando a associação, o consumidor e o filtro não foram criados pelo mesmo usuário, o que significa que __FilterToConsumerBinding, __EventConsumer e __EventFilter precisam ter o mesmo valor de SID (identificador de segurança) individual na propriedade CreatorSID. A WMI (Instrumentação de Gerenciamento do Windows) armazena esse valor.

Criar assinaturas permanentes usando contas de domínio

Vários problemas precisam ser considerados ao usar contas de domínio para criar assinaturas permanentes. Cada assinatura permanente ainda deve funcionar quando nenhum usuário está conectado, o que significa que elas funcionam na conta LocalSystem interna.

Se um usuário de domínio for o criador de uma assinatura permanente para consumidores com segurança sensível (ActiveScriptEventConsumer, CommandLineEventConsumer), o WMI verificará se a propriedade CreatorSID da classe __EventFilter, a classe __FilterToConsumerBinding e as instâncias de consumidor pertencem a um usuário que é membro do grupo Administradores local.

O exemplo de código a seguir mostra como especificar a propriedade 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 situações entre domínios, adicione Usuários Autenticados ao "Grupo de Acesso de Autorização do Windows".

Proteger eventos do WMI

Receber um evento do WMI