Considerazioni sulla sicurezza per i richiedenti

L'infrastruttura vss richiede ai richiedenti vss, ad esempio le applicazioni di backup, di funzionare sia come client COM che come server.

Quando funge da server, un richiedente espone un set di interfacce di callback COM che possono essere richiamate da processi esterni , ad esempio writer o servizio VSS. Pertanto, i richiedenti devono gestire in modo sicuro i client COM in grado di effettuare chiamate COM in ingresso nel processo.

Analogamente, i richiedenti possono fungere da client COM per le API COM fornite da un writer VSS o dal servizio VSS. Le impostazioni di sicurezza specifiche del richiedente devono consentire chiamate COM in uscita dal richiedente a questi altri processi.

Il meccanismo più semplice per la gestione dei problemi di sicurezza di un richiedente comporta una selezione corretta dell'account utente in cui viene eseguito.

Un richiedente deve in genere essere eseguito con un utente membro del gruppo Administrators o del gruppo Backup Operators oppure eseguito come account di sistema locale.

Per impostazione predefinita, quando un richiedente funge da client COM, se non viene eseguito con questi account, qualsiasi chiamata COM viene rifiutata automaticamente con E_ACCESSDENIED, senza nemmeno arrivare all'implementazione del metodo COM.

Disabilitazione della gestione delle eccezioni COM

Quando si sviluppa un richiedente, impostare il flag com COMGLB_EXCEPTION_DONOT_HANDLE opzioni globali per disabilitare la gestione delle eccezioni COM. È importante eseguire questa operazione perché la gestione delle eccezioni COM può mascherare gli errori irreversibili in un'applicazione VSS. L'errore mascherato può lasciare il processo in uno stato instabile e imprevedibile, che può causare danneggiamenti e blocchi. Per altre informazioni su questo flag, vedere IGlobalOptions.

Impostazione dell'autorizzazione controllo di accesso COM predefinita del richiedente

I richiedenti devono tenere presente che quando il processo funge da server (ad esempio, consentendo ai writer di modificare il documento dei componenti di backup), deve consentire le chiamate in ingresso da altri partecipanti del Servizio Copia Shadow del database, ad esempio writer o servizio Vss.

Tuttavia, per impostazione predefinita, un processo di Windows consentirà solo i client COM in esecuzione nella stessa sessione di accesso (SID SELF) o in esecuzione con l'account di sistema locale. Si tratta di un potenziale problema perché queste impostazioni predefinite non sono adeguate per l'infrastruttura vss. Ad esempio, i writer possono essere eseguiti come account utente "Operatore di backup" che non si trova nella stessa sessione di accesso del processo del richiedente né di un account di sistema locale.

Per gestire questo tipo di problema, ogni processo del server COM può esercitare un ulteriore controllo sul fatto che un client RPC o COM sia autorizzato a eseguire un metodo COM implementato dal server (un richiedente in questo caso) usando CoInitializeSecurity per impostare un'autorizzazione di controllo di accesso COM predefinita a livello di processo.

I richiedenti possono eseguire in modo esplicito le operazioni seguenti:

• Consentire a tutti i processi di accedere alla chiamata al processo del richiedente.

  Questa opzione può essere adeguata per la maggior parte dei richiedenti e viene usata da altri server COM, ad esempio tutti i servizi Windows basati su SVCHOST usano già questa opzione, come tutti i servizi COM+ per impostazione predefinita.

  Consentire a tutti i processi di eseguire chiamate COM in ingresso non è necessariamente un punto debole per la sicurezza. Un richiedente che funge da server COM, come tutti gli altri server COM, mantiene sempre la possibilità di autorizzare i client su ogni metodo COM implementato nel processo.

  Si noti che i callback COM interni implementati da VsS sono protetti per impostazione predefinita.

  Per consentire a tutti i processi l'accesso COM a un richiedente, è possibile passare un descrittore di sicurezza NULL come primo parametro di CoInitializeSecurity. (Si noti che CoInitializeSecurity deve essere chiamato al massimo una volta per l'intero processo.

  L'esempio di codice seguente mostra come un richiedente deve chiamare CoInitializeSecurity in Windows 8 e Windows Server 2012 e versioni successive per essere compatibile con VSS per le condivisioni file remote (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
          );
  

  Quando si imposta in modo esplicito la sicurezza a livello COM di un richiedente con CoInitializeSecurity, è necessario eseguire le operazioni seguenti:

  • Impostare il livello di autenticazione su almeno RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Per una maggiore sicurezza, è consigliabile usare RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
  • Impostare il livello di rappresentazione su RPC_C_IMP_LEVEL_IMPERSONATE.
  • Impostare le funzionalità di sicurezza di mantello su EOAC_STATIC. Per altre informazioni sulla sicurezza dei mantelli, vedere Mantello.

  L'esempio di codice seguente mostra come un richiedente deve chiamare CoInitializeSecurity in Windows 7 e Windows Server 2008 R2 e versioni precedenti (o in Windows 8 e Windows Server 2012 e versioni successive, se la compatibilità RVSS non è necessaria):

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

  Quando si imposta in modo esplicito la sicurezza a livello COM di un richiedente con CoInitializeSecurity, è necessario eseguire le operazioni seguenti:

  • Impostare il livello di autenticazione su almeno RPC_C_AUTHN_LEVEL_CONNECT. Per una maggiore sicurezza, è consigliabile usare RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
  • Impostare il livello di rappresentazione su RPC_C_IMP_LEVEL_IDENTIFY a meno che il processo del richiedente non debba consentire la rappresentazione per chiamate RPC o COM specifiche non correlate al servizio Copia Shadow del database.

• Consentire l'accesso solo ai processi specificati per chiamare nel processo del richiedente.

  Un server COM (ad esempio un richiedente) che chiama CoInitializeSecurity con un descrittore di sicurezza non NULL come primo parametro può usare il descrittore per configurare se stesso per accettare chiamate in ingresso solo da utenti appartenenti a un set specifico di account.

  Un richiedente deve assicurarsi che i client COM in esecuzione con utenti validi siano autorizzati a chiamare nel processo. Un richiedente che specifica un descrittore di sicurezza nel primo parametro deve consentire agli utenti seguenti di eseguire chiamate in ingresso nel processo del richiedente:

  • Sistema locale

  • Servizio locale

    Windows XP: questo valore non è supportato fino a Windows Server 2003.

  • Network Service (Servizio di rete)

    Windows XP: questo valore non è supportato fino a Windows Server 2003.

  • Membri del gruppo Administrators locale

  • Membri del gruppo di operatori di backup locali

  • Utenti speciali specificati nel percorso del Registro di sistema seguente, con "1" come valore REG_DWORD

Controllo esplicito dell'accesso dell'account utente a un richiedente

In alcuni casi, la limitazione dell'accesso a un richiedente ai processi in esecuzione come sistema locale o in amministratori locali o gruppi di operatori di backup locali potrebbe essere troppo restrittiva.

Ad esempio, un processo richiedente specificato potrebbe non dover essere eseguito in genere con un account Amministratore o Operatore di backup. Per motivi di sicurezza, è consigliabile non promuovere artificialmente i privilegi dei processi per supportare il Servizio Copia Shadow del database.

In questi casi, la chiave del Registro di sistema HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl deve essere modificata per indicare a VSS che un utente specificato è sicuro di eseguire un richiedente VSS.

In questa chiave è necessario creare una sottochiave con lo stesso nome dell'account a cui concedere o negare l'accesso. Questa sottochiave deve essere impostata su uno dei valori della tabella seguente.

Valore	Significato
0	Negare all'utente l'accesso al writer e al richiedente.
1	Concedere all'utente l'accesso al writer.
2	Concedere all'utente l'accesso al richiedente.
3	Concedere all'utente l'accesso al writer e al richiedente.

 

L'esempio seguente concede l'accesso all'account "MyDomain\MyUser":

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

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

Questo meccanismo può essere usato anche per limitare in modo esplicito un utente altrimenti consentito all'esecuzione di un richiedente VSS. L'esempio seguente limita l'accesso dall'account "ThatDomain\Administrator":

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

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

L'utente ThatDomain\Administrator non è in grado di eseguire un richiedente VSS.

Esecuzione di un backup di file dello stato del sistema

Se un richiedente esegue il backup dello stato del sistema eseguendo il backup di singoli file invece di usare un'immagine del volume per il backup, deve chiamare le funzioni FindFirstFileNameW e FindNextFileNameW per enumerare i collegamenti rigidi nei file che si trovano nelle directory seguenti:

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

Queste directory possono essere accessibili solo dai membri del gruppo Administrators. Per questo motivo, un richiedente di questo tipo deve essere eseguito con l'account di sistema o un account utente membro del gruppo Administrators.

Windows XP e Windows Server 2003: le funzioni FindFirstFileNameW e FindNextFileNameW non sono supportate fino a Windows Vista e Windows Server 2008.