Freigeben über

Sicherer Empfang von Ereignissen

  • Artikel

Temporäre und permanente Consumer verfügen über unterschiedliche Methoden zum Absichern der Ereigniszustellung.

Dieses Thema umfasst die folgenden Abschnitte:

Schützen temporärer Consumer

Ein temporärer Consumer wird ausgeführt, bis das System neu gestartet oder WMI beendet wird, kann aber nicht gestartet werden, wenn ein bestimmtes Ereignis ausgelöst wird. Beispielsweise erstellt ein Aufruf von SWbemServices.ExecNotificationQueryAsync einen temporären Consumer.

Die Aufrufe SWbemServices.ExecNotificationQuery oder IWbemServices::ExecNotificationQuery erstellen temporäre Ereignisconsumer. Temporäre Consumer können nicht steuern, wer Ereignisse für die von ihnen erstellte Ereignissenke bereitstellt.

Aufrufe von ExecNotificationQuery-Methoden können synchron, halbsynchron oder asynchron erfolgen. SWbemServices.ExecNotificationQuery ist beispielsweise eine synchrone Methode, die je nachdem, wie der iflags-Parameter festgelegt wird, halbsynchron aufgerufen werden kann. SWbemServices.ExecNotificationQueryAsync ist ein asynchroner Aufruf.

Beachten Sie, dass der Rückruf an die Senke für die asynchronen Versionen dieser Aufrufe möglicherweise nicht auf derselben Authentifizierungsebene zurückgegeben wird, auf der der Aufruf des Skripts erfolgt ist. Daher wird empfohlen, halbsynchrone Aufrufe anstelle von asynchronen Aufrufen zu verwenden. Wenn Sie asynchrone Kommunikation benötigen, finden Sie weitere Informationen unter Aufrufen einer Methode und Festlegen der Sicherheit für einen asynchronen Aufruf.

Skriptabonnenten können die Zugriffsrechte eines Ereignisanbieters nicht überprüfen, um Ereignisse für die vom Skript erstellte Senke bereitzustellen. Daher wird für Aufrufe von SWbemServices.ExecNotificationQuery die halbsynchrone Form des Aufrufs sowie die Verwendung bestimmter Sicherheitseinstellungen empfohlen. Weitere Informationen finden Sie unter Erstellen eines halbsynchronen Aufrufs mit VBScript.

Schützen permanenter Consumer

Ein permanenter Consumer verfügt über ein permanentes Abonnement für Ereignisse von einem Ereignisanbieter, und wird auch nach dem Neustart des Betriebssystems beibehalten. Ein Ereignisanbieter, der permanente Consumer unterstützt, ist ein Ereignisconsumeranbieter. Wenn der Ereignisanbieter nicht ausgeführt wird, wenn ein Ereignis auftritt, startet WMI den Anbieter, wenn Ereignisse übermittelt werden müssen. WMI identifiziert anhand der __EventConsumerProviderRegistration-Instanz, an welchen Consumeranbieter die Ereignisse übermittelt werden sollen, wobei die __Win32Provider-Instanz des Consumeranbieters einer vom Consumeranbieter definierten logischen Consumerklasse zugeordnet wird. Weitere Informationen zur Rolle von Consumeranbietern finden Sie unter Schreiben eines Ereignisconsumeranbieters.

Permanente Consumer können steuern, wer ihnen Ereignisse sendet, und Ereignisanbieter können steuern, wer auf ihre Ereignisse zugreift.

Clientskripts und -anwendungen erstellen Instanzen der logischen Consumerklasse als Teil eines Abonnements. Die logische Consumerklasse definiert, welche Informationen das Ereignis enthält, was der Client mit dem Ereignis tun kann und wie das Ereignis übermittelt wird.

Die WMI-Standardconsumerklassen enthalten Beispiele für die Rolle logischer Consumerklassen. Weitere Informationen finden Sie unter Überwachen von und Reagieren auf Ereignisse mit Standardconsumern.

Schützen des permanenten Abonnements

Permanente Abonnements haben ein größeres Potenzial, Sicherheitsprobleme im WMI zu verursachen, und unterliegen daher den folgenden Sicherheitsanforderungen:

  • Die logische Consumerinstanz, die __EventFilter-Instanz und die __FilterToConsumerBinding-Instanz müssen dieselbe individuelle Sicherheits-ID (SID) in der CreatorSID-Eigenschaft aufweisen. Weitere Informationen finden Sie unter Beibehalten derselben SID in allen Instanzen eines permanenten Abonnements.

  • Bei dem vom Abonnement erstellten Konto muss es sich entweder um ein Domänenkonto mit lokalen Administratorrechten oder um das Konto der lokalen Administratorengruppe handeln. Mithilfe der SID der Gruppe „Administratoren“ kann das Abonnement weiterhin auf dem lokalen Computer verwendet werden, auch wenn die Verbindung mit dem Netzwerk getrennt ist. Die Verwendung eines Domänenkontos ermöglicht die genaue Identifizierung des Benutzers.

    Wenn der Computer jedoch nicht verbunden ist und das erstellende Konto ein Domänenkonto ist, schlägt der Consumer fehl, da WMI die Identität des Kontos nicht überprüfen kann. Um zu vermeiden, dass Abonnementfehler auftreten, wenn der Computer vom Netzwerk getrennt ist, verwenden Sie die SID der Gruppe „Administratoren“ für ein Abonnement. In diesem Fall sollten Sie sicherstellen, dass das LocalSystem-Konto auf Gruppenmitgliedschaftsdaten in der Domäne zugreifen kann. Einige Ereignisverbraucheranbieter haben besonders hohe Sicherheitsanforderungen, da ein nicht autorisiertes Abonnement großen Schaden anrichten kann. Beispiele hierfür sind die Standardconsumer ActiveScriptEventConsumer und CommandLineEventConsumer.

  • Sie können das permanente Abonnement so konfigurieren, dass nur Ereignisse von bestimmten Ereignisanbieteridentitäten akzeptiert werden. Legen Sie die Sicherheitsbeschreibung in der Eigenschaft EventAccess der __EventFilter-Instanz auf die Ereignisanbieteridentitäten fest. WMI vergleicht die Identität des Ereignisanbieters mit der m Sicherheitsbeschreibung, um zu bestimmen, ob der Anbieter über WBEM_RIGHT_PUBLISH-Zugriff verfügt. Weitere Informationen finden Sie unter WMI-Sicherheitskonstanten.

    Wenn der Filter den Zugriff auf die Ereignisanbieteridentität zulässt, vertraut er auch dem Ereignis. Dadurch kann der Consumer, der das Ereignis empfangen hat, ein delegiertes Ereignis auslösen.

    Hinweis Der Standardwert für die Sicherheitsbeschreibung in EventAccess ist NULL, wodurch jedem Zugriff gewährt wird. Zum Verbessern der Ereignissicherheit wird empfohlen, den Zugriff in der Abonnementinstanz von __EventFilter einzuschränken.

Festlegen einer Sicherheitsbeschreibung nur für Administratoren

Im folgenden C++-Codebeispiel wird eine Sicherheitsbeschreibung für __EventFilter-Instanz erstellt, die nur für Administratoren gilt. In diesem Beispiel wird die Sicherheitsbeschreibung mithilfe von Security Descriptor Definition Language ADDL) erstellt. Weitere Informationen zu WBEM_RIGHT_SUBSCRIBE finden Sie unter WMI-Sicherheitskonstanten.

// 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 );

Im vorherigen Codebeispiel sind die folgenden Verweise und #include-Anweisungen erforderlich.

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

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

Identitätswechsel der Ereignisanbieteridentität

Ein permanenter Consumer muss möglicherweise die Identität des Ereignisanbieters annehmen, um das Ereignis zu verarbeiten. Permanente Consumer können die Identität des Ereignisanbieters nur unter den folgenden Bedingungen annehmen:

  • Die Eigenschaft MaintainSecurityContext ist für die __FilterToConsumerBinding-Instanz auf True festgelegt.
  • Ein Ereignisse wird im gleichen Sicherheitskontext übermittelt, in dem sich der Anbieter beim Generieren des Ereignisses befand. Nur ein als DLL implementierter Consumer (ein In-Process-Consumer) kann Ereignisse im Sicherheitskontext des Anbieters empfangen. Weitere Informationen zur Sicherheit von In-Process-Anbietern und -Consumern finden Sie unter Anbieterhosting und Sicherheit.
  • Der Ereignisanbieter wird in einem Prozess ausgeführt, der einen Identitätswechsel zulässt.

Das Konto, unter dem der Consumerprozess ausgeführt wird, muss über FULL_WRITE-Zugriff auf das WMI-Repository (auch als CIM-Repository bezeichnet) verfügen. Im Abonnement müssen die Instanzen __FilterToConsumerBinding, __EventConsumer und __EventFilter denselben Wert für die individuelle Sicherheits-ID (SID) in der Eigenschaft CreatorSID aufweisen. WMI speichert die SID in der CreatorSID-Eigenschaft jeder Instanz.

SIDs und permanente Abonnements

Ein permanentes Abonnement funktioniert nicht, wenn die Bindung, der Consumer und der Filter nicht vom gleichen Benutzer erstellt werden. Dies bedeutet, dass __FilterToConsumerBinding, __EventConsumer und __EventFilter denselben Wert für die individuelle Sicherheits-ID (SID) in der Eigenschaft CreatorSID aufweisen müssen. Die Windows-Verwaltungsinstrumentation (WMI) speichert diesen Wert.

Erstellen permanenter Abonnements mithilfe von Domänenkonten

Bei der Verwendung von Domänenkonten zum Erstellen permanenter Abonnements müssen mehrere Punkte berücksichtigt werden. Jedes permanente Abonnement sollte auch dann weiterhin funktionieren, wenn kein Benutzer angemeldet ist, d. h. es wird unter dem integrierten LocalSystem-Konto verwendet.

Wenn ein Domänenbenutzer der Ersteller eines permanenten Abonnements für sicherheitsrelevante Consumer (ActiveScriptEventConsumer, CommandLineEventConsumer) ist, überprüft WMI, ob die CreatorSID-Eigenschaft der __EventFilter-Klasse, der __FilterToConsumerBinding-Klasse und der Consumerinstanzen zu einem Benutzer gehören, der Mitglied der lokalen Administratorgruppe ist.

Das folgende Codebeispiel zeigt, wie Sie die CreatorSID-Eigenschaft angeben können.

 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 ...
    }

Fügen Sie in domänenübergreifenden Szenarien authentifizierte Benutzer zur „Windows-Autorisierungszugriffsgruppe“ hinzu.

Schützen von WMI-Ereignissen

Empfangen eines WMI-Ereignisses