Compartir a través de

Consideraciones de seguridad para solicitantes

  • Artículo

La infraestructura de VSS requiere que los solicitantes de VSS, como las aplicaciones de copia de seguridad, puedan funcionar como clientes COM y como servidor.

Al actuar como servidor, un solicitante expone un conjunto de interfaces de devolución de llamada COM que pueden invocarse desde procesos externos (como escritores o el servicio VSS). Por lo tanto, los solicitantes deben administrar de forma segura qué clientes COM pueden realizar llamadas COM entrantes a su proceso.

Del mismo modo, los solicitantes pueden actuar como cliente COM para las API COM proporcionadas por un escritor de VSS o por el servicio VSS. La configuración de seguridad específica del solicitante debe permitir llamadas COM salientes del solicitante a estos otros procesos.

El mecanismo más sencillo para administrar los problemas de seguridad de un solicitante implica la selección adecuada de la cuenta de usuario en la que se ejecuta.

Normalmente, un solicitante debe ejecutarse bajo un usuario que sea miembro del grupo Administradores o del grupo Operadores de copias de seguridad, o ejecutarse como Cuenta del sistema local.

De forma predeterminada, cuando un solicitante actúa como cliente COM, si no se ejecuta con estas cuentas, cualquier llamada COM se rechaza automáticamente con E_ACCESSDENIED, sin llegar a la implementación del método COM.

Deshabilitar el control de excepciones de COM

Cuando desarrolle un solicitante, establezca el indicador de opciones globales COM COMGLB_EXCEPTION_DONOT_HANDLE para desactivar el control de excepciones COM. Es importante hacerlo porque el control de excepciones COM puede enmascarar errores fatales en una aplicación VSS. El error que se enmascara puede dejar el proceso en un estado inestable e impredecible, lo que puede provocar corrupciones y bloqueos. Para obtener más información sobre este indicador, consulte IGlobalOptions.

Configurar el permiso de comprobación de acceso COM predeterminado del solicitante

Los solicitantes deben ser conscientes de que cuando su proceso actúa como servidor (por ejemplo, permitiendo a los escritores modificar el Backup Components Document), deben permitir llamadas entrantes de otros participantes de VSS, como escritores o el servicio VSS.

Sin embargo, por defecto, un proceso de Windows solo permitirá clientes COM que se estén ejecutando bajo la misma sesión de inicio de sesión (el SELF SID) o que se estén ejecutando bajo la cuenta del sistema local. Se trata de un posible problema porque estos valores predeterminados no son adecuados para la infraestructura de VSS. Por ejemplo, los escritores podrían ejecutarse como una cuenta de usuario de "Operador de copia de seguridad" que no esté en la misma sesión de inicio de sesión que el proceso solicitante ni sea una cuenta del sistema local.

Para controlar este tipo de problema, cada proceso de servidor COM puede ejercer un mayor control sobre si un cliente RPC o COM tiene permitido realizar un método COM implementado por el servidor (un solicitante en este caso) utilizando CoInitializeSecurity para establecer un "Permiso predeterminado de comprobación de acceso COM" para todo el proceso.

Los solicitantes pueden hacer explícitamente lo siguiente:

  • Permitir que todos los procesos accedan al proceso solicitante.

    Esta opción puede ser adecuada para la gran mayoría de los solicitantes y se usa en otros servidores COM (por ejemplo, todos los servicios de Windows basados en SVCHOST ya usan esta opción, como todos los servicios COM+ de forma predeterminada).

    Permitir que todos los procesos realicen llamadas COM entrantes no es necesariamente un punto débil de seguridad. Un solicitante que actúa como servidor COM, como todos los demás servidores COM, siempre conserva la opción de autorizar a sus clientes en cada método COM implementado en su proceso.

    Tenga en cuenta que las devoluciones de llamada COM internas implementadas por VSS están protegidas por defecto.

    Para permitir el acceso COM a todos los procesos a un solicitante, puede pasar un descriptor de seguridad NULL como primer parámetro de CoInitializeSecurity. (Tenga en cuenta que se debe llamar a CoInitializeSecurity como máximo una vez para todo el proceso).

    En el siguiente ejemplo de código se muestra cómo debe llamar un solicitante a CoInitializeSecurity en Windows 8 y Windows Server 2012 y versiones posteriores, con el fin de ser compatible con VSS para recursos compartidos de archivos remotos (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
        );

    Al establecer explícitamente la seguridad de nivel COM de un solicitante con CoInitializeSecurity, debe hacer lo siguiente:

    • Establezca el nivel de autenticación en al menos RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Para mejorar la seguridad, considere la posibilidad de usar RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
    • Establezca el nivel de suplantación en RPC_C_IMP_LEVEL_IMPERSONATE.
    • Establezca las capacidades de seguridad de ocultación en EOAC_STATIC. Para obtener más información sobre la seguridad de la ocultación, consulte Ocultación.

    En el siguiente ejemplo de código se muestra cómo debe llamar un solicitante a CoInitializeSecurity en Windows 7 y Windows Server 2008 R2 y versiones anteriores (o en Windows 8 y Windows Server 2012 y versiones posteriores, si no se necesita compatibilidad con 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_IDENTIFY,      //  DWORD                        dwImpLevel,
        NULL,                          //  void                        *pAuthList,
        EOAC_NONE,                     //  DWORD                        dwCapabilities,
        NULL                           //  void                        *pReserved3
        );

    Al establecer explícitamente la seguridad de nivel COM de un solicitante con CoInitializeSecurity, debe hacer lo siguiente:

    • Establezca el nivel de autenticación en al menos RPC_C_AUTHN_LEVEL_CONNECT. Para mejorar la seguridad, considere la posibilidad de usar RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
    • Establezca el nivel de suplantación en RPC_C_IMP_LEVEL_IDENTIFY a menos que el proceso solicitante necesite permitir la suplantación para llamadas RPC o COM específicas que no estén relacionadas con VSS.

  • Permita solo el acceso a los procesos especificados para llamar al proceso solicitante.

    Un servidor COM (como un solicitante) que llama a CoInitializeSecurity con un descriptor de seguridad que no es NULL, ya que el primer parámetro puede usar el descriptor para configurarse para aceptar llamadas entrantes solo de los usuarios que pertenecen a un conjunto específico de cuentas.

    Un solicitante debe asegurarse de que los clientes COM que se ejecutan bajo usuarios válidos están autorizados para llamar a su proceso. Un solicitante que especifica un descriptor de seguridad en el primer parámetro debe permitir que los siguientes usuarios realicen llamadas entrantes al proceso solicitante:

    • Sistema local

    • Servicio local

      Windows XP: este valor no se admite hasta Windows Server 2003.

    • Servicio de red

      Windows XP: este valor no se admite hasta Windows Server 2003.

    • Miembros del grupo local de administradores.

    • Miembros del grupo local de operadores de copia de seguridad

    • Usuarios especiales que se especifican en la ubicación del registro siguiente, con "1" como su valor REG_DWORD

Controlar explícitamente el acceso de la cuenta de usuario a un solicitante

Hay casos en los que restringir el acceso a un solicitante a los procesos que se ejecutan como sistema local, o en los grupos locales de administradores locales o de operadores de copia de seguridad, puede ser demasiado restrictivo.

Por ejemplo, es posible que un proceso solicitante especificado no tenga que ejecutarse normalmente bajo una cuenta de administrador o de operador de copia de seguridad. Por motivos de seguridad, sería mejor no promover artificialmente los privilegios de los procesos para que admitan VSS.

En estos casos, la clave de registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl debe modificarse para indicarle a VSS que es seguro que el usuario especificado ejecute un solicitante de VSS.

Bajo esta clave, debe crear una subclave que tenga el mismo nombre que la cuenta a la que se vaya a conceder o denegar el acceso. Esta subclave debe establecerse en uno de los valores de la siguiente tabla.

Valor Significado
0 Deniegue al usuario el acceso a su escritor y solicitante.
1 Conceda al usuario acceso a su escritor.
2 Conceda al usuario acceso a su solicitante.
3 Conceda al usuario el acceso a su escritor y su solicitante.

 

En el siguiente ejemplo se concede acceso a la cuenta "MyDomain\MyUser":

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

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

Este mecanismo también puede utilizarse para restringir explícitamente que un usuario autorizado ejecute un solicitante de VSS. En el siguiente ejemplo se restringirá el acceso desde la cuenta "ThatDomain\Administrator":

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

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

El usuario ThatDomain\Administrator no podría ejecutar un solicitante de VSS.

Realizar una copia de seguridad del estado del sistema

Si un solicitante realiza una copia de seguridad del estado del sistema haciendo una copia de seguridad de archivos individuales en lugar de utilizar una imagen de volumen para la copia de seguridad, debe llamar a las funciones FindFirstFileNameW y FindNextFileNameW para que enumeren los enlaces duros de los archivos que se encuentran en los siguientes directorios:

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

Solo pueden acceder a estos directorios los miembros del grupo Administradores. Por este motivo, dicho solicitante debe ejecutarse bajo la cuenta del sistema o una cuenta de usuario que sea miembro del grupo Administradores.

Windows XP y Windows Server 2003: Las funciones FindFirstFileNameW y FindNextFileNameW no se admiten hasta Windows Vista y Windows Server 2008.