Ricezione sicura di eventi
I consumatori temporanei e permanenti hanno diverse modalità per garantire il recapito degli eventi.
Le sezioni seguenti sono descritte in questo argomento:
- Sicurezza dei consumatori temporanei
- Assicurare i consumatori permanenti
- Sicurezza dell'abbonamento permanente
- Impostazione di un Administrator-Only SD
- Impersonificazione dell'identità del provider di eventi
- SID e sottoscrizioni permanenti
- creazione di sottoscrizioni permanenti tramite account di dominio
- argomenti correlati
Protezione dei consumatori temporanei
Un consumer temporaneo viene eseguito finché 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 dei consumer di eventi temporanei. I consumatori temporanei non possono controllare chi fornisce eventi al sink che creano.
Le chiamate a metodi ExecNotificationQuery possono essere effettuate in modo sincrono, semiincronamenteo in modo asincrono. Ad esempio, SWbemServices.ExecNotificationQuery è un metodo sincrono che può essere chiamato in modo semisincrono, a seconda di come è impostato il parametro iflags . SWbemServices.ExecNotificationQueryAsync è una chiamata asincrona.
Tenere presente che il richiamo al sink per le versioni asincrone di queste chiamate potrebbe non avvenire allo stesso livello di autenticazione della chiamata eseguita dallo script. È pertanto consigliabile usare chiamate semiincrone anziché asincrone. Se è necessaria la comunicazione asincrona, vedere Chiamata di un metodo e Impostazione della sicurezza in una chiamata asincrona.
I sottoscrittori di scripting non possono controllare i diritti di accesso di un provider di eventi per fornire eventi al sink creato dallo script. È pertanto consigliabile effettuare chiamate a SWbemServices.ExecNotificationQuery utilizzando la forma semisincrona della chiamata e usando impostazioni di sicurezza specifiche. Per altre informazioni, vedere Creazione di una chiamata semisincrona con VBScript.
Acquisizione di Consumatori Permanenti
Un consumer permanente ha una sottoscrizione permanente agli eventi di un provider di eventi che verrà mantenuta dopo il riavvio del sistema operativo. Un provider di eventi che supporta consumatori permanenti è un fornitore di consumatori di eventi . Se il provider di eventi non è in esecuzione quando si verifica un evento, WMI avvia il provider quando deve recapitare gli eventi. WMI identifica quale provider di consumer debbano essere recapitati gli eventi, in base all'istanza __EventConsumerProviderRegistration, che associa l'istanza del provider di consumer __Win32Provider a una classe consumer logica definita dal provider di consumer. Per ulteriori informazioni sul ruolo dei fornitori di servizi per i consumatori, vedere Scrittura di un fornitore di servizi per eventi.
I consumer permanenti possono controllare chi li invia eventi e i provider di eventi possono controllare chi accede ai propri eventi.
Gli script client e le applicazioni creano istanze della classe consumer logica come parte di un abbonamento. 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 standard di consumo WMI forniscono esempi del ruolo delle classi logiche di consumo. Per altre informazioni, vedere Monitoraggio e risposta agli eventi con consumatori standard.
Protezione della sottoscrizione permanente
Le sottoscrizioni permanenti possono causare problemi di sicurezza in WMI e pertanto hanno i requisiti di sicurezza seguenti:
L'istanza del consumer logico, l'__EventFiltere l'istanza __FilterToConsumerBinding devono avere lo stesso identificatore di sicurezza individuale (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 lavorare 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 che sta creando è un account di dominio, il processo fallisce perché WMI non è in grado di verificare l'identità dell'account. Per evitare errori di sottoscrizione se il computer è 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 fornitori di servizi di consumo di eventi hanno requisiti di sicurezza particolarmente elevati, poiché un abbonamento fraudolento può causare gravi danni. Esempi sono i consumer standard, ActiveScriptEventConsumer e CommandLineEventConsumer.
È possibile configurare la sottoscrizione permanente in modo da accettare solo eventi da identità specifiche del provider di eventi. Impostare il descrittore di sicurezza nella proprietà EventAccess dell'istanza di __EventFilter alle identità dei provider di eventi. WMI confronta l'identità del provider di eventi con il 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 una migliore sicurezza degli eventi.
Impostazione di un SD Administrator-Only
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 utilizzando il linguaggio di definizione del descrittore di sicurezza (SDDL). Per altre informazioni su WBEM_RIGHT_SUBSCRIBE, consultare 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 il riferimento e le istruzioni #include seguenti.
#define _WIN32_DCOM
#include <wbemidl.h>
#include <comdef.h>
#pragma comment(lib, "wbemuuid.lib")
Falsificazione dell'identità del fornitore di eventi
Un consumatore permanente potrebbe dover impersonare 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 Provider Hosting and Security.
- Il provider di eventi è in esecuzione in un processo che consente l'impersonificazione.
L'account che esegue il processo consumer deve avere accesso FULL_WRITE al repository WMI (noto anche come repository CIM). Nella sottoscrizione, le istanze di __FilterToConsumerBinding, __EventConsumere __EventFilter devono avere lo stesso valore di identificatore di sicurezza (SID) nella proprietà CreatorSID. WMI archivia il SID nel 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 __FilterToConsumerBinding, __EventConsumere __EventFilter devono avere lo stesso valore dell'identificatore di sicurezza (SID) nella proprietà CreatorSID. Strumentazione gestione Windows archivia questo valore.
Creazione di sottoscrizioni permanenti tramite account di dominio
Quando si usano account di dominio per creare sottoscrizioni permanenti, è necessario considerare diversi problemi. 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, __FilterToConsumerBinding classe 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 le situazioni tra domini, aggiungere utenti autenticati al "gruppo di accesso autorizzazioni di Windows".
Argomenti correlati