Considérations relatives à la sécurité pour les demandeurs

Article
06/13/2023

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

Lorsqu’il agit en tant que serveur, un demandeur expose un ensemble d’interfaces de rappel COM qui peuvent être appelées à partir de processus externes (tels que les enregistreurs ou le service VSS). Par conséquent, les demandeurs doivent gérer de manière sécurisée quels clients COM sont en mesure d’effectuer 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 enregistreur VSS ou par le service VSS. Les paramètres de sécurité spécifiques au demandeur doivent autoriser 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 d’utilisateur sous lequel il s’exécute.

Un demandeur doit généralement s’exécuter sous un utilisateur qui est membre du groupe Administrateurs ou 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 obtenir 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 le faire, car la gestion des exceptions COM peut masquer des erreurs irrécupérables 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 altérations et des blocages. Pour plus d’informations sur cet indicateur, consultez IGlobalOptions.

Définition de l’autorisation de vérification d’accès COM par défaut du demandeur

Les demandeurs doivent savoir que lorsque leur processus fait office de serveur (par exemple, en autorisant les rédacteurs à modifier le document des composants de sauvegarde), ils doivent autoriser les appels entrants d’autres participants VSS, tels que les rédacteurs ou le service VSS.

Toutefois, par défaut, un processus Windows autorise uniquement les clients COM qui s’exécutent sous la même session d’ouverture de session (SELF SID) ou qui s’exécutent sous le compte système local. Il s’agit d’un problème potentiel, car ces valeurs par défaut ne sont pas adéquates pour l’infrastructure VSS. Par exemple, les rédacteurs peuvent s’exécuter en tant que compte d’utilisateur « Opérateur de sauvegarde » qui ne se trouve ni dans la même session d’ouverture de session que le processus du demandeur ni comme compte système local.

Pour gérer ce type de problème, chaque processus de serveur COM peut contrôler davantage 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) à l’aide de CoInitializeSecurity pour définir une « autorisation de vérification d’accès COM par défaut » à l’échelle du processus.

Les demandeurs peuvent effectuer explicitement les opérations suivantes :

Autoriser l’accès à tous les processus à appeler dans le processus du demandeur.

Cette option peut être appropriée 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, comme le sont tous 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 la possibilité d’autoriser ses clients sur 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 à un demandeur, vous pouvez passer un descripteur de sécurité NULL comme premier paramètre de CoInitializeSecurity. (Notez que CoInitializeSecurity doit être appelé au maximum une fois pour l’ensemble du processus. Pour plus d’informations sur les appels CoInitializeSecurity , consultez la documentation COM ou MSDN.)

L’exemple de code suivant montre comment un demandeur doit appeler CoInitializeSecurity dans 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
        );
```
Lorsque vous définissez explicitement la sécurité au niveau COM d’un demandeur avec CoInitializeSecurity, vous devez effectuer les opérations suivantes :
- Définissez le niveau d’authentification sur 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’emprunt d’identité sur RPC_C_IMP_LEVEL_IMPERSONATE.
- Définissez les fonctionnalités de sécurité de EOAC_STATIC. Pour plus d’informations sur la sécurité de l’occultation, consultez Cloaking.
L’exemple de code suivant montre comment un demandeur doit appeler CoInitializeSecurity dans Windows 7 et Windows Server 2008 R2 et versions antérieures (ou dans 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
        );
```
Lorsque vous définissez explicitement la sécurité au niveau COM d’un demandeur avec CoInitializeSecurity, vous devez effectuer les opérations suivantes :
- Définissez le niveau d’authentification sur 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’emprunt d’identité sur RPC_C_IMP_LEVEL_IDENTIFY , sauf si le processus du demandeur doit autoriser l’emprunt d’identité pour des appels RPC ou COM spécifiques qui ne sont pas liés à VSS.
Autorisez uniquement l’accès aux processus spécifiés pour appeler le processus du 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 pour accepter les appels entrants uniquement d’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 à appeler son processus. Un demandeur qui spécifie un descripteur de sécurité dans le premier paramètre doit permettre aux utilisateurs suivants d’effectuer des appels entrants dans le processus du 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 du compte d’utilisateur à un demandeur

Il existe des cas où la restriction de 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 restrictive.

Par exemple, un processus de demandeur spécifié peut ne pas avoir besoin d’être exécuté sous un compte administrateur ou opérateur de sauvegarde. Pour des raisons de sécurité, il est préférable de ne pas promouvoir artificiellement les privilèges de processus pour prendre en charge VSS.

Dans ce cas, la clé de RegistreVSS\VssAccessControlControlServices\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Doit\ être modifiée pour indiquer à VSS qu’un utilisateur spécifié peut exécuter un demandeur VSS en toute sécurité.

Sous cette clé, vous devez créer une sous-clé portant le même nom que le compte auquel 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	Refusez à l’utilisateur l’accès à votre enregistreur et à votre demandeur.
1	Accordez à l’utilisateur l’accès à votre enregistreur.
2	Accordez à l’utilisateur l’accès à votre demandeur.
3	Accordez à l’utilisateur l’accès à votre rédacteur et à votre 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 empêcher explicitement un utilisateur autorisé d’exécuter un demandeur VSS. L’exemple suivant restreint l’accès à partir du 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 peut pas exécuter un demandeur VSS.

Exécution d’une sauvegarde de fichier de l’état système

Si un demandeur effectue une sauvegarde d’état 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 durs sur les fichiers qui se trouvent dans les répertoires suivants :

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

Ces répertoires sont accessibles uniquement aux membres du groupe Administrateurs. Pour cette raison, un tel demandeur doit s’exécuter sous le compte système ou un compte d’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.