Considerazioni sulla sicurezza per i richiedenti

Articolo
06/13/2023

L'infrastruttura VSS richiede ai richiedenti VSS, ad esempio applicazioni di backup, di essere in grado di funzionare sia come client COM che come server.

Quando si 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 proprio 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 corretta selezione dell'account utente in cui viene eseguito.

Un richiedente deve in genere essere eseguito in un utente membro del gruppo Administrators o del gruppo Operatori di backup oppure eseguire come account di sistema locale.

Per impostazione predefinita, quando un richiedente agisce come client COM, se non viene eseguito in 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 di opzioni com COMGLB_EXCEPTION_DONOT_HANDLE globale 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 delle autorizzazioni di controllo di accesso COM predefinite del richiedente

I richiedenti devono essere consapevoli che quando il processo funge da server (ad esempio, consentendo ai writer di modificare il documento componenti di backup), devono consentire chiamate in ingresso da altri partecipanti di VSS, ad esempio writer o servizio VSS.

Per impostazione predefinita, tuttavia, un processo di Windows consentirà solo i client COM in esecuzione nella stessa sessione di accesso (SELF SID) o in esecuzione nell'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 trovano nella stessa sessione di accesso del processo del richiedente o di un account di sistema locale.

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

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 stanno già usando questa opzione, come tutti i servizi COM+ per impostazione predefinita.

Consentire a tutti i processi di eseguire chiamate COM in ingresso non è necessariamente una debolezza della sicurezza. Un richiedente che funge da server COM, come tutti gli altri server COM, mantiene sempre l'opzione per autorizzare i client in ogni metodo COM implementato nel suo 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. Per altre informazioni sulle chiamate CoInitializeSecurity , vedere la documentazione COM o MSDN.

Nell'esempio di codice seguente viene illustrato come un richiedente deve chiamare CoInitializeSecurity in Windows 8 e Windows Server 2012 e versioni successive, per essere compatibili 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, è consigliabile eseguire le operazioni seguenti:
- Impostare il livello di autenticazione su almeno RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Per migliorare la sicurezza, considerare l'uso di RPC_C_AUTHN_LEVEL_PKT_PRIVACY.
- Impostare il livello di rappresentazione su RPC_C_IMP_LEVEL_IMPERSONATE.
- Impostare le funzionalità di sicurezza del mantello su EOAC_STATIC. Per altre informazioni sulla sicurezza del mantello, vedere Mantello.
Nell'esempio di codice seguente viene illustrato 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, è consigliabile eseguire le operazioni seguenti:
- Impostare il livello di autenticazione su almeno RPC_C_AUTHN_LEVEL_CONNECT. Per migliorare la sicurezza, considerare l'uso di 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 a VSS.
Consenti solo l'accesso 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 dagli utenti che appartengono a un set specifico di account.

Un richiedente deve assicurarsi che i client COM in esecuzione in utenti validi siano autorizzati a chiamare nel suo 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.
- Servizio di rete
  
  Windows XP: Questo valore non è supportato fino a Windows Server 2003.
- Membri del gruppo Administrators locale
- Membri del gruppo 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

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

Ad esempio, un processo del richiedente specificato potrebbe non essere normalmente necessario eseguire in un account Amministratore o Operatore di backup. Per motivi di sicurezza, è consigliabile non promuovere in modo artificiale i privilegi dei processi per supportare VSS.

In questi casi, la chiavedel Registro di sistema HKEY_LOCAL_MACHINESYSTEM\\CurrentControlSet\Services\VSSVssAccessControl deve essere modificata per indicare a VSS \ che un utente specificato è sicuro per eseguire un richiedente VSS.

In questa chiave è necessario creare una sottochiave con lo stesso nome dell'account che deve essere concesso o negato 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.

Nell'esempio seguente viene concesso 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 dall'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 sarà in grado di eseguire un richiedente VSS.

Esecuzione di un backup file dello stato del sistema

Se un richiedente esegue il backup dello stato del sistema eseguendo il backup di singoli file anziché usare un'immagine del volume per il backup, è necessario 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 nell'account di sistema o in 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.