Share via

Réception d’événements en toute sécurité

  • Article

Les consommateurs temporaires et permanents ont différentes méthodes de sécurisation de la livraison des événements.

Les sections suivantes sont abordées dans cette rubrique :

Sécurisation des consommateurs temporaires

Un consommateur temporaire s’exécute jusqu’à ce que le système soit redémarré ou que WMI soit arrêté, mais il ne peut pas être démarré si un événement spécifique est déclenché. Par exemple, un appel à SWbemServices.ExecNotificationQueryAsync crée un consommateur temporaire.

Les appels SWbemServices.ExecNotificationQuery ou IWbemServices::ExecNotificationQuery créent des consommateurs d’événements temporaires. Les consommateurs temporaires ne peuvent pas contrôler qui fournit des événements au récepteur d’événements qu’ils créent.

Les appels aux méthodes ExecNotificationQuery peuvent être effectués de manière synchrone, semi-synchrone ou asynchrone. Par exemple, SWbemServices.ExecNotificationQuery est une méthode synchrone qui peut être appelée semi-synchrone, selon la façon dont le paramètre iflags est défini. SWbemServices.ExecNotificationQueryAsync est un appel asynchrone.

N’oubliez pas que le rappel au récepteur pour les versions asynchrones de ces appels peut ne pas être retourné au même niveau d’authentification que l’appel effectué par le script. Par conséquent, il est recommandé d’utiliser des appels semi-synchrones au lieu d’appels asynchrones. Si vous avez besoin d’une communication asynchrone, consultez Appel d’une méthode et Définition de la sécurité sur un appel asynchrone.

Les abonnés aux scripts ne peuvent pas vérifier les droits d’accès d’un fournisseur d’événements pour fournir des événements au récepteur créé par le script. Par conséquent, il est recommandé que les appels à SWbemServices.ExecNotificationQuery utilisent la forme semi-synchrone de l’appel et utilisent des paramètres de sécurité spécifiques. Pour plus d’informations, consultez Effectuer un appel semi-synchrone avec VBScript.

Sécurisation des consommateurs permanents

Un consommateur permanent dispose d’un abonnement permanent aux événements d’un fournisseur d’événements qui persisteront après le redémarrage du système d’exploitation. Un fournisseur d’événements qui prend en charge les consommateurs permanents est un fournisseur de consommateurs d’événements. Si le fournisseur d’événements n’est pas en cours d’exécution lorsqu’un événement se produit, WMI démarre le fournisseur lorsqu’il doit remettre des événements. WMI identifie le fournisseur de consommateurs auquel les événements doivent être remis, en fonction de la __EventConsumerProviderRegistration instance, qui associe le fournisseur de consommateurs __Win32Provider instance à une classe de consommateurs logique définie par un fournisseur de consommateurs. Pour plus d’informations sur le rôle des fournisseurs de consommateurs, consultez Écriture d’un fournisseur de consommateurs d’événements.

Les consommateurs permanents peuvent contrôler qui leur envoie des événements et les fournisseurs d’événements peuvent contrôler qui accède à leurs événements.

Les scripts et applications clients créent des instances de la classe de consommateur logique dans le cadre d’un abonnement. La classe de consommateur logique définit les informations que contient l’événement, ce que le client peut faire avec l’événement et comment l’événement est remis.

Les classes de consommateurs standard WMI fournissent des exemples du rôle des classes de consommateurs logiques. Pour plus d’informations, consultez Monitoring des événements et réponse à ces derniers avec des consommateurs standard.

Sécurisation de l’abonnement permanent

Les abonnements permanents ont un plus grand risque de provoquer des problèmes de sécurité dans WMI et ont donc les exigences de sécurité suivantes :

  • L’instance consommateur logique et les instances __EventFilter et __FilterToConsumerBinding doivent avoir le même identificateur de sécurité individuel (SID) dans la propriété CreatorSID. Pour plus d’informations, consultez Conserver le même SID dans toutes les instances d’un abonnement permanent.

  • Le compte qui crée l’abonnement doit être un compte de domaine avec des privilèges d’administrateur local ou le compte de groupe Administrateurs local. L’utilisation du SID du groupe Administrateurs permet à l’abonnement de continuer à travailler sur l’ordinateur local, même s’il est déconnecté du réseau. L’utilisation d’un compte de domaine permet d’identifier exactement l’utilisateur.

    Toutefois, si l’ordinateur n’est pas connecté et que le compte de création est un compte de domaine, le consommateur échoue, car WMI ne peut pas vérifier l’identité du compte. Pour éviter l’échec de l’abonnement si l’ordinateur est déconnecté du réseau, utilisez le SID du groupe Administrateurs pour un abonnement. Dans ce cas, vous devez vous assurer que le compte LocalSystem peut accéder aux données d’appartenance au groupe sur le domaine. Certains fournisseurs de consommateurs d’événements ont des exigences de sécurité particulièrement élevées, car un abonnement non autorisé peut causer de grands dommages. Par exemple, les consommateurs standard, ActiveScriptEventConsumer et CommandLineEventConsumer.

  • Vous pouvez configurer l’abonnement permanent pour accepter uniquement les événements provenant d’identités de fournisseur d’événements spécifiques. Définissez le descripteur de sécurité dans la propriété EventAccess de l’instance __EventFilter sur les identités de fournisseur d’événements. WMI compare l’identité du fournisseur d’événements au descripteur de sécurité pour déterminer si le fournisseur dispose d’un accès à WBEM_RIGHT_PUBLISH. Pour plus d’informations, consultez Constantes de sécurité WMI.

    Si le filtre autorise l’accès à l’identité du fournisseur d’événements, il approuve également l’événement. Cela permet au consommateur qui a reçu l’événement de déclencher un événement délégué.

    Note La valeur par défaut du descripteur de sécurité dans EventAccess est NULL, ce qui autorise l’accès à tout le monde. La limitation de l’accès dans l’instance d’abonnement de __EventFilter est recommandée pour une meilleure sécurité des événements.

Définition d’un SD réservé à l’administrateur

L’exemple de code C++ suivant crée un descripteur de sécurité réservé à l’administrateur sur l’instance __EventFilter. Cet exemple crée le descripteur de sécurité à l’aide du langage Security Descriptor Definition Language(SDDL). Pour plus d’informations sur WBEM_RIGHT_SUBSCRIBE, consultez Constantes de sécurité 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’exemple de code précédent nécessite les instructions de référence et de #include suivantes.

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

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

Emprunt d’identité du fournisseur d’événements

Un consommateur permanent peut avoir besoin d’emprunter l’identité du fournisseur d’événements pour traiter l’événement. Les consommateurs permanents peuvent emprunter l’identité du fournisseur d’événements uniquement lorsque les conditions suivantes existent :

  • L’instance de __FilterToConsumerBinding a la propriété MaintainSecurityContext définie sur True.
  • Un événement est remis dans le même contexte de sécurité que celui dans lequel se trouvait le fournisseur lorsqu’il a généré l’événement. Seul un consommateur implémenté en tant que DLL, un consommateur dans le processus, peut recevoir des événements dans le contexte de sécurité du fournisseur. Pour plus d’informations sur la sécurité des fournisseurs et des consommateurs dans le processus, consultez Hébergement et sécurité du fournisseur.
  • Le fournisseur d’événements s’exécute dans un processus qui autorise l’emprunt d’identité.

Le compte exécutant le processus consommateur doit avoir un accès FULL_WRITE au référentiel WMI (également appelé référentiel CIM). Dans l’abonnement, les instances __FilterToConsumerBinding, __EventConsumer et __EventFilter doivent avoir la même valeur d’identificateur de sécurité individuel (SID) dans la propriété CreatorSID. WMI stocke le SID dans le CreatorSID pour chaque instance.

SID et abonnements permanents

Un abonnement permanent ne fonctionne pas lorsque la liaison, le consommateur et le filtre ne sont pas créés par le même utilisateur, ce qui signifie que le __FilterToConsumerBinding, le __EventConsumer et le __EventFilter doivent avoir la même valeur d’identificateur de sécurité individuel (SID) dans la propriété CreatorSID. Windows Management Instrumentation (WMI) stocke cette valeur.

Création d’abonnements permanents à l’aide de comptes de domaine

Plusieurs problèmes doivent être pris en compte lors de l’utilisation de comptes de domaine pour créer des abonnements permanents. Chaque abonnement permanent doit continuer à fonctionner lorsqu’aucun utilisateur n’est connecté, ce qui signifie qu’il fonctionne sous le compte LocalSystem intégré.

Si un utilisateur de domaine est le créateur d’un abonnement permanent pour les consommateurs sensibles à la sécurité (ActiveScriptEventConsumer, CommandLineEventConsumer), WMI vérifie si la propriété CreatorSID de la classe __EventFilter, la classe __FilterToConsumerBinding et les instances de consommateur appartiennent à un utilisateur membre du groupe Administrateurs local.

L’exemple de code suivant montre comment spécifier la propriété 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 ...
    }

Pour les situations inter-domaines, ajoutez Utilisateurs authentifiés au « Groupe d’accès d’autorisation Windows ».

Sécurisation des événements WMI

Réception d’un événement WMI