Sichere Bereitstellung (2003 System)
Aktualisiert: November 2007
Betrifft |
|---|
Die Informationen in diesem Thema gelten nur für die angegebenen Visual Studio Tools for Office-Projekte und Versionen von Microsoft Office. Projekttyp
Microsoft Office-Version
Weitere Informationen hierzu finden Sie unter Verfügbare Features nach Anwendung und Projekttyp. |
Beim Erstellen einer Visual Studio Tools for Office-Projektmappe werden die lokalen Sicherheitsrichtlinien automatisch aktualisiert, damit der Projektcode ausgeführt werden kann. Beim Bereitstellen der Projektmappe hingegen müssen Sie die Sicherheitsrichtlinien explizit auf jedem Computer aktualisieren, auf dem die Projektmappe verwendet wird, damit der Assemblycode auf das Office-Objektmodell zugreifen und es ausführen darf.
Wenn Sie für Anpassungen auf Dokumentebene das Dokument an einem Netzwerkspeicherort bereitstellen, müssen Sie außerdem die Sicherheitsrichtlinie für das Dokument aktualisieren. Weitere Informationen zum Festlegen der Sicherheitsrichtlinien auf Endbenutzercomputern finden Sie unter Bereitstellen der Sicherheitsrichtlinien. Weitere Informationen zu Anpassungen auf Dokumentebene finden Sie unter Architektur von Anpassungen auf Dokumentebene.
Starke Namen und Zertifikate
Für die sichere Bereitstellung von Projektmappen empfiehlt es sich, Ihren Assemblys einen starken Namen zuzuweisen oder sie mit einem Authenticode-Zertifikat (x.509) zu signieren. Um die Sicherheit zu erhöhen und die Verwaltung zu erleichtern, sollten Sie am besten beides durchführen. Starke Namen und Authenticode-Signaturen bieten ein hohes Maß an Sicherheit, denn Ihr Code lässt sich von einem Dritten nur sehr schwer ändern, ohne dass dabei der starke Name oder die Signatur ungültig wird. Authenticode-Signaturen haben weitere Vorzüge:
Sie können mit einem Timestamp versehen werden.
Die Zertifikate können aufgehoben werden.
Das Zertifikat gibt Auskunft über die Identität des Herausgebers.
Weitere Informationen über Assemblys mit starkem Namen finden Sie unter Assemblys mit starkem Namen und Erstellen und Verwenden von Assemblys mit starkem Namen.
Weitere Informationen über Authenticode-Signaturen finden Sie unter Bereitstellung und Authenticode-Signatur.
Auswählen der Sicherheitsebene
Sie müssen die Vorteile strengerer Regeln (höhere Sicherheit) und weniger strenger Regeln (einfachere Verwaltung) gegeneinander abwägen und sich für eine angemessene Vertrauensebene entscheiden. Wenn die Projektmappe beispielsweise immer auf einem Server mit dem Namen \\appserver\ bereitgestellt und mit dem Unternehmenszertifikat signiert werden soll, sollten Sie eine Regel wählen, die nur das Unternehmenszertifikat auf \\appserver\ als vertrauenswürdig behandelt. Damit erhalten Sie Unterstützung für den Schutz vor bösartigen Benutzern, die sich das Zertifikat unrechtmäßig beschaffen und den Code im Internet veröffentlichen könnten (der Code ist nur dann vertrauenswürdig, wenn er von \\appserver\ stammt). Dies bedeutet auch, dass Sie beim zukünftigen Speichern von Assemblys auf einem anderen Server die Sicherheitsrichtlinie erneut aktualisieren müssen.
Wenn Sie sich nicht sicher sind, an welchen Stellen die Projektmappen bereitgestellt werden, ist es ein vernünftiger Kompromiss, das Zertifikat oder den starken Namen vom lokalen Computer und lokalen Intranet als vertrauenswürdig zu behandeln. Wenn Sie den Code über das Web verteilen möchten, können Sie in den Sicherheitsoptionen von Internet Explorer auch die Zone Vertrauenswürdige Sites verwenden. Sie sollten dem Zertifikat der Zone Internet, der Zone Eingeschränkte Sites oder auf der obersten Ebene (gesamter Code) nur dann vertrauen, wenn ein hinreichender Grund dafür spricht. Sorgen Sie in diesem Fall mit den entsprechenden Vorsichtsmaßnahmen dafür, dass der Code sicher ist, selbst wenn er in die Hände böswilliger Benutzer gelangt. Weitere Informationen hierzu finden Sie unter Codezugriffssicherheit.
Informationen über mögliche Risiken finden Sie unter Überlegungen zur Sicherheit von Office-Projektmappen.
Gewähren von Zugriff auf die Assembly
Eine Möglichkeit zum Bereitstellen von Anpassungen auf Dokumentebene besteht darin, das Dokument für jeden Benutzer lokal und die Assembly an einem Netzwerkspeicherort bereitzustellen. Auf ähnliche Weise können Sie bei Add-Ins auf Anwendungsebene die Add-In-Assembly an einem Netzwerkspeicherort bereitstellen. Die Assembly wird erst dann in einer Office-Projektmappe ausgeführt, wenn diese vertrauenswürdig ist. Versehen Sie die Assembly mit einer digitalen Signatur, und gewähren Sie nur Systemadministratoren (und allen Personen, die Änderungen an der Assembly vornehmen müssen) Schreibzugriff auf den Speicherort. Weitere Informationen über das Absichern von Assemblys vor der Bereitstellung finden Sie unter Überlegungen zur Assemblysicherheit.
Mit dem Microsoft .NET Framework 2.0-Konfigurationstool oder dem Sicherheitsrichtlinientool für den Codezugriff (Caspol.exe) können Sie Unternehmensrichtlinien festlegen, die der Assembly Vertrauenswürdigkeit gewähren.
Weitere Informationen zum .NET Framework-Konfigurationstool finden Sie unter .NET Framework-Konfigurationstool (Mscorcfg.msc). Weitere Informationen zu Caspol.exe finden Sie unter Sicherheitsrichtlinientool für den Codezugriff (Caspol.exe) und unter Konfigurieren der Sicherheitsrichtlinien mit dem Sicherheitsrichtlinientool für den Codezugriff (Caspol.exe).
Ehe Sie eine Assembly an ihrem endgültigen Speicherort bereitstellen (oder eine bereitgestellte Assembly aktualisieren), sollten Sie Ihre Sicherheitsrichtlinien prüfen und festlegen, mit welcher Art von Beweisen Sie sich vor Sicherheitsrisiken schützen können. Weitere Informationen hierzu finden Sie unter Sicherheitsanforderungen für die Ausführung von Office-Projektmappen (2003 System).
Sichern von Dokumenten im Netzwerk
Wenn sich bei Anpassungen auf Dokumentebene ein Dokument auf einem Server oder in einer Netzwerkfreigabe befindet, muss der URL des Dokuments volle Vertrauenswürdigkeit gewährt werden. Das funktioniert am besten mit Vorlagen oder einzelnen Dokumenten, die nur von vertrauenswürdigen Benutzern geändert werden dürfen. Sie sollten sicherstellen, dass Benutzer ohne Vertrauenswürdigkeit keine Berechtigung haben, das Dokument in der Netzwerkfreigabe zu ändern oder zu ersetzen.
Wenn ein Administrator den Benutzern den Zugriff auf Dokumente ermöglichen möchte, die in einem öffentlichen freigegebenen Verzeichnis wie einem SharePoint Portal gespeichert sind, muss er eine neue Codegruppe für die Dokumente in die Richtlinien aufnehmen. Die Codegruppe wird von der Mitgliedschaftsbedingung ausgenommen, mit der nach Office-Dokumenten als Beweisen gesucht wird, und erlaubt es den Administratoren, entsprechende Entscheidungen zur Vertrauenswürdigkeit zu treffen (genauso wie Administratoren eine Codegruppe hinzufügen müssen, um einer Assembly explizit Vertrauenswürdigkeit zu gewähren). Weitere Informationen hierzu finden Sie unter Gewusst wie: Gewähren von Berechtigungen für Dokumente und Arbeitsmappen an freigegebenen Speicherorten (2003 System).
E-Mail-Verteilung
Bei Anpassungen auf Dokumentebene wird eine Assembly standardmäßig nicht ausgeführt, wenn das Dokument direkt aus einer E-Mail-Nachricht heraus geöffnet wird. Das Dokument kann jedoch auf der lokalen Festplatte gespeichert und dann wie üblich geöffnet werden. Wenn das Dokument in seinem Anwendungsmanifest den vollständigen Pfad zu einer Assembly mit voller Vertrauenswürdigkeit enthält, wird die Projektmappe ausgeführt.
Es ist möglich, wenn auch nicht empfehlenswert, Dokumenten aus dem temporären Ordner von Outlook das Hosten von Code zu gestatten. Dies stellt ein geringes bis mittleres Sicherheitsrisiko dar, da eine vorhandene Sicherheitslücke in einer bereitgestellten Assembly, der volle Vertrauenswürdigkeit gewährt wurde, von einem böswilligen Benutzer ausgenutzt werden könnte. Dieser könnte an eine E-Mail-Nachricht ein Dokument anhängen, das auf die Assembly zeigt, und den Empfänger zum Öffnen dieser Nachricht ermutigen. Im Erfolgsfall könnte der Angreifer mit den Anmeldeinformationen des Empfängers zum Beispiel auf eine sichere Intranetsite zugreifen. Beachten Sie, dass der Assembly dennoch explizit volle Vertrauenswürdigkeit gewährt werden müsste. Ein Angreifer könnte nicht ein Dokument und eine Assembly seiner Wahl erstellen und den Benutzer zur Ausführung verleiten.
Ändern von Sicherheitsrichtlinien
Wenn der Administrator die Berechtigungen für ein Dokument oder eine Assembly ändert, müssen die Benutzer alle Office-Anwendungen beenden und dann neu starten, damit die Änderungen wirksam werden.
Manchmal wird der Prozess der Office-Anwendung weiter ausgeführt, nachdem der Benutzer die Anwendung beendet hat. Unter diesen Umständen werden die geänderten Sicherheitsrichtlinien nicht wirksam. Stellen Sie im Task-Manager sicher, dass die Office-Anwendung nicht in der Liste der aktiven Prozesse aufgeführt ist.
Andere Anwendungen, die als Host für Office-Anwendungen dienen, können ebenfalls verhindern, dass die neuen Berechtigungen wirksam werden. Beim Ändern der Sicherheitsrichtlinien müssen alle Anwendungen (einschließlich Internet Explorer), die Office als Host oder eigenständig verwenden, vom Benutzer beendet werden.
Verhindern der Codeausführung durch Anpassungen auf Dokumentebene
Administratoren können mithilfe der Registrierung verhindern, dass Anpassungen auf Dokumentebene auf einem Computer ausgeführt werden. Wenn ein Word-Dokument oder eine Excel-Arbeitsmappe mit verwalteten Codeerweiterungen geöffnet wird, überprüft die Visual Studio Tools for Office-Laufzeit, ob unter einem der folgenden Registrierungsschlüssel auf dem Computer ein Eintrag mit dem Namen Disabled vorhanden ist:
HKEY_CURRENT_USER\Software\Microsoft\VSTO
HKEY_LOCAL_MACHINE\Software\Microsoft\VSTO
Um Anpassungen auf Dokumentebene am Ausführen von Code zu hindern, erstellen Sie unter einem der Registrierungsschlüssel oder unter beiden Schlüsseln einen Disabled-Eintrag, und geben Sie für Disabled einen der folgenden Datentypen und Werte an:
REG_SZ oder REG_EXPAND_SZ, wobei als Zeichenfolge ein anderer Wert als "0" (Null) angegeben ist.
REG_DWORD mit einem anderen Wert als 0 (Null).
Wenn Anpassungen auf Dokumentebene deaktiviert sind, können Benutzer Dokumente weiterhin öffnen und Änderungen an diesen vornehmen, der Code in der Assembly wird jedoch nicht mehr ausgeführt. Um die Codeausführung für Anpassungen auf Dokumentebene zu aktivieren, legen Sie beide Disabled-Einträge auf 0 fest, oder löschen Sie die Registrierungseinträge.
Siehe auch
Aufgaben
Gewusst wie: Bereitstellen von Office-Projektmappen (2003 System)
Gewusst wie: Entfernen verwalteter Codeerweiterungen aus Dokumenten (2003 System)
Gewusst wie: Bereitstellen für die Offlineverwendung von Dokumenten (2003 System)
Konzepte
Bereitstellungsmodelle (2003 System)
Bereitstellen von Anpassungen auf Dokumentebene (2003 System)
Bereitstellen von Office-Projektmappen (2003 System)
Bereitstellen von Add-Ins auf Anwendungsebene (2003 System)