Freigeben über

Sicherheitsüberlegungen für Anforderer

  • Artikel

Die VSS-Infrastruktur erfordert, dass VSS-Anforderer, z. B. Sicherungsanwendungen, sowohl als COM-Clients als auch als Server fungieren können.

Wenn ein Anforderer als Server fungiert, macht er Anforderer eine Reihe von COM-Rückruf-Schnittstellen verfügbar, die von externen Prozessen aufgerufen werden können (z. B. Autoren oder VSS-Service). Daher müssen Anforderer in sicherer Weise festlegen, welche COM-Clients eingehende COM-Aufrufe an ihren Prozess tätigen können.

Ebenso können Anforderer als COM-Client für die COM-APIs fungieren, die von einem VSS-Autor oder vom VSS-Service bereitgestellt werden. Die anfordererspezifischen Sicherheitseinstellungen müssen ausgehende COM-Aufrufe vom Anforderer an diese anderen Prozesse zulassen.

Der einfachste Mechanismus für das Management der Sicherheitsprobleme eines Anforderers beinhaltet die ordnungsgemäße Auswahl des Benutzerkontos, unter dem er ausgeführt wird.

Typischerweise muss ein Anforderer unter einem Benutzer ausgeführt werden, der entweder Mitglied der Gruppe „Administratoren“ oder der Gruppe „Sicherungsoperatoren“ ist oder als lokales Systemkonto ausgeführt wird.

Standardmäßig gilt: Wenn ein Anforderer als COM-Client fungiert und nicht unter diesen Konten ausgeführt wird, wird jeder COM-Aufruf automatisch mit E_ACCESSDENIED abgewiesen, ohne dass auch nur die Implementierung der COM-Methode erreicht wird.

Deaktivieren der COM-Ausnahmebehandlung

Wenn Sie einen Anforderer entwickeln, legen Sie das globale Options-Flag COM-COMGLB_EXCEPTION_DONOT_HANDLE fest, um die COM-Ausnahmebehandlung zu deaktivieren. Dies ist wichtig, da die COM-Ausnahmebehandlung schwerwiegende Fehler in einer VSS-Anwendung verschleiern kann. Der verschleierte Fehler kann den Prozess in einem instabilen und unvorhersehbaren Zustand hinterlassen, was zu Beschädigungen und Blockaden führen kann. Weitere Informationen zu diesem Flag finden Sie unter IGlobalOptions.

Festlegen der Standardberechtigung für die COM-Zugriffsüberprüfung des Anforderers

Anforderer müssen beachten, dass eingehende Aufrufe von anderen VSS-Teilnehmern, z. B. Autoren oder VSS-Service, zugelassen werden müssen, wenn ihr Prozess als Server fungiert (z. B. mit Erlaubnis für Autoren, das Sicherungskomponentendokument zu ändern).

Standardmäßig lässt ein Windows-Prozess jedoch nur COM-Clients zu, die unter derselben Anmeldesitzung (SELF SID) oder unter dem lokalen Systemkonto ausgeführt werden. Dies stellt ein potenzielles Problem dar, da diese Standardwerte für die VSS-Infrastruktur nicht ausreichend sind. Autoren können beispielsweise als „Sicherungsoperator“-Benutzerkonto ausgeführt werden, das sich weder in derselben Anmeldesitzung wie der Anfordererprozess noch wie das lokale Systemkonto befindet.

Für den Umgang mit dieser Art von Problemen kann jeder CM-Server-Prozess weiter kontrollieren, ob ein RPC- oder COM-Client eine vom Server (in diesem Fall einem Anforderer) implementierte COM-Methode ausführen kann, indem CoInitializeSecurity zur Einrichtung einer prozessweiten „Standard-COM-Zugriffsprüfungsberechtigung“ verwendet wird.

Anforderer können explizit Folgendes tun:

  • Zulassen des Zugriffs für Aufrufe in den Aufruferprozess für alle Prozesse.

    Diese Option eignet sich möglicherweise für die überwiegende Mehrheit der Anforderer und wird von anderen COM-Servern verwendet – beispielsweise verwenden alle SVCHOST-basierten Windows-Services diese Option bereits, ebenso wie standardmäßig alle COM+-Services.

    Das Zulassen, dass alle Prozesse eingehende COM-Aufrufe durchführen, beeinträchtigt nicht notwendigerweise die Sicherheit. Ein Anforderer, der als COM_Server fungiert, behält wie alle anderen COM-Server immer die Möglichkeit, seine Clients für jede COM-Methode zu autorisieren, die in seinem Prozess implementiert ist.

    Beachten Sie, dass interne von VSS implementierte COM-Rückrufe standardmäßig gesichert sind.

    Um allen Prozessen den COM-Zugriff auf einen Anforderer zu ermöglichen, können Sie einen NULL-Sicherheitsdeskriptor als ersten Parameter von CoInitializeSecurity übergehen. (Beachten Sie, dass CoInitializeSecurity höchsten einmal für den gesamten Prozess aufgerufen werden muss.)

    Das folgende Codebeispiel zeigt, wie ein Anforderer CoInitializeSecurity unter Windows 8 und Windows Server 2012 und höher aufruft, um die Kompatibilität mit VSS für RVSS (Remote File Shares) sicherzustellen:

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

    Wenn Sie die COM-Sicherheitsstufe eines Antragstellers explizit mit CoInitializeSecurity festlegen, sollten Sie die folgenden Schritte ausführen:

    • Legen Sie die Authentifizierungsebene mindestens auf RPC_C_AUTHN_LEVEL_PKT_INTEGRITY fest. Um eine bessere Sicherheit zu gewährleisten, sollten Sie RPC_C_AUTHN_LEVEL_PKT_PRIVACY verwenden.
    • Legen Sie die Identitätswechselebene auf RPC_C_IMP_LEVEL_IMPERSONATE fest.
    • Legen Sie die Cloaking-Sicherheitsfunktionen auf EOAC_STATIC fest. Weitere Informationen zur Cloaking-Sicherheit finden Sie unter Cloaking.

    Das folgende Codebeispiel zeigt, wie ein Anforderer CoInitializeSecurity unter Windows 7 und Windows Server 2008 R2 und früher (oder unter Windows 8 und Windows Server 2012 und höher, wenn keine RVSS-Kompatibilität benötigt wird) aufrufen soll:

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

    Wenn Sie die COM-Sicherheitsstufe eines Antragstellers explizit mit CoInitializeSecurity festlegen, sollten Sie die folgenden Schritte ausführen:

    • Legen Sie die Authentifizierungsebene auf mindestens RPC_C_AUTHN_LEVEL_CONNECT fest. Um eine bessere Sicherheit zu gewährleisten, sollten Sie RPC_C_AUTHN_LEVEL_PKT_PRIVACY verwenden.
    • Legen Sie die Identitätswechselstufe auf RPC_C_IMP_LEVEL_IDENTIFY fest, es sei denn, der Anfordererprozess muss den Identitätswechsel für bestimmte RPC- oder COM-Aufrufe zulassen, die nicht mit VSS verbunden sind.

  • Festlegen, dass nur bestimmte Prozesse Zugriff zu Aufrufen für den Anfordererprozess erhalten.

    Ein COM-Server (z. B. ein Anforderer), der CoInitializeSecurity mit einem Nicht-NULL-Sicherheitsdeskriptor als erstem Parameter aufruft, kann den Deskriptor verwenden, um sich selbst so zu konfigurieren, dass er eingehende Aufrufe nur von Benutzern annimmt, die zu einem bestimmten Satz von Konten gehören.

    Ein Anforderer muss sicherstellen, dass COM-Clients, die unter gültigen Benutzern ausgeführt werden, berechtigt sind, Aufrufe für seinen Prozess durchzuführen. Ein Anforderer, der einen Sicherheitsdeskriptor im ersten Parameter angibt, muss es den folgenden Benutzern ermöglichen, eingehende Anrufe für den Anfordererprozess auszuführen:

    • Lokales System

    • Lokaler Dienst

      Windows XP: Dieser Wert wird erst unter Windows Server 2003 unterstützt.

    • Netzwerkdienst

      Windows XP: Dieser Wert wird erst unter Windows Server 2003 unterstützt.

    • Mitglieder der lokalen Administratorengruppe

    • Mitglieder der lokalen Sicherungsoperatorengruppe

    • Besondere Benutzer, die unten am Registrierungsspeicherort mit „1“ als REG_DWORD-Wert angegeben sind

Explizite Steuerung des Benutzerkontozugriffs für einen Anforderer

Es gibt Fälle, in denen das Einschränken des Zugriffs auf einen Anforderer für Prozesse, die als lokales System ausgeführt werden, bzw. unter den Gruppen lokale Administratoren oder lokale Sicherungsoperatoren zu restriktiv sein kann.

Beispielsweise muss ein angegebener Anfordererprozess möglicherweise nicht unter einem Administrator- oder Sicherungsoperator-Konto ausgeführt werden. Aus Sicherheitsgründen wäre es dann am besten, die Berechtigungen der Prozesse nicht künstlich zu erhöhen, um VSS zu unterstützen.

In solchen Fällen muss der Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl so geändert werden, dass VSS informiert wird, dass ein bestimmter Benutzer einen VSS-Anforderer ausführen darf.

Unter diesem Schlüssel müssen Sie einen Unterschlüssel erstellen, der denselben Namen wie das Konto hat, dem die Berechtigung gewährt oder verweigert werden soll. Dieser Unterschlüssel muss auf einen der Werte in der folgenden Tabelle festgelegt werden.

Wert Bedeutung
0 Verweigern des Zugriffs auf Ihren Autor und den Anforderer für den Benutzer.
1 Gewähren des Zugriffs auf Ihren Autor für den Benutzer.
2 Gewähren des Zugriffs auf Ihren Anforderer für den Benutzer.
3 Gewähren des Zugriffs auf Ihren Autor und den Anforderer für den Benutzer.

 

Im folgenden Beispiel wird der Zugriff auf das Konto „MyDomain\MyUser“ gewährt:

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

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

Dieser Mechanismus kann auch verwendet werden, um explizit einzuschränken, dass ein andernfalls zugelassener Benutzer einen VSS-Anforderer ausführt. Im folgenden Beispiel wird der Zugriff auf das Konto „ThatDomain\Administrator“ verweigert:

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

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

Der Benutzer ThatDomain\Administrator kann dann keinen VSS-Anforderer ausführen.

Durchführen einer Dateisicherung des Systemstatus

Wenn ein Anforderer eine Systemstatussicherung durchführt, indem einzelne Dateien gesichert werden, anstatt ein Datenträger-Image für die Sicherung zu verwenden, muss er die Funktionen FindFirstFileNameW und FindNextFileNameW aufrufen, um feste Verknüpfungen für Dateien aufzulisten, die sich in den folgenden Verzeichnissen befinden:

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

Auf diese Verzeichnisse kann nur von Mitgliedern der Gruppe „Administratoren“ zugegriffen werden. Aus diesem Grund muss ein solcher Antragsteller unter dem Systemkonto oder einem Benutzerkonto ausgeführt werden, das Mitglied der Gruppe „Administratoren“ ist.

Windows XP and Windows Server 2003: Die Funktionen FindFirstFileNameW und FindNextFileNameW werden erst ab Windows Vista und Windows Server 2008 unterstützt.