Compartilhar via

Considerações de segurança para solicitantes

  • Artigo

A infraestrutura do VSS requer que os solicitantes do VSS, como aplicativos de backup, possam funcionar como clientes COM e como um servidor.

Ao atuar como um servidor, um solicitante expõe um conjunto de interfaces de retorno de chamada COM que podem ser invocadas de processos externos (como escritores ou o serviço VSS). Portanto, os solicitantes precisam gerenciar com segurança quais clientes COM podem fazer chamadas COM de entrada em seu processo.

Da mesma forma, os solicitantes podem atuar como um cliente COM para as APIs COM fornecidas por um gravador VSS ou pelo serviço VSS. As configurações de segurança específicas do solicitante devem permitir chamadas COM de saída do solicitante para esses outros processos.

O mecanismo mais simples para gerenciar os problemas de segurança de um solicitante envolve a seleção adequada da conta de usuário na qual ele é executado.

Um solicitante geralmente precisa ser executado em um usuário que seja membro do grupo Administradores ou do grupo Operadores de Backup, ou executar como a conta do Sistema Local.

Por padrão, quando um solicitante está atuando como um cliente COM, se ele não for executado nessas contas, qualquer chamada COM será rejeitada automaticamente com E_ACCESSDENIED, sem nem mesmo chegar à implementação do método COM.

Desabilitar o tratamento de exceção COM

Ao desenvolver um solicitante, defina o sinalizador de opções globais COM COMGLB_EXCEPTION_DONOT_HANDLE para desabilitar o tratamento de exceções COM. É importante fazer isso porque o tratamento de exceção COM pode mascarar erros fatais em um aplicativo VSS. O erro mascarado pode deixar o processo em um estado instável e imprevisível, o que pode levar a corrupções e travamentos. Para obter mais informações sobre esse sinalizador, consulte IGlobalOptions.

Definir a permissão de verificação de acesso COM padrão do solicitante

Os solicitantes precisam estar cientes de que, quando seu processo atua como um servidor (por exemplo, permitindo que os gravadores modifiquem o Documento de Componentes de Backup), eles devem permitir chamadas de entrada de outros participantes do VSS, como gravadores ou o serviço VSS.

No entanto, por padrão, um processo do Windows permitirá apenas clientes COM que estão sendo executados na mesma sessão de logon (o SID SELF) ou na conta do Sistema Local. Esse é um problema potencial porque esses padrões não são adequados para a infraestrutura do VSS. Por exemplo, os gravadores podem ser executados como uma conta de usuário "Operador de Backup" que não está na mesma sessão de logon que o processo do solicitante nem em uma conta do Sistema Local.

Para lidar com esse tipo de problema, cada processo de servidor COM pode exercer controle adicional sobre se um cliente RPC ou COM tem permissão para executar um método COM implementado pelo servidor (um solicitante nesse caso) usando CoInitializeSecurity para definir uma "Permissão de Verificação de Acesso COM Padrão" em todo o processo.

Os solicitantes podem fazer explicitamente o seguinte:

  • Permitir que todos os processos acessem a chamada para o processo do solicitante.

    Essa opção pode ser adequada para a grande maioria dos solicitantes e é usada por outros servidores COM, por exemplo, todos os serviços do Windows baseados em SVCHOST já estão usando essa opção, assim como todos os serviços COM+ por padrão.

    Permitir que todos os processos realizem chamadas COM de entrada não é necessariamente uma falha de segurança. Um solicitante que atua como um servidor COM, como todos os outros servidores COM, sempre mantém a opção de autorizar seus clientes em todos os métodos COM implementados em seu processo.

    Observe que os retornos de chamada COM internos implementados pelo VSS são protegidos por padrão.

    Para permitir que todos os processos tenham acesso COM a um solicitante, você pode passar um descritor de segurança NULL como o primeiro parâmetro de CoInitializeSecurity. (Observe que CoInitializeSecurity deve ser chamado no máximo uma vez para todo o processo.)

    O exemplo de código a seguir mostra como um solicitante deve chamar CoInitializeSecurity no Windows 8 e Windows Server 2012 e posterior, para ser compatível com o VSS para compartilhamentos de arquivos 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
        );

    Ao definir explicitamente a segurança de nível COM de um solicitante com CoInitializeSecurity, você deve fazer o seguinte:

    • Defina o nível de autenticação para pelo menos RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Para melhor segurança, considere usar RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
    • Defina o nível de representação para RPC_C_IMP_LEVEL_IMPERSONATE.
    • Defina os recursos de segurança de camuflagem como EOAC_STATIC. Para obter mais informações sobre a segurança de camuflagem, consulte Camuflagem.

    O exemplo de código a seguir mostra como um solicitante deve chamar CoInitializeSecurity no Windows 7 e Windows Server 2008 R2 e versões anteriores (ou no Windows 8 e Windows Server 2012 e versões posteriores, se a compatibilidade com RVSS não for necessária):

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

    Ao definir explicitamente a segurança de nível COM de um solicitante com CoInitializeSecurity, você deve fazer o seguinte:

    • Defina o nível de autenticação para pelo menos RPC_C_AUTHN_LEVEL_CONNECT. Para melhor segurança, considere usar RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
    • Defina o nível de representação para RPC_C_IMP_LEVEL_IDENTIFY a menos que o processo do solicitante precise permitir a representação para chamadas RPC ou COM específicas não relacionadas ao VSS.

  • Permitir que apenas processos especificados acessem o processo do solicitante.

    Um servidor COM (como um solicitante) que está chamando CoInitializeSecurity com um descritor de segurança não NULL como o primeiro parâmetro pode usar o descritor para se configurar para aceitar chamadas de entrada somente de usuários que pertencem a um conjunto específico de contas.

    Um solicitante deve garantir que os clientes COM em execução com usuários válidos estejam autorizados a chamar seu processo. Um solicitante que especifica um Descritor de Segurança no primeiro parâmetro deve permitir que os seguintes usuários executem chamadas de entrada no processo do solicitante:

    • Sistema Local

    • Serviço Local

      Windows XP: esse valor não tem suporte até o Windows Server 2003.

    • Serviço de Rede

      Windows XP: esse valor não tem suporte até o Windows Server 2003.

    • Membros do grupo local de Administradores

    • Membros do grupo local de Operadores de Backup

    • Usuários especiais que são especificados no local do registro abaixo, com "1" como seu valor REG_DWORD

Controlar explicitamente o acesso da conta de usuário a um solicitante

Há casos em que restringir o acesso de um solicitante a processos em execução como Sistema Local ou nos grupos locais de Administradores ou Operadores de Backup pode ser muito restritivo.

Por exemplo, um processo de solicitante especificado pode não precisar ser executado em uma conta de Administrador ou Operador de Backup. Por motivos de segurança, seria melhor não promover artificialmente os privilégios de processos para oferecer suporte ao VSS.

Nesses casos, a chave do registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl deve ser modificado para instruir o VSS que um usuário especificado está seguro para executar um solicitante VSS.

Nessa chave, você deve criar uma subchave que tenha o mesmo nome da conta que deve receber ou negar acesso. Essa subchave deve ser definida como um dos valores na tabela a seguir.

Valor Significado
0 Negue o acesso de usuário ao gravador e ao solicitante.
1 Conceda o acesso de usuário ao seu gravador.
2 Conceda o acesso de usuário ao seu solicitante.
3 Conceda o acesso de usuário ao gravador e ao solicitante.

 

O exemplo a seguir concede acesso à conta "MyDomain\MyUser":

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

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

Esse mecanismo também pode ser usado para restringir explicitamente um usuário autorizado de executar um solicitante VSS. O exemplo a seguir restringirá o acesso da conta "ThatDomain\Administrator":

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

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

O usuário ThatDomain\Administrator não conseguiria executar um solicitante VSS.

Executar um backup de arquivo do estado do sistema

Se um solicitante executar um backup do estado do sistema fazendo backup de arquivos individuais em vez de usar uma imagem de volume para o backup, ele deverá chamar as funções FindFirstFileNameW e FindNextFileNameW para enumerar links rígidos em arquivos localizados nos seguintes diretórios:

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

Esses diretórios só podem ser acessados por membros do grupo Administradores. Por isso, esse solicitante deverá ser executado na conta do sistema ou em uma conta de usuário que seja membro do grupo Administradores.

Windows XP e Windows Server 2003: As funções FindFirstFileNameW e FindNextFileNameW não têm suporte até o Windows Vista e o Windows Server 2008.