Partager via

Considérations de sécurité pour les demandeurs

  • Article

L’infrastructure VSS nécessite que les demandeurs VSS, tels que les applications de sauvegarde, puissent fonctionner à la fois comme clients COM et comme serveur.

Lorsqu’il agit en tant que serveur, un demandeur expose un ensemble d’interfaces de rappel COM qui peuvent être invoquées à partir de processus externes (tels que les writers ou le service VSS). Par conséquent, les demandeurs doivent gérer de manière sécurisée quels clients COM sont capables de passer des appels COM entrants dans son processus.

De même, les demandeurs peuvent agir en tant que client COM pour les API COM fournies par un writer VSS ou par le service VSS. Les paramètres de sécurité spécifiques aux demandeurs doivent permettre les appels COM sortants du demandeur vers ces autres processus.

Le mécanisme le plus simple pour gérer les problèmes de sécurité d’un demandeur implique une sélection appropriée du compte utilisateur sous lequel il s’exécute.

Un demandeur doit généralement s’exécuter sous un utilisateur membre soit du groupe Administrateurs, soit du groupe Opérateurs de sauvegarde, ou s’exécuter en tant que compte Système local.

Par défaut, lorsqu’un demandeur agit en tant que client COM, s’il ne s’exécute pas sous ces comptes, tout appel COM est automatiquement rejeté avec E_ACCESSDENIED, sans même atteindre l’implémentation de la méthode COM.

Désactivation de la gestion des exceptions COM

Lors du développement d’un demandeur, définissez l’indicateur d’options globales COM COMGLB_EXCEPTION_DONOT_HANDLE pour désactiver la gestion des exceptions COM. Il est important de faire cela car la gestion des exceptions COM peut masquer des erreurs fatales dans une application VSS. L’erreur masquée peut laisser le processus dans un état instable et imprévisible, ce qui peut entraîner des corruptions et des blocages. Pour plus d’informations sur cet indicateur, veuillez consulter la section IGlobalOptions.

Définition de l’autorisation de vérification d’accès COM par défaut pour les demandeurs

Les demandeurs doivent être conscients que lorsque leur processus agit en tant que serveur (par exemple, permettant aux writers de modifier le document des composants de sauvegarde), ils doivent autoriser les appels entrants d’autres participants VSS, tels que les writers ou le service VSS.

Cependant, par défaut, un processus Windows n’autorisera que les clients COM s’exécutant sous la même session de connexion (le SID SELF) ou s’exécutant sous le compte Système local. Il s’agit d’un problème potentiel car ces paramètres par défaut ne sont pas adéquats pour l’infrastructure VSS. Par exemple, les writers peuvent s’exécuter sous un compte utilisateur « Opérateur de sauvegarde » qui n’est ni dans la même session de connexion que le processus demandeur ni un compte Système local.

Pour gérer ce type de problème, chaque processus serveur COM peut exercer un contrôle supplémentaire sur la question de savoir si un client RPC ou COM est autorisé à exécuter une méthode COM implémentée par le serveur (un demandeur dans ce cas) en utilisant CoInitializeSecurity pour définir une "Autorisation de vérification d’accès COM par défaut" à l’échelle du processus.

Les demandeurs peuvent explicitement faire ce qui suit :

  • Autoriser tous les processus à accéder au processus demandeur.

    Cette option peut être adéquate pour la grande majorité des demandeurs, et est utilisée par d’autres serveurs COM. Par exemple, tous les services Windows basés sur SVCHOST utilisent déjà cette option, tout comme les services COM+ par défaut.

    Autoriser tous les processus à effectuer des appels COM entrants n’est pas nécessairement une faiblesse de sécurité. Un demandeur agissant en tant que serveur COM, comme tous les autres serveurs COM, conserve toujours l’option d’autoriser ses clients pour chaque méthode COM implémentée dans son processus.

    Notez que les rappels COM internes implémentés par VSS sont sécurisés par défaut.

    Pour autoriser tous les processus à accéder au demandeur par COM, vous pouvez passer un descripteur de sécurité NULL comme premier paramètre de CoInitializeSecurity. (Notez que CoInitializeSecurity ne doit être appelé qu’une seule fois pour l’ensemble du processus.)

    L’exemple de code suivant montre comment un demandeur doit appeler CoInitializeSecurity sous Windows 8 et Windows Server 2012 et versions ultérieures, afin d’être compatible avec VSS pour les partages de fichiers distants (RVSS) :

    // Initialize COM security.
   hr = CoInitializeSecurity(
        NULL,                          //  PSECURITY_DESCRIPTOR         pSecDesc,
        -1,                            //  LONG                         cAuthSvc,
        NULL,                          //  SOLE_AUTHENTICATION_SERVICE *asAuthSvc,
        NULL,                          //  void                        *pReserved1,
        RPC_C_AUTHN_LEVEL_PKT_PRIVACY, //  DWORD                        dwAuthnLevel,
        RPC_C_IMP_LEVEL_IMPERSONATE,   //  DWORD                        dwImpLevel,
        NULL,                          //  void                        *pAuthList,
        EOAC_STATIC,                   //  DWORD                        dwCapabilities,
        NULL                           //  void                        *pReserved3
        );

    Lors de la définition explicite de la sécurité de niveau COM d’un demandeur avec CoInitializeSecurity, vous devez faire ce qui suit :

    • Définissez le niveau d’authentification à au moins RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Pour une meilleure sécurité, envisagez d’utiliser RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
    • Définissez le niveau d’usurpation à RPC_C_IMP_LEVEL_IMPERSONATE.
    • Définissez les capacités de sécurité de dissimulation à EOAC_STATIC. Pour plus d’informations sur la dissimulation de sécurité, veuillez consulter la section Cloaking.

    L’exemple de code suivant montre comment un demandeur doit appeler CoInitializeSecurity sous Windows 7 et Windows Server 2008 R2 et versions antérieures (ou sous Windows 8 et Windows Server 2012 et versions ultérieures, si la compatibilité RVSS n’est pas nécessaire) :

    // Initialize COM security.
   hr = CoInitializeSecurity(
        NULL,                          //  PSECURITY_DESCRIPTOR         pSecDesc,
        -1,                            //  LONG                         cAuthSvc,
        NULL,                          //  SOLE_AUTHENTICATION_SERVICE *asAuthSvc,
        NULL,                          //  void                        *pReserved1,
        RPC_C_AUTHN_LEVEL_PKT_PRIVACY, //  DWORD                        dwAuthnLevel,
        RPC_C_IMP_LEVEL_IDENTIFY,      //  DWORD                        dwImpLevel,
        NULL,                          //  void                        *pAuthList,
        EOAC_NONE,                     //  DWORD                        dwCapabilities,
        NULL                           //  void                        *pReserved3
        );

    Lors de la définition explicite de la sécurité de niveau COM d’un demandeur avec CoInitializeSecurity, vous devez faire ce qui suit :

    • Définissez le niveau d’authentification à au moins RPC_C_AUTHN_LEVEL_CONNECT. Pour une meilleure sécurité, envisagez d’utiliser RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
    • Définissez le niveau d’usurpation à RPC_C_IMP_LEVEL_IDENTIFY à moins que le processus demandeur ait besoin de permettre l’usurpation pour des appels RPC ou COM spécifiques qui ne sont pas liés à VSS.

  • Autoriser uniquement les processus spécifiés à accéder au processus demandeur.

    Un serveur COM (tel qu’un demandeur) qui appelle CoInitializeSecurity avec un descripteur de sécurité non NULL comme premier paramètre peut utiliser le descripteur pour se configurer afin d’accepter uniquement les appels entrants des utilisateurs appartenant à un ensemble spécifique de comptes.

    Un demandeur doit s’assurer que les clients COM s’exécutant sous des utilisateurs valides sont autorisés à accéder à son processus. Un demandeur qui spécifie un descripteur de sécurité dans le premier paramètre doit autoriser les utilisateurs suivants à effectuer des appels entrants dans le processus demandeur :

    • Système local

    • Service local

      Windows XP : Cette valeur n’est pas prise en charge avant Windows Server 2003.

    • Service réseau

      Windows XP : Cette valeur n’est pas prise en charge avant Windows Server 2003.

    • Membres du groupe Administrateurs local

    • Membres du groupe Opérateurs de sauvegarde local

    • Utilisateurs spéciaux spécifiés dans l’emplacement du registre ci-dessous, avec « 1 » comme valeur REG_DWORD

Contrôle explicite de l’accès des comptes utilisateur à un demandeur

Il existe des cas où restreindre l’accès à un demandeur aux processus s’exécutant en tant que Système local, ou sous les groupes Administrateurs locaux ou Opérateurs de sauvegarde locaux, peut être trop restrictif.

Par exemple, un processus demandeur spécifié peut ne pas avoir besoin de s’exécuter sous un compte Administrateur ou Opérateur de sauvegarde. Pour des raisons de sécurité, il serait préférable de ne pas promouvoir artificiellement les privilèges des processus pour prendre en charge VSS.

Dans ces cas, la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl doit être modifiée pour indiquer à VSS qu’un utilisateur spécifié est autorisé à exécuter un demandeur VSS.

Sous cette clé, vous devez créer une sous-clé portant le même nom que le compte à qui l’accès doit être accordé ou refusé. Cette sous-clé doit être définie sur l’une des valeurs du tableau suivant.

Valeur Signification
0 Refuser l’accès de l’utilisateur à votre writer et demandeur.
1 Accorder à l’utilisateur l’accès à votre writer.
2 Accorder à l’utilisateur l’accès à votre demandeur.
3 Accorder à l’utilisateur l’accès à votre writer et demandeur.

 

L’exemple suivant accorde l’accès au compte « MyDomain\MyUser » :

HKEY_LOCAL_MACHINE
   SYSTEM
      CurrentControlSet
         Services
            VSS
               VssAccessControl
                  MyDomain\MyUser = 2<dl>
<dt>

                  Data type
</dt>
<dd>                  REG_DWORD</dd>
</dl>

Ce mécanisme peut également être utilisé pour restreindre explicitement un utilisateur autrement autorisé à exécuter un demandeur VSS. L’exemple suivant restreindra l’accès au compte « ThatDomain\Administrator » :

HKEY_LOCAL_MACHINE
   SYSTEM
      CurrentControlSet
         Services
            VSS
               VssAccessControl
                  ThatDomain\Administrator = 0<dl>
<dt>

                  Data type
</dt>
<dd>                  REG_DWORD</dd>
</dl>

L’utilisateur ThatDomain\Administrator ne pourrait pas exécuter un demandeur VSS.

Effectuer une sauvegarde de fichier de l’état du système

Si un demandeur effectue une sauvegarde de l’état du système en sauvegardant des fichiers individuels au lieu d’utiliser une image de volume pour la sauvegarde, il doit appeler les fonctions FindFirstFileNameW et FindNextFileNameW pour énumérer les liens physiques sur les fichiers situés dans les répertoires suivants :

  • Windows\system32\WDI\perftrack\
  • Windows\WINSXS\

Ces répertoires ne peuvent être accessibles que par les membres du groupe Administrateurs. Pour cette raison, un tel demandeur doit s’exécuter sous le compte système ou un compte utilisateur membre du groupe Administrateurs.

Windows XP et Windows Server 2003 : Les fonctions FindFirstFileNameW et FindNextFileNameW ne sont pas prises en charge avant Windows Vista et Windows Server 2008.