Ricezione di eventi in modo sicuro

I consumatori temporanei e permanenti hanno diversi metodi per proteggere la distribuzione degli eventi.

Le sezioni seguenti sono illustrate in questo argomento:

Protezione dei consumer temporanei

Un consumer temporaneo viene eseguito fino a quando il sistema non viene riavviato o WMI viene arrestato, ma non può essere avviato se viene generato un evento specifico. Ad esempio, una chiamata a SWbemServices.ExecNotificationQueryAsync crea un consumer temporaneo.

Le chiamate SWbemServices.ExecNotificationQuery o IWbemServices::ExecNotificationQuery creano consumer di eventi temporanei. I consumer temporanei non possono controllare chi fornisce eventi al sink di eventi creato.

Le chiamate ai metodi ExecNotificationQuery possono essere effettuate in modo sincrono, semisynchrono o asincrono. Ad esempio, SWbemServices.ExecNotificationQuery è un metodo sincrono che può essere chiamato semisynchronously, a seconda della modalità di impostazione del parametro iflags . SWbemServices.ExecNotificationQueryAsync è una chiamata asincrona.

Tenere presente che il callback nel sink per le versioni asincrone di queste chiamate potrebbe non essere restituito allo stesso livello di autenticazione della chiamata effettuata dallo script. È pertanto consigliabile usare chiamate semisynchrono anziché chiamate asincrone. Se è necessaria la comunicazione asincrona, vedere Chiamata di un metodo e impostazione della sicurezza in una chiamata asincrona.

I sottoscrittori di script non possono controllare i diritti di accesso di un provider di eventi per fornire eventi al sink creato dallo script. È pertanto consigliabile che le chiamate a SWbemServices.ExecNotificationQuery usino la forma semisynchronous della chiamata e usino impostazioni di sicurezza specifiche. Per altre informazioni, vedere Creazione di una chiamata Semisynchronous con VBScript.

Protezione dei consumer permanenti

Un consumer permanente ha una sottoscrizione permanente agli eventi di un provider di eventi che persiste dopo il riavvio del sistema operativo. Un provider di eventi che supporta consumer permanenti è un provider consumer di eventi. Se il provider di eventi non è in esecuzione quando si verifica un evento, WMI avvia il provider quando deve recapitare eventi. WMI identifica il provider di consumer a cui devono essere recapitati gli eventi, in base all'istanza __EventConsumerProviderRegistration , che associa l'istanza del provider consumer __Win32Provider a una classe consumer logica definita dal provider consumer. Per altre informazioni sul ruolo dei provider di consumer, vedere Scrittura di un provider consumer di eventi.

I consumer permanenti possono controllare chi li invia eventi e provider di eventi possono controllare chi accede agli eventi.

Gli script client e le applicazioni creano istanze della classe consumer logica come parte di una sottoscrizione. La classe consumer logica definisce le informazioni contenute dall'evento, le operazioni che il client può eseguire con l'evento e il modo in cui viene recapitato l'evento.

Le classi consumer standard WMI forniscono esempi del ruolo delle classi consumer logiche. Per altre informazioni, vedere Monitoraggio e risposta agli eventi con consumer standard.

Protezione della sottoscrizione permanente

Le sottoscrizioni permanenti hanno un maggiore potenziale per causare problemi di sicurezza in WMI e pertanto hanno i requisiti di sicurezza seguenti:

  • L'istanza del consumer logico, la __EventFilter e le istanze di __FilterToConsumerBinding devono avere lo stesso identificatore di sicurezza (SID) nella proprietà CreatorSID . Per altre informazioni, vedere Mantenere lo stesso SID in tutte le istanze di una sottoscrizione permanente.

  • L'account che crea la sottoscrizione deve essere un account di dominio con privilegi di amministratore locale o l'account del gruppo Administrators locale. L'uso del SID del gruppo Administrators consente alla sottoscrizione di continuare a funzionare nel computer locale, anche se è disconnesso dalla rete. L'uso di un account di dominio consente l'identificazione esatta dell'utente.

    Tuttavia, se il computer non è connesso e l'account di creazione è un account di dominio, il consumer non riesce perché WMI non può verificare l'identità dell'account. Per evitare errori di sottoscrizione se il computer viene disconnesso dalla rete, usare il SID del gruppo Administrators per una sottoscrizione. In questo caso, è necessario assicurarsi che l'account LocalSystem possa accedere ai dati di appartenenza ai gruppi nel dominio. Alcuni provider di consumer di eventi hanno requisiti di sicurezza particolarmente elevati, poiché una sottoscrizione non autorizzata può causare danni gravi. Esempi sono i consumer standard, ActiveScriptEventConsumer e CommandLineEventConsumer.

  • È possibile configurare la sottoscrizione permanente per accettare solo gli eventi provenienti da identità del provider di eventi specifiche. Impostare il descrittore di sicurezza nella proprietà EventAccess dell'istanza di __EventFilter sulle identità del provider di eventi. WMI confronta l'identità del provider di eventi al descrittore di sicurezza per determinare se il provider ha WBEM_RIGHT_PUBLISH accesso. Per altre informazioni, vedere Costanti di sicurezza WMI.

    Se il filtro consente l'accesso all'identità del provider di eventi, considera attendibile anche l'evento. Ciò consente al consumer che ha ricevuto l'evento di generare un evento delegato.

    Nota Il valore predefinito per il descrittore di sicurezza in EventAccess è NULL, che consente l'accesso a tutti. È consigliabile limitare l'accesso nell'istanza della sottoscrizione di __EventFilter per migliorare la sicurezza degli eventi.

Impostazione di un Administrator-Only SD

Nell'esempio di codice C++ seguente viene creato un descrittore di sicurezza solo amministratore nell'istanza di __EventFilter . In questo esempio viene creato il descrittore di sicurezza usando Security Descriptor Definition Language (SDDL). Per altre informazioni su WBEM_RIGHT_SUBSCRIBE, vedere Costanti di sicurezza 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 );

L'esempio di codice precedente richiede le istruzioni di riferimento e #include seguenti.

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

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

Rappresentazione dell'identità del provider di eventi

Un consumer permanente potrebbe dover rappresentare il provider di eventi per elaborare l'evento. I consumer permanenti possono rappresentare solo il provider di eventi quando esistono le condizioni seguenti:

  • L'istanza di __FilterToConsumerBinding ha la proprietà MaintainSecurityContext impostata su True.
  • Un evento viene recapitato nello stesso contesto di sicurezza in cui si trovava il provider quando ha generato l'evento. Solo un consumer implementato come DLL, un consumer in-process, può ricevere eventi nel contesto di sicurezza del provider. Per altre informazioni sulla sicurezza di provider e consumer in-process, vedere Hosting e sicurezza del provider.
  • Il provider di eventi è in esecuzione in un processo che consente la rappresentazione.

L'account che esegue il processo consumer deve avere FULL_WRITE accesso al repository WMI (noto anche come repository CIM). Nella sottoscrizione, i __FilterToConsumerBinding, i __EventConsumer e le istanze di __EventFilter devono avere lo stesso valore siD (Individual Security Identifier) nella proprietà CreatorSID . WMI archivia il SID in CreatorSID per ogni istanza.

SID e sottoscrizioni permanenti

Una sottoscrizione permanente non funziona quando l'associazione, il consumer e il filtro non vengono creati dallo stesso utente, il che significa che il __FilterToConsumerBinding, __EventConsumer e __EventFilter deve avere lo stesso valore di identificatore di sicurezza (SID) nella proprietà CreatorSID. Strumentazione gestione Windows archivia questo valore.

Creazione di sottoscrizioni permanenti tramite account di dominio

È necessario considerare diversi problemi quando si usano gli account di dominio per creare sottoscrizioni permanenti. Ogni sottoscrizione permanente deve comunque funzionare quando nessun utente è connesso, il che significa che funzionano con l'account LocalSystem predefinito.

Se un utente di dominio è l'autore di una sottoscrizione permanente per i consumer sensibili alla sicurezza (ActiveScriptEventConsumer, CommandLineEventConsumer), WMI verifica se la proprietà CreatorSID della classe __EventFilter, la classe __FilterToConsumerBinding e le istanze del consumer appartengono a un utente membro del gruppo Administrators locale.

Nell'esempio di codice seguente viene illustrato come specificare la proprietà 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 ...
    }

Per situazioni tra domini, aggiungere utenti autenticati al "Gruppo di accesso all'autorizzazione di Windows".

Protezione degli eventi WMI

Ricezione di un evento WMI