Sicherheitsanforderungen für die Ausführung von Office-Projektmappen (2003 System)

Aktualisiert: November 2007

Anpassungen auf Dokumentebene und Add-Ins auf Anwendungsebene enthalten die in .NET Framework verfügbaren Sicherheitsfeatures. Damit können für die Projektmappe Entscheidungen zur Vertrauenswürdigkeit anhand einer Reihe von Beweisen getroffen werden.

Zum Bereitstellen und Ausführen einer Microsoft Office-Projektmappe müssen Sie den Assemblys in der Sicherheitsrichtlinie jedes Endbenutzers volle Vertrauenswürdigkeit gewähren. Wenn sich bei Anpassungen das Dokument nicht auf dem Computer des Benutzers, sondern an einem Netzwerkspeicherort befindet, müssen Sie auch dem Dokument volle Vertrauenswürdigkeit gewähren. Weitere Informationen zum Festlegen der Sicherheitsrichtlinien auf Endbenutzercomputern finden Sie unter Bereitstellen der Sicherheitsrichtlinien.

In Microsoft Office-Projektmappen wird eine benutzerdefinierte Sicherheitseinschränkung hinzugefügt: Beweise vom Typ Gesamter Code oder zonenbasierte Beweise werden nicht akzeptiert. Das heißt, dass in Microsoft Office-Anwendungen keine Assemblys ausgeführt werden, die sich auf dem lokalen Computer, im Netzwerk oder im Internet befinden, solange der Assembly in der Sicherheitsrichtlinie keine Berechtigung (Vertrauenswürdigkeit) gewährt wurde.

Microsoft Office Outlook enthält einen Schutz für das Objektmodell, der den Zugriff von nicht vertrauenswürdigem Code auf das Outlook-Objektmodell verhindert. Durch diesen Objektmodellschutz können Endbenutzern in Outlook Warnungen angezeigt werden, wenn der Code ausgeführt wird. Informationen darüber, wie Sie diese Warnungen verhindern, finden Sie unter Überlegungen zur Sicherheit von Office-Projektmappen.

Vertrauensebenen

Sicherheit in .NET Framework umfasst die folgenden drei Vertrauensebenen:

• Voll vertrauenswürdig Mit dieser Ebene wird dem Code die Berechtigung zum Ausführen sämtlicher Aktionen gewährt, die auch vom Benutzer ausgeführt werden können. Dem gesamten Code muss volle Vertrauenswürdigkeit zugewiesen werden, damit er in Office-Projektmappen ausgeführt werden kann.

• Teilweise vertrauenswürdig Diese Ebene ist ein eingeschränkter Berechtigungssatz, mit dem nur bestimmte Berechtigungen gewährt werden. Teilweise vertrauenswürdiger Code kann in Office-Projektmappen nicht ausgeführt werden.

• Nicht vertrauenswürdig Mit dieser Ebene werden keine Berechtigungen gewährt, daher wird der Code nicht ausgeführt.

Als Berechtigungssatz muss die volle Vertrauenswürdigkeit festgelegt sein, In Office-Projektmappen werden keine verwalteten Codeerweiterungen ausgeführt, die teilweise oder nicht vertrauenswürdig sind. Weitere Informationen zu Berechtigungssätzen finden Sie unter Benannte Berechtigungssätze.

Beweisarten

Sicherheit in .NET Framework umfasst folgende Beweisarten:

• Gesamter Code

• Anwendungsverzeichnis

• Globaler Assemblycache (GAC)

• Hash

• Herausgeber

• Site

• Starker Name

• URL

• Zone

• Benutzerdefiniert (msosec.dll für Office-Projektmappen. Weitere Informationen finden Sie unter Gewusst wie: Gewähren von Berechtigungen für Dokumente und Arbeitsmappen an freigegebenen Speicherorten (2003 System).)

Weitere Informationen hierzu finden Sie unter Beweise.

Wenn Sie ein Projekt erstellen, wird diesem von Visual Studio mithilfe des Beweistyps URL volle Vertrauenswürdigkeit gewährt. Beim Erstellen eines Visual Studio Tools for Office-Projekts in Visual Studio wird die Sicherheitsrichtlinie auf der Benutzerebene so geändert, dass den Erstellungsspeicherorten für Office-Projekte volle Vertrauenswürdigkeit gewährt wird. Beim Ausführen der Anpassung oder des Add-Ins übermittelt das Ladeprogramm die URL des Assemblyspeicherorts an das Richtliniensystem, das den betreffenden Speicherorten volle Vertrauenswürdigkeit gewährt.

Diese Sicherheitsebene reicht im Allgemeinen aus, wenn Sie mit Ihrem eigenen Computer arbeiten, kann jedoch zu einem Sicherheitsproblem werden, wenn Sie die Projektmappe bereitstellen. Ehe Sie die Assembly bereitstellen, sollte sie eine stärkere Form von Beweisen erhalten. Eine stärkere Beweisform sollte aus zwei Gründen verwendet werden:

• Wenn Sie einem Speicherort im Web volle Vertrauenswürdigkeit gewähren, können bösartige Benutzer mit Schreibzugriff auf den betreffenden Speicherort die Assembly durch eigenen Code ersetzen und ahnungslose Benutzer dazu verleiten, diesen auszuführen.

• Die Standardrichtlinie auf Computerebene gewährt allen Websites teilweise Vertrauenswürdigkeit. Da jedoch volle Vertrauenswürdigkeit erforderlich ist, ist es nicht ausreichend, anhand einer Richtlinie auf Benutzerebene festzulegen, dass einer URL vollständige Vertrauenswürdigkeit gewährt wird.

Wenn Sie sich für die Verwendung von URL-Beweisen entscheiden, müssen Sie die Richtlinie im Intranetzonenbereich auf der Ebene der Computerrichtlinien und nicht auf der Ebene der Benutzerrichtlinien festlegen. Gewähren Sie darüber hinaus die vollständige Vertrauenswürdigkeit nur für die Speicherorte, von denen Sie wissen, dass nur vertrauenswürdige Personen dafür über Schreibzugriff verfügen. Eine bessere Richtlinie besteht darin, eine Kombination von Speicherortbeweisen und starken kryptografischen Beweisen zu verwenden, beispielsweise einen starken Namen. Starke Namen müssen immer in Verbindung mit Speicherortinformationen verwendet werden, sodass auf eine Anwendung mit einem starken Namen, für die ein Sicherheitsrisiko besteht, gefahrlos ein Patch angewendet werden kann.

Bei Anwendungen auf Dokumentebene verfügt das Dokument außerdem über speicherortbasierte Beweise. Dies erschwert es bösartigen Benutzern, vertrauenswürdigen Code anhand neu erstellter Dokumente zu missbrauchen, mit denen der Code zu unerwünschten Zwecken verwendet wird. Wenn ein Dokument mit verwalteten Codeerweiterungen sich nicht in einem voll vertrauenswürdigen Speicherort befindet, führt es die Assembly nicht aus. In der Standardeinstellung wird der Arbeitsplatzzone volle Vertrauenswürdigkeit gewährt, sodass der Code von Dokumenten auf dem Computer des Benutzers ausgeführt werden kann. Der Internetzone wird jedoch keine volle Vertrauenswürdigkeit gewährt.

Bei Dokumenten mit verwalteten Codeerweiterungen wird keine Office-Makrosicherheit verwendet. Diese stützt sich auf den Zertifikatsspeicher von Office. Makrosicherheit steht in keinem Zusammenhang mit Assemblysicherheit.

Informationen über die Sicherheit in .NET Framework finden Sie unter Grundlagen der Codezugriffssicherheit oder, etwas allgemeiner gefasst, unter Sicherheit in .NET Framework sowie unter Übersicht über die Verwaltung der Sicherheitsrichtlinien.

Übersicht über die Assemblysicherheit

Übersicht über die Dokumentsicherheit

Sicherheit auf dem Entwicklungscomputer

Wenn Sie als Entwickler in Visual Studio ein neues Office-Projekt erstellen, wird standardmäßig in der .NET Framework-Sicherheitsrichtlinie auf Benutzerebene der vollständige Pfad der Assembly (einschließlich des Assemblynamens) hinzugefügt. Der Assembly wird daher die volle Vertrauenswürdigkeit gewährt. Assemblys, auf die verwiesen wird und die sich im Ausgabeordner des Projekts befinden, erhalten beim Erstellen des Projekts ebenfalls volle Vertrauenswürdigkeit.

Wenn die Standardeinstellung nicht geändert wird, überprüft Visual Studio Tools for Office die Sicherheitsrichtlinie im Cache bei jeder Erstellung der Projektmappe. Falls die Assemblys nicht über die volle Vertrauenswürdigkeit verfügen, gewährt Visual Studio Tools for Office die volle Vertrauenswürdigkeit. Auf diese Weise kann das Projekt seine Vertrauenswürdigkeit auch dann behalten, wenn die Assembly umbenannt wird oder das Projekt an einen neuen Speicherort verschoben wird.

Wenn Sie die Standardeinstellung für die Vertrauenswürdigkeit ändern (also die Vertrauenswürdiger Assemblyspeicherort-Eigenschaft auf false setzen), wird den Assemblys von Visual Studio keine volle Vertrauenswürdigkeit gewährt, und der Code wird nicht ausgeführt. Um den Code erneut auszuführen, ändern Sie die Vertrauenswürdiger Assemblyspeicherort-Eigenschaft in true und erstellen die Projektmappe neu. Sie können auch eine globale Regel festlegen, durch die sämtlichem Code, der im Projektordner und den entsprechenden Unterverzeichnissen ausgeführt wird, volle Vertrauenswürdigkeit gewährt werden kann.

Informationen dazu, wie Sie Vertrauenswürdigkeitsoptionen für Projekte festlegen und Ordnern volle Vertrauenswürdigkeit gewähren, finden Sie unter Gewusst wie: Gewähren von Berechtigungen für Ordner und Assemblys (2003 System).

Zwischenspeichern von Sicherheitsrichtlinien

Die Sicherheitsrichtlinie wird für jeden Prozess von der Common Language Runtime im Cache zwischengespeichert. Dieser Cache wird beim Erstellen von Projekten von Visual Studio auf die volle Vertrauenswürdigkeit der Assemblys hin überprüft. Wenn die Assemblys beim Starten von Visual Studio bereits über volle Vertrauenswürdigkeit verfügen, werden von Visual Studio für diese Assemblys während des Buildvorgangs keine Richtlinien erstellt.

Wenn Sie während der Ausführung von Visual Studio Sicherheitsrichtlinien für das Projekt ändern, werden diese Änderungen von Visual Studio nicht erkannt. Wenn die vorgenommenen Änderungen zur Folge haben, dass das Projekt nicht ausgeführt werden kann, wird von der Anwendung eine Sicherheitsausnahme ausgelöst, da von Visual Studio nicht erneut Richtlinien erstellt werden, die den Assemblys volle Vertrauenswürdigkeit gewähren. Sie müssen Visual Studio schließen und erneut öffnen, damit Änderungen an den Sicherheitsrichtlinien erkannt werden können.

Projektmappen, die mit der vorherigen Version erstellt wurden

Jeder Version von Microsoft .NET Framework, die auf Ihrem Computer installiert ist, ist eine Sicherheitsrichtlinie zugeordnet. Visual Studio Tools for Office-Projektmappen überprüfen die Sicherheitsrichtlinie der .NET Framework-Version, für die sie erstellt wurden. Wenn Sie also eine Projektmappe mithilfe von Visual Studio-Tools für Office, Version 2003 erstellen, wird von dieser stets die Sicherheitsrichtlinie für .NET Framework Version 1.1 überprüft. Wenn Sie eine Projektmappe mithilfe von Visual Studio 2005-Tools für Office erstellen, wird von dieser stets die Sicherheitsrichtlinie für .NET Framework Version 2.0 überprüft.

Visual Studio Tools für Office System 3.0-Projektmappen nehmen eine Überprüfung auf .NET Framework Version 3.5 vor, Projektmappen für Office 2003 können jedoch so festgelegt werden, dass sie .NET Framework 2.0 verwenden. Weitere Informationen finden Sie unter Gewusst wie: Ändern der .NET Framework-Zielversion. 

Im Netzwerk erstellte Projekte

Obwohl Sie ein Projekt an einem freigegebenen Netzwerkspeicherort erstellen können, ist es nicht möglich, dieses Projekt über das Netzwerk auszuführen, solange Sie ihm nicht volle Vertrauenswürdigkeit auf Computerebene gewähren. Standardmäßig wird von Visual Studio Tools for Office auf Benutzerebene ein URL-Beweis erteilt. Sie müssen der Assembly manuell volle Vertrauenswürdigkeit auf Computerebene gewähren.

Wenn Sie einem Speicherort im Netzwerk nur mit URL-Beweisen vollständige Vertrauenswürdigkeit gewähren, können bösartige Benutzer mit Schreibzugriff auf den betreffenden Speicherort die Assembly durch eigenen Code ersetzen und ahnungslose Benutzer dazu verleiten, diesen auszuführen. Ziehen Sie andere Beweisformen in Betracht, die Sie anstelle von bzw. zusätzlich zu URL-Beweisen verwenden können. Weitere Informationen finden Sie unter Beweisarten in diesem Thema.

Sicherheit für Endbenutzer

Endbenutzer öffnen Dokumente mit verwalteten Codeerweiterungen so wie jedes andere Dokument. Wenn sich das Dokument auf dem Computer des Endbenutzers befindet oder dem Dokument in einer Netzwerkfreigabe Vertrauenswürdigkeit gewährt wurde, wird von Word oder Excel versucht, die Assembly zu laden und auszuführen. Add-Ins werden geladen, wenn die Microsoft Office-Anwendung vom Benutzer gestartet wird.

Die Microsoft Office-Anwendung überprüft die Sicherheitsrichtlinie und führt eine der folgenden Aktionen aus:

• Wenn der Assembly und (sofern zutreffend) dem Dokument ausdrücklich die entsprechenden Berechtigungen gewährt wurden, darf die Assembly ausgeführt werden. Weitere Informationen zum Festlegen der Sicherheitsrichtlinien auf Endbenutzercomputern finden Sie unter Bereitstellen der Sicherheitsrichtlinien.

• Wenn die einzigen zur Ermittlung von Berechtigungen vorliegenden Beweise auf dem gesamten Code oder auf der Zone basieren, wird der Code nicht ausgeführt. Der Endbenutzer erhält dann eine Fehlermeldung mit der Erklärung, dass der Code aufgrund der aktuellen Sicherheitsrichtlinien nicht ausgeführt werden kann. Der Benutzer sollte sich an einen Administrator wenden. Der Administrator kann durch ein Ändern der Sicherheitsrichtlinien die Ausführung des Codes ermöglichen.

Die standardmäßige Visual Studio Tools for Office-Sicherheitsrichtlinie lässt das Ausführen von Code in Anpassungen nicht zu. Standardmäßig behandeln die Sicherheitsrichtlinien die Arbeitsplatz-Zone als vertrauenswürdig. Die Anwendungsdomänenrichtlinien für Dokumente mit verwalteten Codeerweiterungen erlauben die Ausführung von Code in dieser Zone jedoch erst dann, wenn dem Code explizit Vertrauenswürdigkeit gewährt wurde. Dies entspricht nicht den herkömmlichen Erfahrungen der Entwickler und Endbenutzer, macht den Desktop bei Standardeinstellungen jedoch sicherer. Darüber hinaus können die Endbenutzer die Sicherheitseinstellungen in Office nicht so ändern, dass nicht vertrauenswürdiger Code ausgeführt werden darf. Nur explizite Änderungen in den .NET-Sicherheitsrichtlinien ermöglichen die Ausführung von verwalteten Codeerweiterungen.

Gewähren der Vertrauenswürdigkeit für Office-Dokumente

In den meisten Situationen wird das Office-Dokument in der Arbeitsplatz-Zone ausgeführt, und es ist keine Aktion erforderlich, um das Öffnen des Dokuments wie erwartet zu ermöglichen. Der Assembly jedoch muss nach wie vor volle Vertrauenswürdigkeit gewährt werden, damit die Anwendung ausgeführt wird. Wenn ein Dokument als E-Mail-Anlage empfangen wird, muss es an einem anderen Speicherort auf dem Computer (z. B. auf dem Desktop des Benutzers) gespeichert werden, damit die Projektmappe ausgeführt wird. Dies gilt auch dann, wenn das Dokument auf eine vertrauenswürdige Assembly zeigt. Der Grund dafür ist, dass sich Anlagen in der Internetzone befinden, die keine volle Vertrauenswürdigkeit besitzt.

Wenn sich das Dokument im Netzwerk befindet, muss der Administrator auch Berechtigungen für das Dokument erteilen. Bei unveränderlichen Dokumenten wie Vorlagen kann der Administrator das Dokument auf der Grundlage seines vollständigen Pfades (URL) als vertrauenswürdig behandeln. In allgemeineren Fällen, in denen viele Benutzer beliebige Inhalte hochladen dürfen (z. B. eine SharePoint-Liste), wird der Administrator u. U. nur die Office-Dokumente als vertrauenswürdig behandeln, die in dem freigegebenen Verzeichnis gespeichert sind. Weitere Informationen hierzu finden Sie unter Gewusst wie: Gewähren von Berechtigungen für Dokumente und Arbeitsmappen an freigegebenen Speicherorten (2003 System).

Entziehen der Vertrauenswürdigkeit von Assemblys

Wenn der Administrator ein Sicherheitsproblem im Unternehmen feststellt, kann er den gesamten verwalteten Code vorübergehend deaktivieren, indem er Richtlinien anwendet, die die Ausführung von Code grundsätzlich nicht zulassen. Werden Teile von verwaltetem Code benötigt, kann der Administrator die Richtlinien weiter ändern, sodass nur der erforderliche Code ausgeführt wird. Dazu muss er eine eindeutige Eigenschaft des betreffenden Codes wählen (z. B. Speicherort, starker Name oder Signatur) und die notwendigen Berechtigungen erteilen. Verwalteter Code lässt sich problemlos wieder aktivieren, indem die Richtlinien nach der Beseitigung des Sicherheitsproblems einfach auf ihre vorherigen Einstellungen zurückgesetzt werden. Weitere Informationen hierzu finden Sie unter Gewusst wie: Entfernen von Berechtigungen für Ordner und Assemblys (2003 System).

Siehe auch

Konzepte

Sichere Bereitstellung (2003 System)

Empfohlene Vorgehensweisen für die Sicherheit in Office-Projektmappen (2003 System)

Überlegungen zur Sicherheit von Office-Projektmappen

Sichern von Anwendungen

Weitere Ressourcen

Sicherheit in Office-Projektmappen (2003 System)