Beveiligingsoverwegingen voor aanvragers
Voor de VSS-infrastructuur moeten VSS-aanvragers, zoals back-uptoepassingen, zowel als COM-clients als als een server kunnen functioneren.
Wanneer deze fungeert als een server, maakt een aanvrager een set COM-callback-interfaces beschikbaar die kunnen worden aangeroepen vanuit externe processen (zoals schrijvers of de VSS-service). Daarom moeten aanvragers veilig beheren welke COM-clients in staat zijn om binnenkomende COM-aanroepen te doen in het proces.
Op dezelfde manier kunnen aanvragers fungeren als een COM-client voor de COM-API's die worden geleverd door een VSS Writer of door de VSS-service. De specifieke beveiligingsinstellingen van de aanvrager moeten uitgaande COM-aanroepen van de aanvrager naar deze andere processen toestaan.
Het eenvoudigste mechanisme voor het beheren van de beveiligingsproblemen van een aanvrager omvat de juiste selectie van het gebruikersaccount waaronder het wordt uitgevoerd.
Een aanvrager moet doorgaans worden uitgevoerd onder een gebruiker die lid is van de groep Administrators of de groep Back-upoperators, of moet worden uitgevoerd als het lokale systeemaccount.
Wanneer een aanvrager als COM-client fungeert en niet onder deze accounts wordt uitgevoerd, wordt elke COM-aanroep automatisch geweigerd met E_ACCESSDENIED, zonder dat de COM-methode-implementatie zelfs maar wordt bereikt.
COM-uitzonderingsafhandeling uitschakelen
Bij het ontwikkelen van een verzoeker stelt u de globale optiesvlag COM-COMGLB_EXCEPTION_DONOT_HANDLE in om de verwerking van COM-fouten uit te schakelen. Het is belangrijk om dit te doen omdat COM-uitzonderingsafhandeling fatale fouten in een VSS-toepassing kan maskeren. De fout die wordt gemaskeerd, kan het proces instabiel en onvoorspelbaar maken, wat kan leiden tot beschadiging en vastlopen. Zie IGlobalOptionsvoor meer informatie over deze vlag.
Standaardmachtiging voor COM-toegangscontrole instellen voor aanvrager
Aanvragers moeten zich ervan bewust zijn dat wanneer hun proces fungeert als een server (bijvoorbeeld door schrijvers toe te staan het document van back-uponderdelen te wijzigen), ze oproepen binnen moeten toestaan van andere VSS-deelnemers, zoals de VSS-service of schrijvers.
Standaard staat een Windows-proces echter alleen COM-clients toe die worden uitgevoerd onder dezelfde aanmeldingssessie (de SELF-SID) of worden uitgevoerd onder het lokale systeemaccount. Dit is een mogelijk probleem omdat deze standaardinstellingen niet geschikt zijn voor de VSS-infrastructuur. Schrijvers kunnen bijvoorbeeld worden uitgevoerd als een 'Backup-operator'-gebruikersaccount dat zich niet in dezelfde aanmeldingssessie bevindt als het aanvragerproces of een Lokaal Systeem-account.
Als u dit type probleem wilt afhandelen, kan elk COM-serverproces meer controle uitoefenen over het feit of een RPC- of COM-client een COM-methode mag uitvoeren die door de server is geïmplementeerd (in dit geval een aanvrager) met behulp van CoInitializeSecurity om een procesbrede "Standaard COM-toegangscontrolemachtiging" in te stellen.
Aanvragers kunnen het volgende expliciet doen:
Hiermee staat u alle processen toegang toe om het aanvragerproces aan te roepen.
Deze optie is mogelijk voldoende voor de overgrote meerderheid van de aanvragers en wordt gebruikt door andere COM-servers, bijvoorbeeld alle windows-services op basis van SVCHOST gebruiken deze optie al, net zoals alle COM+ Services standaard.
Het toestaan dat alle processen binnenkomende COM-aanroepen uitvoeren, is niet per se een beveiligingsrisico. Een aanvrager die fungeert als een COM-server, zoals alle andere COM-servers, behoudt altijd de optie om de clients te autoriseren op elke COM-methode die in het proces wordt geïmplementeerd.
Interne COM-callbacks die door VSS zijn geïmplementeerd, worden standaard beveiligd.
Als u alle processen COM-toegang tot een aanvrager wilt toestaan, kunt u een NULL- beveiligingsdescriptor doorgeven als de eerste parameter van CoInitializeSecurity. (Houd er rekening mee dat CoInitializeSecurity maximaal één keer moet worden aangeroepen voor het hele proces.)
In het volgende codevoorbeeld ziet u hoe een aanvrager CoInitializeSecurity in Windows 8 en Windows Server 2012 en hoger moet aanroepen om compatibel te zijn met VSS voor externe bestandsshares (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_CLOAKING, // DWORD dwCapabilities, NULL // void *pReserved3 );
Wanneer u de COM-beveiliging van een aanvrager expliciet instelt met CoInitializeSecurity, moet u het volgende doen:
- Stel het verificatieniveau in op ten minste RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Voor een betere beveiliging kunt u overwegen RPC_C_AUTHN_LEVEL_PKT_PRIVACYte gebruiken.
- Stel het imitatieniveau in op RPC_C_IMP_LEVEL_IMPERSONATE.
- Stel de beveiligingsmogelijkheden voor cloaking in op EOAC_STATIC_CLOAKING. Zie Cloakingvoor meer informatie over het verbergen van beveiliging.
In het volgende codevoorbeeld ziet u hoe een aanvrager CoInitializeSecurity- moet aanroepen in Windows 7 en Windows Server 2008 R2 en eerder (of in Windows 8 en Windows Server 2012 en hoger, als RVSS-compatibiliteit niet nodig is):
// 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 );
Wanneer u de COM-beveiliging van een aanvrager expliciet instelt met CoInitializeSecurity, moet u het volgende doen:
- Stel het verificatieniveau in op ten minste RPC_C_AUTHN_LEVEL_CONNECT. Voor een betere beveiliging kunt u overwegen RPC_C_AUTHN_LEVEL_PKT_PRIVACYte gebruiken.
- Stel het imitatieniveau in op RPC_C_IMP_LEVEL_IDENTIFY, tenzij het aanvragerproces imitatie moet toestaan voor specifieke RPC- of COM-aanroepen die niet zijn gerelateerd aan VSS.
Sta alleen opgegeven processen toegang toe om het aanvragerproces aan te roepen.
Een COM-server (zoals een aanvrager) die CoInitializeSecurity aanroept met een niet-NULL- beveiligingsdescriptor als de eerste parameter, kan deze descriptor gebruiken om zichzelf te configureren zodat het alleen binnenkomende oproepen accepteert van gebruikers die tot een specifieke reeks accounts behoren.
Een aanvrager moet ervoor zorgen dat COM-clients die worden uitgevoerd onder geldige gebruikers, gemachtigd zijn om zijn proces aan te roepen. Een aanvrager die een beveiligingsdescriptor in de eerste parameter opgeeft, moet de volgende gebruikers toestaan binnenkomende aanroepen uit te voeren in het proces van de aanvrager:
Lokaal systeem
Lokale service
Windows XP: Deze waarde wordt pas ondersteund als Windows Server 2003.
Netwerkservice
Windows XP: Deze waarde wordt pas ondersteund als Windows Server 2003.
Leden van de lokale groep Administrators
Leden van de lokale groep back-up-operators
Speciale gebruikers die zijn opgegeven in de onderstaande registerlocatie, met '1' als hun REG_DWORD waarde
Gebruikersaccounttoegang expliciet controleren voor een verzoeker
Er zijn gevallen waarin het beperken van de toegang tot een verzoeker tot processen die worden uitgevoerd als Lokaal Systeem, of onder de lokale beheerders- of lokale Back-up Operators-groepen, te beperkend kan zijn.
Het is bijvoorbeeld mogelijk dat een opgegeven aanvragerproces normaal gesproken niet moet worden uitgevoerd onder een Administrator- of Backup Operator-account. Om veiligheidsredenen is het raadzaam om de processenbevoegdheden niet kunstmatig te promoten ter ondersteuning van VSS.
In deze gevallen moet de registersleutel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl worden gewijzigd om VSS te laten instrueren dat een opgegeven gebruiker veilig is om een VSS-aanvrager uit te voeren.
Onder deze sleutel moet u een subsleutel maken met dezelfde naam als het account waaraan toegang moet worden verleend of geweigerd. Deze subsleutel moet worden ingesteld op een van de waarden in de volgende tabel.
Waarde | Betekenis |
---|---|
0 | De gebruiker toegang tot uw schrijver en aanvrager weigeren. |
1 | Geef de gebruiker toegang tot uw schrijver. |
2 | Verdeel de gebruiker toegang tot uw aanvrager. |
3 | Verleen de gebruiker toegang tot uw schrijver en aanvrager. |
In het volgende voorbeeld verleent u toegang tot het account 'MyDomain\MyUser':
HKEY_LOCAL_MACHINE
SYSTEM
CurrentControlSet
Services
VSS
VssAccessControl
MyDomain\MyUser = 2<dl>
<dt>
Data type
</dt>
<dd> REG_DWORD</dd>
</dl>
Dit mechanisme kan ook worden gebruikt om expliciet te beperken dat een anderszins toegestane gebruiker een VSS-aanvrager uitvoert. In het volgende voorbeeld wordt de toegang beperkt tot het account ThatDomain\Administrator:
HKEY_LOCAL_MACHINE
SYSTEM
CurrentControlSet
Services
VSS
VssAccessControl
ThatDomain\Administrator = 0<dl>
<dt>
Data type
</dt>
<dd> REG_DWORD</dd>
</dl>
De gebruiker ThatDomain\Administrator kan geen VSS-aanvrager uitvoeren.
Een bestandsback-up van de systeemstatus uitvoeren
Als een aanvrager een systeemstatusback-up uitvoert door een back-up te maken van afzonderlijke bestanden in plaats van een volume-installatiekopieën te gebruiken voor de back-up, moet deze de FindFirstFileNameW- aanroepen en FindNextFileNameW- functies om harde koppelingen te inventariseren op bestanden die zich in de volgende mappen bevinden:
- Windows\system32\WDI\perftrack\
- Windows\WINSXS\
Deze mappen kunnen alleen worden geopend door leden van de groep Administrators. Daarom moet een dergelijk proces worden uitgevoerd onder het systeemaccount of een gebruikersaccount dat lid is van de groep Administrators.
Windows XP en Windows Server 2003: De functies FindFirstFileNameW en FindNextFileNameW worden pas ondersteund als Windows Vista en Windows Server 2008.