Considerações de segurança para solicitantes

Artigo
06/12/2023

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

Ao agir como um servidor, um solicitante expõe um conjunto de interfaces de retorno de chamada COM que podem ser invocadas de processos externos (como gravadores ou o serviço VSS). Portanto, os solicitantes precisam gerenciar com segurança quais clientes COM são capazes de 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 problemas de segurança de um solicitante envolve a seleção adequada da conta de usuário sob a qual ela é executada.

Normalmente, um solicitante precisa ser executado em um usuário que seja membro do grupo Administradores ou do grupo Operadores de Backup ou executado como a conta 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 sequer acessar a implementação do método COM.

Desabilitando o tratamento de exceções COM

Ao desenvolver um solicitante, defina o sinalizador com COMGLB_EXCEPTION_DONOT_HANDLE opções globais para desabilitar o tratamento de exceções COM. É importante fazer isso porque o tratamento de exceções 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ção e travamentos. Para obter mais informações sobre esse sinalizador, consulte IGlobalOptions.

Configuração da 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 recebidas 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 em execução na mesma sessão de logon (o SID SELF) ou em execução na conta 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á nem na mesma sessão de logon que o processo solicitante nem uma conta do Sistema Local.

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

Os solicitantes podem fazer o seguinte explicitamente:

Permitir que todos os processos acessem para chamar 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 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 executem chamadas COM de entrada não é necessariamente uma fraqueza 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 COM acessem 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. Consulte a documentação com ou o MSDN para obter mais informações sobre chamadas coInitializeSecurity .)

O exemplo de código a seguir mostra como um solicitante deve chamar CoInitializeSecurity em 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 em nível COM de um solicitante com CoInitializeSecurity, você deve fazer o seguinte:
- Defina o nível de autenticação como pelo menos RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Para obter uma melhor segurança, considere usar RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
- Defina o nível de representação como RPC_C_IMP_LEVEL_IMPERSONATE.
- Defina as funcionalidades 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 anteriores (ou em Windows 8 e Windows Server 2012 e posterior, se a compatibilidade 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 em nível COM de um solicitante com CoInitializeSecurity, você deve fazer o seguinte:
- Defina o nível de autenticação como pelo menos RPC_C_AUTHN_LEVEL_CONNECT. Para obter uma melhor segurança, considere usar RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
- Defina o nível de representação como RPC_C_IMP_LEVEL_IDENTIFY a menos que o processo solicitante precise permitir a representação para chamadas RPC ou COM específicas que não estão relacionadas ao VSS.
Permitir acesso somente a processos especificados para chamar no processo solicitante.

Um servidor COM (como um solicitante) que está chamando CoInitializeSecurity com um descritor de segurança não NULL , pois 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 em usuários válidos estejam autorizados a chamar em 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 administradores locais
- Membros do grupo operadores de backup local
- Usuários especiais especificados no local do Registro abaixo, com "1" como seu valor REG_DWORD

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

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

Por exemplo, um processo solicitante especificado normalmente não precisa 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 dar suporte ao VSS.

Nesses casos, a chave do registrovssAccessControl\ do HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ deve ser modificada para instruir o VSS de que um usuário especificado é seguro para executar um solicitante VSS.

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

Valor	Significado
0	Negue o acesso do usuário ao gravador e ao solicitante.
1	Conceda ao usuário acesso ao gravador.
2	Conceda ao usuário acesso ao solicitante.
3	Conceda ao usuário acesso 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 permitido 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 seria capaz de executar um solicitante vss.

Executando um backup de arquivo do estado do sistema

Se um solicitante executar o backup de 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 esse motivo, esse solicitante deve 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.

Compartilhar via