In diesem Artikel stellen Dominick Baier und Keith Brown dar, wie Berechtigungserweiterungen in ClickOnce funktionieren, das Standardverhalten geändert wird und sich ClickOnce-Anwendungen sicher bereitstellen lassen. (11 gedruckte Seiten).

Auf dieser Seite

 Einführung
 Probleme bei NTD (No-Touch Deployment)
 Vorteile von ClickOnce
 Der ClickOnce-Loader
 Vertrauenswürdige Anwendungen
 Vertrauenswürdige Herausgeber
 Ändern der TrustManager-Konfiguration
 Tool-Unterstützung
 Schlussbemerkung
 Die Autoren

Einführung

Mit Microsoft .NET 2.0 wird eine neue Bereitstellungstechnologie für Software namens ClickOnce eingeführt. ClickOnce vereinfacht unter anderem die Bereitstellung von Windows Forms-Anwendungen über zentrale Netzwerkspeicherorte. Ein wesentliches Merkmal des ClickOnce-Konzepts besteht darin, dass Benutzer entscheiden können, ob sie Code, der nicht vom lokalen Computer stammt, als vertrauenswürdig einschätzen und ausführen. Auf diese Weise werden zwar viele Praxis-Probleme der in .NET 1.1 enthaltenen "No Touch Deployment" Technologie gelöst, aber damit auch die Standard-Sicherheit in einer Weise gelockert, die für die meisten (Firmen) Umgebungen nicht akzeptabel ist. In diesem Artikel wird erläutert, wie Berechtigungserweiterungen in ClickOnce funktionieren, das Standardverhalten geändert werden kann und ClickOnce-Anwendungen sicher bereitgestellt werden.

 Zum Seitenanfang

Probleme bei NTD (No-Touch Deployment)

In Microsoft .NET 1.x ist eine Technologie enthalten, die im Allgemeinen als "NTD" oder "No-Touch Deployment" bezeichnet wird. Mit dieser Technologie kann eine EXE-Datei über eine Dateifreigabe oder den Browser ausgeführt werden. Bei Verwendung eines Browsers werden die Datei und zugehörige Abhängigkeiten heruntergeladen und auf Grundlage des Ursprungs (Intranet/Internet) in einer geschützten Umgebung ("Sandbox") ausgeführt. In der Praxis ergeben sich hierbei jedoch einige Probleme. Erstens weist die Standardsicherheitsrichtlinie für mobilen Code für die meisten Anwendungen zu starke Einschränkungen auf, um sinnvoll arbeiten zu können. Zweitens können Richtlinien nur geändert werden, indem ein Administrator für jeden Client Änderungen an den Einstellungen vornimmt. Die Details dieser Einstellungen sind in häufig verwendeten Technologien zur Netzwerkverwaltung wie Active Directory-Gruppenrichtlinien nicht zufrieden stellend integriert, was die Situation nicht gerade verbessert. Oft führt dies zu Anwendungen mit Installationsanweisungen der Art: "Führen Sie zunächst die folgenden zwölf einfachen Schritte aus (für die selbstverständlich Administratorrechte erforderlich sind), dann können Sie für diese Anwendung eine "No Touch"-Bereitstellung durchführen".

Selbst wenn ein Mechanismus zur Richtlinienbereitstellung vorhanden ist, ist es oft nicht leicht, eine Grundlage für diese Richtlinien zu ermitteln. Anwendungen bestehen gewöhnlich aus mehreren Komponenten, von denen einige unter Umständen sogar von Drittanbietern stammen. Das Ermitteln der für diese Komponenten erforderlichen Berechtigungen ist keine leichte Aufgabe, und je komplexer das Problem ist, desto schwieriger ist die Erstellung der Richtlinie. Wenn Sie Richtlinien auf der Grundlage von URL-Beweisen erstellen, müssen Sie der DNS-Infrastruktur uneingeschränkt vertrauen, und es gibt keine Möglichkeit, zu ermitteln, ob auf dem Server Binärdateien durch bösartigen Code ersetzt wurden. Starke Namen werden gewöhnlich nur für selbst geschriebenen Code verwendet, und es ist keine Infrastruktur zum Sperren von Schlüsseln vorhanden, für den Fall, dass Schlüssel manipuliert werden oder verloren gehen. Darüber hinaus führen starke Namen zu zusätzlichen geheimen Projektinformationen, die vom Entwicklungsteam vertraulich behandelt werden müssen.

Weitere Probleme mit 1.1 href-EXE-Dateien:

• Keine Unterstützung von Konfigurationsdateien

• Keine intuitive Offline-Unterstützung

• Keine optimale Geschwindigkeit beim Startvorgang

• Keine Benutzeroberfläche beim Starten/Aktualisieren von Anwendungen

 Zum Seitenanfang

Vorteile von ClickOnce

ClickOnce ist eine neue Bereitstellungstechnologie in .NET 2.0, die zur Lösung dieser Probleme entwickelt wurde. Die wichtigsten Entwurfsziele von ClickOnce sind:

• Problemlose Installationen über Netzwerkfreigaben, URLs und CDs.

• Shell-Integration. Beispielsweise können Anwendungen nach der ersten Installation über das Startmenü gestartet werden (sogar im Offline-Betrieb).

• Automatische Aktualisierungen und Patches.

• Höhere Benutzerfreundlichkeit durch eine standardisierte Benutzeroberfläche.

Das wichtigste neue Feature ist jedoch die Möglichkeit für den Endbenutzer, die Berechtigungen der Anwendung ohne Eingriffe eines Administrators zu erhöhen, falls die Standardrichtlinie zu restriktiv ist.

ClickOnce-Anwendungen werden nicht über die EXE-Datei gestartet. Stattdessen wurde die neue Dateierweiterung ".application" eingeführt (siehe Beispiel 1 für eine APPLICATION-Beispieldatei). Hierbei handelt es sich um eine Datei im XML-Format, durch die die Anforderungen einer Anwendung auf hoher Ebene und deren Version beschrieben wird. Diese Informationen werden mit einer digitalen W3C-XML-Standardsignatur versehen, um die Dateien vor Manipulation zu schützen und authentifizierbar zu machen (das <signature>-Element).

Beispiel 1: APPLICATION-Beispieldatei ( .application -Datei)

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly>
  <assemblyIdentity name="ExpenseApp.application" version="1.1.0.1" 
    publicKeyToken="8fd41ed2607f2ab2" language="neutral" 
    processorArchitecture="msil" 
    xmlns="urn:schemas-microsoft-com:asm.v1" />
  <description asmv2:publisher="Dominick Baier"   
    asmv2:product="MyExpenseApp" 
    xmlns="urn:schemas-microsoft-com:asm.v1" />
  <deployment install="false" mapFileExtensions="true" />
  <dependency>
    <dependentAssembly dependencyType="install" 
      allowDelayedBinding="true" 
      codebase="ExpenseApp_1_1_0_1\ExpenseApp.exe.manifest" 
      size="10503">
      <assemblyIdentity name="ExpenseApp.exe" 
        version="1.1.0.1" 
        publicKeyToken="8f..b2" 
        language="neutral" 
        processorArchitecture="msil" 
        type="win32" />
        <hash>
          <dsig:Transforms>
            <dsig:Transform 
              Algorithm="..." />
          </dsig:Transforms>
            <dsig:DigestMethod Algorithm="..." />
            <dsig:DigestValue>X1...w=</dsig:DigestValue>
        </hash>
      </dependentAssembly>
    </dependency>
  <Signature>...</Signature>
</asmv1:assembly>

Die APPLICATION-Datei enthält außerdem eine Verknüpfung mit der Anwendungsmanifestdatei. Im Manifest werden der Einstiegspunkt der Anwendung, die Abhängigkeiten (z. B. abhängige DLLs und Datendateien) sowie die für die Ausführung erforderlichen Berechtigungen beschrieben. In Beispiel 2 wird eine Manifestdatei für eine einfache Anwendung dargestellt, die aus einer ausführbaren Hauptdatei, einer referenzierten DLL und einer Anwendungsdatendatei namens data.xml besteht.

Beispiel 2: MANIFEST-Beispieldatei

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0">
  <asmv1:assemblyIdentity 
    name="ExpenseApp.exe" 
    version="1.1.0.1" 
    publicKeyToken="8fd41ed2607f2ab2" 
    language="neutral" 
    processorArchitecture="msil" 
    type="win32" />
  <application />
  <entryPoint>
    <assemblyIdentity 
      name="ExpenseApp" 
      version="1.0.0.0" 
      language="neutral" 
      processorArchitecture="msil" />
     <commandLine file="ExpenseApp.exe" parameters="" />
  </entryPoint>
  <trustInfo>
    <security>
      <applicationRequestMinimum>
        <PermissionSet 
           class="System.Security.PermissionSet" 
           version="1" 
           ID="Custom" 
           SameSite="site">
          <IPermission  
             class="System.Security.Permissions.EnvironmentPermission, ..." 
             version="1" 
             Read="USERNAME" />
          <IPermission  
             class="System.Security.Permissions.FileDialogPermission, ..." 
             version="1" 
             Unrestricted="true" />
          <IPermission 
      class="System.Security.Permissions.IsolatedStorageFilePermission, ..." 
            version="1" 
            Allowed="AssemblyIsolationByUser" 
            UserQuota="9223372036854775807" 
            Expiry="9223372036854775807" 
            Permanent="True" />
          <IPermission 
            class="System.Security.Permissions.ReflectionPermission, ... " 
            version="1" 
            Flags="ReflectionEmit" />
          <IPermission  
            class="System.Security.Permissions.SecurityPermission, ..." 
            version="1" 
            Flags="Assertion, Execution, BindingRedirects" />
          <IPermission 
            class="System.Security.Permissions.UIPermission, ... " 
            version="1" 
            Unrestricted="true" />
          <IPermission 
            class="System.Net.DnsPermission, ... " 
            version="1" 
            Unrestricted="true" />
          <IPermission 
            class="System.Windows.Forms.WebBrowserPermission, ... " 
            version="1" 
            Unrestricted="True" />
       <IPermission class="System.Drawing.Printing.PrintingPermission, ... " 
            version="1" 
            Level="DefaultPrinting" />
        </PermissionSet>
        <defaultAssemblyRequest permissionSetReference="Custom" />
      </applicationRequestMinimum>
    </security>
  </trustInfo>
  <dependency>
    <dependentOS>
      <osVersionInfo>
        <os majorVersion="4" 
          minorVersion="10" 
          buildNumber="0" 
          servicePackMajor="0" />
      </osVersionInfo>
    </dependentOS>
  </dependency>
  <dependency>
    <dependentAssembly 
      dependencyType="preRequisite" 
      allowDelayedBinding="true">
      <assemblyIdentity 
        name="Microsoft.Windows.CommonLanguageRuntime" 
        version="2.0.50215.44" />
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly 
      dependencyType="install" 
      allowDelayedBinding="true" 
      codebase="BusinessLogic.dll" size="16384">
      <assemblyIdentity name="BusinessLogic" version="1.0.0.0" 
        language="neutral" 
        processorArchitecture="msil" />
      <hash>
        <dsig:Transforms>
          <dsig:Transform Algorithm="..." />
        </dsig:Transforms>
        <dsig:DigestMethod Algorithm="..." />
        <dsig:DigestValue>PU72aPMmuikoi5y3h+clRcgov9I=</dsig:DigestValue>
      </hash>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly 
      dependencyType="install" 
      allowDelayedBinding="true" 
      codebase="ExpenseApp.exe" 
      size="16384">
      <assemblyIdentity 
        name="ExpenseApp" 
        version="1.0.0.0" 
        language="neutral" 
        processorArchitecture="msil" />
      <hash>
        <dsig:Transforms>
          <dsig:Transform Algorithm="..." />
        </dsig:Transforms>
        <dsig:DigestMethod Algorithm="..." />
        <dsig:DigestValue>m0spIP4iplyZh0tW/IrWisuaO5Y=</dsig:DigestValue>
      </hash>
    </dependentAssembly>
  </dependency>
  <file name="Data.xml" size="62" writeableType="applicationData">
    <hash>
      <dsig:Transforms>
        <dsig:Transform Algorithm="..." />
      </dsig:Transforms>
      <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
      <dsig:DigestValue>Viie3RrQpo/AJEFBpqbkxtmpVKE=</dsig:DigestValue>
    </hash>
  </file>
<Signature>...</Signature>
</asmv1:assembly>

Jede auf dem Computer installierte ClickOnce-Anwendung verfügt über ein eigenes Datenverzeichnis, das im persönlichen Ordner Dokumente und Einstellungen gespeichert wird. Jede in einer ClickOnce-Anwendung enthaltene und als "Data" gekennzeichnete Datei wird bei der Installation der Anwendung in dieses Verzeichnis kopiert.

Das <trustInfo>-Element enthält die CAS-Berechtigungen, die für die Ausführung der Anwendung erforderlich sind. (In diesem Beispiel sind das die Berechtigungen für das lokale Intranet.) ClickOnce-Anwendungen werden nach dem Start mit genau diesen Berechtigungen in einer Sandbox ausgeführt. Die digitale Signatur in der APPLICATION-Datei schließt auch den Hashwert der Manifestdatei ein und schützt auf diese Weise die Berechtigungen. In Abbildung 1 wird in einer Übersicht dargestellt, wie diese Dateien miteinander verknüpft sind.

Abbildung 1: Beziehungen zwischen Manifesten und Dateien. Klicken Sie auf die Abbildung für eine Größere Darstellung.

Wie sie sehen, sind die wichtigsten konzeptionellen Neuerungen, dass Sicherheits- und Bereitstellungsanforderungen durch die Anwendungen beschrieben werden, und dass der Benutzer über die Vertrauenswürdigkeit der Anwendungen entscheidet. Das heißt, dass Vertrauenswürdigkeit nicht auf einzelnen Komponenten der Anwendung basiert, sondern auf der Anwendung selbst. Auf diese Weise wird die Arbeit erheblich erleichtert.

 Zum Seitenanfang

Der ClickOnce-Loader

Die Erweiterung ".application" ist dem ClickOnce-Ladeprogramm dfsvc.exe zugeordnet. Wenn Sie also auf eine APPLICATION-Datei doppelklicken oder für diese auf einer Web-Seite einen Link erstellen, wird das ClickOnce-Ladeprogramm gestartet, das die Manifestdatei an die CLR übergibt. Die AppDomainSetup Klasse in .NET 2.0 beinhaltet für diesen Zweck eine neue Eigenschaft namens ActivationArguments, das auf eine ".application" Datei verweisen kann.

Jeder Benutzer verfügt über eine Liste vertrauenswürdiger Anwendungen. (ATL – Application Trust List). Diese Liste wird im .NET Framework-Konfigurations-Snap-In im Abschnitt "Benutzer" der Laufzeitsicherheitsrichtlinie angezeigt. Die ATL speichert die Anwendungs-ID und den URL von Anwendungen, die vom Benutzer als vetrauenswürdig eingestuft wurden. Das heißt, wenn Sie z. B. ExpenseApp auf ihrem lokalen Anwendungsserver vertrauen, wird derselben Anwendung von einem Server namens HackShack.com keine Vertrauenswürdigkeit gewährt. Wenn die Anwendung in der ATL aufgeführt ist, wird in einer Sandbox eine Anwendungsdomäne erstellt (mit den im Manifest angegebenen Berechtigungen), und der Haupteinstiegspunkt der Anwendung wird ausgeführt. Diese Anwendungsdomäne wird in einer ausführbaren Datei namens AppLaunch.exe gehostet (Ausnahmen sind hier Anwendungen, die Full Trust erfordern, diese werden direkt gestartet).

Wenn die Anwendung nicht in der Vertrauenswürdigkeitsliste enthalten ist, wird der TrustManager aufgerufen. TrustManager ist eine Klasse, durch die die Vertrauenswürdigkeit einer Anwendung festgestellt wird. Dies beinhaltet sämtliche Interaktionen über die Benutzeroberfläche sowie ein Standardverhalten, welches über die Registrierung konfiguriert werden kann (dazu später mehr).

Der TrustManager, der sich in der System.Security.Policy.ApplicationTrust-Klasse befindet, überprüft zunächst, ob das Anwendungsmanifest von einem vertrauenswürdigen Herausgeber signiert ist. In diesem Fall wird die Anwendung – wiederum direkt, oder mithilfe von AppLaunch.exe - sofort ausgeführt. Wenn der Herausgeber nicht vertrauenswürdig ist, werden die erforderlichen Berechtigungen im Manifest ausgewertet und mit den Standard-CAS-Richtlinien für die Herkunftszone verglichen. Wenn die angeforderten Berechtigungen der Anwendung die Standard-CAS Richtlinienberechtigungen nicht überschreiten, wird die Anwendung ohne weitere Bestätigung durch den Benutzer ausgeführt.

Wenn für die Anwendung mehr Berechtigungen erforderlich sind, als die durch die Standardrichtlinie gewährten, wird der Benutzer gefragt, ob der Anwendung vertraut und die Berechtigungsebene erhöht werden soll (Abbildung 2). Wenn der Benutzer auf Ausführen klickt, wird die Anwendung in die ATL aufgenommen, bei Bedarf heruntergeladen und gestartet.

Abbildung 2: Dialogfeld "Berechtigungserweiterung"

Beachten Sie, dass die Anwendung nur bei Bedarf und nach Treffen aller Entscheidungen über die Vertrauenswürdigkeit heruntergeladen wird. In Abbildung 3 wird ein Diagramm zu diesen Entscheidungen während des Ladevorgangs dargestellt.

Abbildung 3: ClickOnce-Ladevorgang

Sie haben richtig gelesen, die Entscheidung über die Vertrauenswürdigkeit einer Anwendung wird vom Benutzer getroffen. Dies gilt auch für Anwendungen aus der Internetzone. Im Folgenden wird der Begriff der vertrauenswürdigen Anwendung definiert und erläutert wie das Standardverhalten von TrustManager geändert werden kann.

 Zum Seitenanfang

Vertrauenswürdige Anwendungen

In Unternehmensszenarien ist es meist nicht erwünscht, dass Benutzer Entscheidungen über die Vertrauenswürdigkeit selbst treffen können, bzw. mit Vertrauensdialogen konfrontiert werden. Wenn TrustManager einer Anwendung Vertrauenswürdigkeit gewährt, wird das Dialogfeld Berechtigungserweiterung nicht angezeigt. Dies ist auch bei der ersten Installation der Anwendung der Fall. Weiterhin kann die Vertrauensfrage und Berechtigungserweiterung für alle anderen Anwendungen deaktiviert werden.

In ClickOnce (mit der standardmäßigen TrustManager-Klasse) wird die initiale Vertrauenwürdigkeit einer Anwendung durch das Zertifikat, mit dem das Manifest signiert ist, festgestellt.

 Zum Seitenanfang

Vertrauenswürdige Herausgeber

Wie bereits erwähnt, enthalten APPLICATION- und MANIFEST-Dateien eine digitale Signatur. Manifeste können mit einem Authenticode-Zertifikat signiert werden (dies ist ein Zertifikat, das einen "Code-Signature" Intended Purpose hat). Wenn der Client dem Zertifikat vertraut (d.h. das Zertifikat ist gültig und befindet sich im "Vertrauenswürdige Herausgeber"-Ordner), bewertet TrustManager die Anwendung als vertrauenswürdig und führt diese direkt aus, ohne den Benutzer zu einer Berechtigungserweiterung aufzufordern.

Es gibt drei Möglichkeiten, ein Code-Signierungszertifikat zu erhalten:

1. Erstellen Sie ein selbstsigniertes Zertifikat mithilfe von makecert.exe oder Visual Studio.

2. Kaufen Sie ein Zertifikat (beispielsweise von VeriSign).

3. Erstellen Sie ein Zertifikat mithilfe eines Windows-Zertifikatservers.

Die erste Möglichkeit bietet einen einfachen Weg, mit der Technologie zu experimentieren, ist jedoch nur zu internen Testzwecken oder für Demoversionen sinnvoll. Die zweite Möglichkeit wird üblicherweise von unabhängigen Softwareanbietern (ISVs – Independent Software Vendors) genutzt, die Code anderen Organisationen oder Privatbenutzern zur Verfügung stellen möchten.

Die dritte Möglichkeit ist sinnvoll für Code, der nur im eigenen Unternehmen verwendet wird. Im Folgenden werden die Schritte erläutert, die dafür erforderlich sind.

Jede Windows Server 2003 Enterprise Edition-Zertifizierungsstelle (CA – Certificate Authority) stellt einen Satz von Zertifikatvorlagen bereit (der vom Snap-In certtmpl.msc verwaltet wird). Durch diese Vorlagen werden die Einstellungen von Zertifikaten konfiguriert, die ausgestellt werden können. Für Code-Signierung ist bereits eine vorinstallierte Vorlage vorhanden. Diese Vorlage ist für einen Zeitraum von einem Jahr gültig. Wenn Sie die Vorlage ändern möchten (wird nur unter Windows 2003 Enterprise Edition unterstützt), rufen Sie Vorlage kopieren auf, geben Sie der Vorlage einen neuen Namen, und ändern Sie deren Einstellungen. In jedem Fall müssen Sie die Sicherheitseinstellungen ändern. Gewähren Sie den Benutzern, die zum Anfordern des Zertifikats berechtigt sein sollen, Enroll-Zugriff.

Wechseln Sie anschließend zur Konsole der CA, und navigieren Sie zum Ordner Zertifikatvorlagen. Klicken Sie auf Neu -> Auszustellende Zertifikatvorlage, und wählen Sie die Code-Signierungsvorlage aus. Nun können Sie diesen Zertifikattyp bei der CA-Web-Schnittstelle oder dem MMC-Snap-In Zertifikate auf dem Client anfordern.

Nachdem Sie das Zertifikat angefordert haben, signieren Sie mit diesem Zertifikat das ClickOnce-Manifest (weitere Informationen finden Sie im Abschnitt Tool-Unterstützung.) Für die Stamm-CA und das Code-Signierungszertifikat muss auf dem Client Vertrauenswürdigkeit gewährt werden. Das heißt, Sie müssen diese Zertifikate im Zertifikatspeicher des Clients in die Ordner Vertrauenswürdige Stammzertifizierungsstelle und Vertrauenswürdige Herausgeber importieren.

Selbstverständlich stellt der private Schlüssel für dieses Zertifikat eine neue und sehr wichtige Information dar, die im Unternehmen vertraulich behandelt und gesichert werden muss.

In größeren Netzwerken ist es nicht sinnvoll, die Zertifikate auf jeder Clientarbeitsstation manuell zu installieren. Wenn Sie in einer Active Directory-Domäne arbeiten, gibt es eine einfache Lösung. Sie können AD-Gruppenrichtlinienobjekte (GPOs – Group Policy Objects) verwenden, um Zertifikate zentral zu verteilen.

Fügen Sie für das Stamm-CA-Zertifikat eine GPO zu AD hinzu, und erstellen Sie auf der entsprechenden Ebene eine Verknüpfung (gewöhnlich auf Domänenebene). Wechseln Sie zu Computereinstellungen -> Windows-Einstellungen -> Sicherheit -> Richtlinien öffentlicher Schlüssel. Fügen Sie das Stamm-CA-Zertifikat unter Vertrauenswürdige Stammzertifizierungsstellen hinzu.

Die Verteilung durch einen vertrauenswürdigen Herausgeber kann auf die gleiche Weise durchgeführt werden. Fügen Sie eine GPO zu AD hinzu, und erstellen Sie auf der entsprechenden Ebene eine Verknüpfung (gewöhnlich für die Organisationseinheit, die der Anwendung Vertrauenswürdigkeit gewähren soll). Wechseln Sie zu Benutzereinstellungen -> Windows-Einstellungen -> Internet Explorer-Wartung -> Sicherheit -> Authenticode-Einstellungen. Klicken Sie auf Importieren and anschließend auf Ändern. Wenn Sie verhindern möchten, dass Benutzer den vertrauenswürdigen Herausgeberzertifikatsspeicher selbst ändern, sollten Sie vertrauenswürdige Herausgeber sperren.

Nachdem die normale GPO-Replikation für Clients durchgeführt wurde, vertraut jeder Client der CA und dem vertrauenswürdigen Herausgeberzertifikat. Benutzer sollten für Anwendungen, die mit Unternehmenszertifikaten signiert sind, keine Fragen zur Vertrauenswürdigkeit beantworten müssen.

 Zum Seitenanfang

Ändern der TrustManager-Konfiguration

Bisher haben wir lediglich den Berechtigungsdialog für vertrauenswürdige Anwendungen unterdrückt. Der nächste Schritt besteht üblicherweiseder darin, die Ausführung nicht vertrauenswürdiger Anwendungen zu verhindern. Mit nicht vertrauenswürdigen Anwendungen sind Anwendungen gemeint, die nicht von einem vertrauenswürdigen Herausgeber stammen.

Durch TrustManager wird festgelegt, ob eine Anwendung automatisch ausgeführt wird oder Benutzer zum Gewähren der Vertrauenswürdigkeit für eine Anwendung aufgefordert werden. Das Verhalten von TrustManager kann mithilfe der Windows-Registrierung konfiguriert werden. Aus praktischen Gründen wird die Konfiguration – im Gegensatz zu XML-Dateien wie der "klassischen" Datei EnterpriseTrust.config – in der Registrierung vorgenommen. Auf diese Weise können GPOs problemlos auf die Konfiguration zugreifen, um TrustManager zentral für Unternehmensnetzwerke zu konfigurieren.

Durch den Registrierungsschlüssel HKLM\Software\Microsoft\.NETFramework\Security\TrustManager\PromptingLevel wird gesteuert, bei welchen Anwendugen ClickOnce die Berechtigungserweiterung erlaubt (der Registrierungsschlüssel ist standardmässig nicht vorhanden und muss erstellt werden). Innerhalb des Schlüssels können Sie Zeichenfolgen für Zonen hinzufügen, z. B. LocalIntranet, Internet usw. Zulässige Werte sind Enabled (Berechtigungserweiterung ist immer erlaubt), Disabled (Berechtigungserweiterung ist generell deaktiviert, und die Anwendung wird nur mit erweiterten Rechten ausgeführt, wenn sie von einem vertrauten Herausgeber stammt) und AuthenticodeRequired (Berechtigungen können nur von Anwendungen mit einem gültigen Zertifikat erweitert werden, was aber nicht zwingend ein vertrauenswürdiger Herausgeber sein muss). In der folgenden Tabelle sind die Standardwerte für jede Zone aufgeführt:

Insbesondere die Tatsache, dass auch aus dem Internet stammende Anwendungen standardmässig ihre Berechtigungen erweitern können, sollte zu Überlegungen führen, wie Sie ihre Arbeitsstationen im Netzwerk "vorkonfigureren" wollen.

Indem Sie diese Werte ändern, können Sie ClickOnce sperren, sodass nur vertrauenswürdige Anwendungen Berechtigungen erweitern können. Dies gilt auch für die Intranetzone. Um diese Einstellungen mit einem GPO in der Domäne zu verteilen, müssen Sie eine administrative Vorlage erstellen, die in den Gruppenrichtlinien-Editor integriert werden kann. Beispiel 3 zeigt eine Vorlagendatei.

Beispiel 3: Administrative Vorlage für TrustManager

CLASS MACHINE

CATEGORY ClickOnce

   POLICY "MyComputer"
   KEYNAME "Software\Microsoft\.NETFramework\Security\TrustManager\PromptingLevel"
      PART "Choose Prompting Level" DROPDOWNLIST REQUIRED
      VALUENAME MyComputer
         ITEMLIST
           NAME "Enabled" VALUE "Enabled" DEFAULT
           NAME "Authenticode Required" VALUE "AuthenticodeRequired"
           NAME "Disabled" VALUE "Disabled"
         END ITEMLIST
      END PART
   END POLICY

   POLICY "LocalIntranet"
   KEYNAME "Software\Microsoft\.NETFramework\Security\TrustManager\PromptingLevel"
      PART "Choose Prompting Level" DROPDOWNLIST REQUIRED
      VALUENAME LocalIntranet
         ITEMLIST
           NAME "Enabled" VALUE "Enabled" DEFAULT
           NAME "Authenticode Required" VALUE "AuthenticodeRequired"
           NAME "Disabled" VALUE "Disabled"
         END ITEMLIST
      END PART
   END POLICY

   POLICY "Internet"
   KEYNAME "Software\Microsoft\.NETFramework\Security\TrustManager\PromptingLevel"
      PART "Choose Prompting Level" DROPDOWNLIST REQUIRED
      VALUENAME Internet
         ITEMLIST
           NAME "Enabled" VALUE "Enabled" 
           NAME "Authenticode Required" VALUE "AuthenticodeRequired" DEFAULT
           NAME "Disabled" VALUE "Disabled"
         END ITEMLIST
      END PART
   END POLICY

   POLICY "TrustedSites"
   KEYNAME "Software\Microsoft\.NETFramework\Security\TrustManager\PromptingLevel"
      PART "Choose Prompting Level" DROPDOWNLIST REQUIRED
      VALUENAME TrustedSites
         ITEMLIST
           NAME "Enabled" VALUE "Enabled" DEFAULT
           NAME "Authenticode Required" VALUE "AuthenticodeRequired"
           NAME "Disabled" VALUE "Disabled"
         END ITEMLIST
      END PART
   END POLICY

   POLICY "UntrustedSites"
   KEYNAME "Software\Microsoft\.NETFramework\Security\TrustManager\PromptingLevel"
      PART "Choose Prompting Level" DROPDOWNLIST REQUIRED
      VALUENAME UntrustedSites
         ITEMLIST
           NAME "Enabled" VALUE "Enabled" 
           NAME "Authenticode Required" VALUE "AuthenticodeRequired"
           NAME "Disabled" VALUE "Disabled" DEFAULT
         END ITEMLIST
      END PART
   END POLICY
END CATEGORY

Kopieren Sie den Inhalt in eine Textdatei mit der Erweiterung ".adm" (z. B. TrustManager.adm), und kopieren Sie die Datei auf den Domäne-Controller, auf dem sie die GPO hinzufügen möchten, in das Verzeichnis \Windows\Inf. Wechseln Sie im Gruppenrichtlinien-Editor zu Computereinstellungen -> Administrative Vorlagen. Klicken Sie mit der rechten Maustaste, und wählen Sie Administrative Vorlage hinzufügen/entfernen aus. Wählen Sie anschließend die Datei TrustManager.adm aus. Wechseln Sie zu Ansicht -> Filtern, und deaktivieren Sie Nur vollständig verwaltbare Richtlinieneinstellungen anzeigen, um die Vorlage anzuzeigen (Abbildung 4). Nun können Sie die TrustManager-Einstellungen im Unternehmensnetzwerk verteilen.

Abbildung 4: ClickOnce-Einstellungen im Gruppenrichtlinien-Editor.

 Zum Seitenanfang

Tool-Unterstützung

Die APPLICATION- und MANIFEST-Dateien sind ziemlich kompliziert. Selbstverständlich müssen Sie diese XML-Dateien nicht vollständig von Hand schreiben. Visual Studio 2005 unterstützt das Schreiben teilweise vertrauenswürdiger Anwendungen und deren anschließende Bereitstellung mit ClickOnce.

Zum Aktivieren von ClickOnce für eine Windows Forms-Anwendung wechseln Sie als erstes in Visual Studio zu den Projekteigenschaften und aktivieren das Projekt für ClickOnce und teilweise Vertrauenswürdigkeit. Anschließend wählen Sie die gewünschte Zone aus, in der die Anwendung ausgeführt wird, also Intranet oder Internet. Sie können außerdem die Berechtigungen bearbeiten, die zum manuellen Ausführen der Anwendung erforderlich sind. Beispiel: Sie beginnen mit Intranetberechtigungen und fügen dann eine FileIOPermission hinzu. Dies hat Auswirkungen auf die Berechtigungen, die Visual Studio in die Manifestdatei einfügt. Ein neues Feature in .NET 2.0 ist die Möglichkeit, durch Visual Studio zu ermitteln, welche Berechtigungen zum Auführen der Anwendung erforderlich sind (dies ist oft sehr ungenau, kann aber trotzdem hiflreich sein). Klicken Sie hierzu einfach auf die Schaltfläche Berechtigungen berechnen (Abbildung 5).

Abbildung 5: ClickOnce-Einstellungen in Visual Studio. Klicken Sie auf die Abbildung für eine Größere Darstellung.

Auf der Registerkarte Signierung können Sie das Code-Signierungszertifikat auswählen, mit dem das Manifest signiert wird. Sie können aus einem lokalen Zertifikatsspeicher auswählen oder eine PFX-Datei benutzen. Wenn Sie kein Code-Signierungszertifikat auswählen, erstellt Visual Studio ein selbstsigniertes Zertifikat (Abbildung 6).

Abbildung 6: Signieren eines ClickOnce-Manifests mit Visual Studio . Klicken Sie auf die Abbildung für eine Größere Darstellung.

Abschließend können Sie über die Registerkarte Veröffentlichen alle Binär- und Manifestdateien an einen Speicherort Ihrer Wahl publizieren. Wenn Sie einen Web-Speicherort auswählen, erstellt Visual Studio automatisch eine Skelett-Web-Seite mit dem Namen publish.htm.

Wenn Visual Studio 2005 nicht installiert ist (beispielsweise in einer Staging-Umgebung), oder wenn Sie den Prozess automatisieren möchten, wird mit dem .NET Framework SDK ein Tool namens mage.exe bereitgestellt, das über dieselben Funktionen verfügt.

 Zum Seitenanfang

Schlussbemerkung

Eine zentralisierte Bereitstellung von Windows Forms-Anwendungen ist in modernen Unternehmen eine nicht seltene Anforderung. Der .NET 1.1 href-EXE-Ansatz hat sich hierfür in den meisten Szenarios als ungeeignet erwiesen. Die standardmäßige Sicherheits-Sandbox verfügt für die meisten Anwendungen über zu hohe Einschränkungen, und die Richtlinienbereitstellung kann sehr kompliziert werden.

Mit ClickOnce wird dieses Problem durch Anwendungsrichtlinien sowie dem Erhöhen von Berechtigungen durch den Endbenutzer vereinfacht. Dadurch wird allerdings die Sicherheit stark gelockert, z.B. indem auch Anwendungen aus dem Internet ihre Berechtigungen standardmäßig erweitern dürfen. Dies ist in den meisten Fällen nicht erwünscht. Für Szenarien, in denen die Benutzer keine Entscheidungen hinsichtlich der Vertrauenswürdigkeit treffen sollen, können Sie das Verhalten anpassen, indem Sie die Anwendungsmanifeste signieren und TrustManager konfigurieren. Die gesamten Einstellungen können nun mithilfe von Active Directory-Gruppenrichtlinien zentral verwaltet werden. Durch diese kombinierten Features wird "No Touch-Bereitstellung" in Zukunft praktikabler sein.

 Zum Seitenanfang

Die Autoren

Dominick Baier leitet die Sicherheitsschulungen bei DevelopMentor. Dazu zählt auch die Leitung und Entwicklung von Kursen zur Sicherheit von .NET, ASP.NET, WinFX und "Vista". Dominick Baier hat einen Abschluss in Informatik, ist zertifizierter BS7799/ISO17799-Auditor und hält auf vielen Konferenzen Vorträge über Anwendungssicherheit. Die übrige Zeit verbringt er mit Forschungen auf dem Gebiet der Anwendungssicherheit, der Durchführung von Penetration- und Sicherheitstests und mit der Unterstützung von Entwicklern auf der ganzen Welt beim Erstellen sichererer Anwendungen. Dominick ist Microsoft MVP in der Kategorie "Visual Developer – Security".

Eine Reihe von Sicherheitsressourcen sowie Vorlesungsmitschriften, Tools und Code-Beispiele finden Sie in Dominicks Weblog unter http://www.leastprivilege.com/.

Keith Brown ist Mitgründer von Pluralsight, einem führenden Unternehmen für Entwicklerschulungen, wo er als Spezialist Sicherheitsfragen tätig ist. Keith Brown schreibt Artikel für die Kolumne "Security Briefs" des MSDN Magazine und ist Autor der Bücher The .NET Developer's Guide to Windows Security (Addison Wesley, 2004) und Programming Windows Security (Addison Wesley, 2000). Keith hält außerdem Vorlesungen auf vielen Konferenzen, einschließlich TechEd und WinDev. Weitere Informationen finden Sie in seinem Weblog unter www.pluralsight.com/keith.

 Zum Seitenanfang