Windows-Verwaltung

Der ActiveX-Installationsdienst in Windows Vista

Rob Campbell and Joel Yoker

Kurz zusammengefasst:

• Häufige Herausforderungen bei ActiveX-Steuerelementen
• Installation von ActiveX-Steuerelementen
• Gefährliche Berechtigungen
• Ein sichererer Prozess in Windows Vista

Es ist immer dasselbe: Um die Sicherheit wesentlich zu erhöhen, müssen Sie ein gewisses Maß an Freiheit oder Flexibilität aufgeben. Wenn Ihre Umgebung den meisten anderen Organisationen gleicht, werden Sie Ihr Desktopbetriebssystem bestimmt so absichern wollen, dass eine sicherere Computerumgebung

für Ihre Endbenutzer bereitgestellt wird. IT-Administratoren gehen bei der Sicherung des Desktops üblicherweise so vor, dass sie eine Kombination aus Sicherheitsrichtlinieneinstellungen, Benutzerberechtigungen, Datei- und Registrierungs-Zugriffssteuerungslisten (Access Control Lists, ACLs) sowie Systemdiensteinschränkungen verwenden.

Eine häufig auftretende Hürde bei der Entwicklung einer sicheren Desktopumgebung ist die Begrenzung der Bedrohungen durch schädliche ActiveX®-Steuerelemente bei gleichzeitiger Bereitstellung einer nach wie vor angemessenen Anwendungskompatibilität in Ihrer Umgebung. Bei Desktopbetriebssystemen war dies jahrelang eine Herausforderung. Glücklicherweise geht der neue Installationsdienst für ActiveX-Steuerelemente (AxIS) in Windows Vista™ die für die Verwaltung von ActiveX-Steuerelementen in Unternehmensumgebungen spezifischen Probleme an. AxIS bietet Standardbenutzern, die normalerweise für die Installation von ActiveX-Steuerelementen nicht berechtigt sind, eine einfache und überschaubare Möglichkeit, diese von genehmigten Websites zu installieren. Gruppenrichtliniensteuerung über AxIS ermöglicht IT-Administratoren zu bestimmen, welche Steuerelemente Benutzer unabhängig von ihren Berechtigungen installieren dürfen.

In diesem Artikel werden die administrativen Herausforderungen im Zusammenhang mit ActiveX-Steuerelementen behandelt, die Art und Weise, wie diese Probleme in früheren Versionen von Windows® behandelt wurden, und wie AxIS in Windows Vista eine einmalige und effiziente Möglichkeit bietet, die Installation von ActiveX-Steuerelementen zu verwalten.

Was ist ein ActiveX-Steuerelement?

Ein ActiveX-Steuerelement ist ein Stück ausführbaren Codes (in der Regel eine OCX-Datei, die in einer CAB-Datei verpackt ist), das installiert und durch den Benutzer über Internet Explorer® aufgerufen wird. Webentwickler erstellen ActiveX-Steuerelemente, um ihren Webanwendungen Funktionen hinzuzufügen, die sie mit Standard-HTML oder einem einfachen Skript nur schwer erzielen können.

Ein Schlüsselfeature von ActiveX-Steuerelementen ist das einfache Bereitstellungskonzept in Form von „Downloaden und ausführen“. ActiveX-Steuerelemente werden über das HTML-Objekttag installiert und aufgerufen, das ein Attribut namens CODEBASE hat. Dieses Attribut gibt Internet Explorer (mithilfe einer URL) an, wo das Steuerelement abzurufen ist, wenn es nicht bereits auf dem Computer des Benutzers installiert ist. In diesem Fall lädt Internet Explorer das entsprechende Installationspaket herunter, führt eine Vertrauensüberprüfung am Objekt durch und fordert den Benutzer zur Eingabe der Installationsgenehmigung über die Internet Explorer-Informationsleiste auf (siehe Abbildung 1). Während der Installation wird das Steuerelement durch die Ausgabeseite registriert und aufgerufen. Nach der Installation können alle Standardbenutzer das Steuerelement aufrufen. Dieser einfache Verteilungs- und Ausführungsmechanismus soll Entwicklern eine leichte Möglichkeit bieten, Komponenten an Benutzer ihrer Webanwendung zu verteilen. Das Problem bei dieser Verteilungsmethode ist, dass Standardbenutzer ActiveX-Steuerelemente nicht direkt installieren können, weil zur Durchführung der Installation Administratorrechte erforderlich sind.

Abbildung 1** Installationsinformationsleiste des ActiveX-Steuerelements **

Als ActiveX-Steuerelemente erstmals in Internet Explorer 4.0 eingeführt wurden, schien das Internet noch ein viel freundlicherer Ort zu sein. Heute kann ausführbarer Code, der über das Web verteilt wird, eine erhebliche Bedrohung darstellen. Deshalb dürfen in Windows ausschließlich Benutzer mit lokalen Administratorrechten ActiveX-Steuerelemente installieren, und auch nur dann, wenn die Installation gemäß Richtlinieneinstellungen genehmigt ist. Wenn ein ActiveX-Steuerelement erst einmal von einem Administrator installiert ist, kann es von jedem Benutzer des Systems aufgerufen werden. Dieses Verhalten wird durch einen Satz von Datei- und Registrierungs-ACLs in Windows ermöglicht. Dies hindert Standardbenutzer zwar daran, ActiveX-Steuerelemente zu installieren, verringert aber nicht die Risiken für lokale Administratoren und Standardbenutzer (mit geänderten Standardberechtigungen), die sie installieren.

Der Standardschutz in Windows, nämlich dass nur Personen mit Administratorrechten eine Installation durchführen können, berücksichtigt also ActiveX-Steuerelemente auf der Ebene des einzelnen Benutzers. Die Verwaltung von ActiveX-Steuerelementen innerhalb großer Organisationen wird allerdings nicht behandelt. Eine häufige Herausforderung in Unternehmensumgebungen ist die Frage, wie die Verwendung der von der IT-Organisation als vertrauenswürdig anerkannten ActiveX-Steuerelemente zugelassen werden kann, gleichzeitig aber potenzielle Bedrohungen reduziert werden, die von externen, nicht vertrauenswürdigen Steuerelementen ausgehen. Letztendlich wird die Entscheidung, ob ein bestimmtes ActiveX-Steuerelement installiert wird, sei es gut oder bösartig, oft einem einzelnen Benutzer je nach dessen Rechten überlassen. Um Bedrohungen entgegenzuwirken, sperren manche Organisationen alle ActiveX-Steuerelemente, während andere die Installation durch Endbenutzer zulassen, jedoch versuchen, womöglich installierte Malware abzuwehren.

Eine andere Möglichkeit, die Installation schädlicher Steuerelemente zu verhindern, besteht darin, beim Standardbenutzer eingeschränkte Rechte zu erzwingen und den IT-Administrator alle erforderlichen Steuerelemente auf der Desktopplattform vorinstallieren zu lassen. Dies ist effektiv, wenn die verwendeten ActiveX-Steuerelemente entweder von verhältnismäßig statischer Natur sind, wenn sie gemäß einem geplanten Veröffentlichungsprozess in Verbindung mit Desktopupdates geändert werden, oder wenn die Organisation einen Softwareverteilungsmechanismus wie Systems Management Server verwendet. Allerdings stellen bei diesen Vorgehensweisen die alltägliche Verwaltung, die sich ständig ändernden Anforderungen interner Anwendungsentwickler sowie Abhängigkeiten von externen Steuerelementen weiterhin eine Herausforderung dar.

Wenn Benutzer Administratorrechte haben, sieht das Problem anders aus, da diese Benutzer dann an der Installation nicht genehmigter Steuerelemente gehindert werden müssen. In diesem Fall wird das Recht des Endbenutzers vorausgesetzt, ActiveX-Steuerelemente zu installieren, da er über Administratorrechte verfügt. (Beachten Sie, dass eine Konstellation, in der Endbenutzer als lokale Administratoren fungieren, für die Organisation ein hohes Risiko darstellt und für die meisten Unternehmensumgebungen nicht empfohlen wird.)

Eine Lösung besteht in der Einrichtung eines internen Downloadservers für Internetkomponenten, der die genehmigten Steuerelemente hostet. Diese Lösung erfordert die Änderung der CodeBaseSearchPath-Zeichenfolge in der Registrierung des Clients. Wenn in der angeforderten HTML-Seite ein Objekttag gefunden wird, das das Attribut CODEBASE enthält, werden die Windows-Clients normalerweise zu den Orten geleitet, die in den CodeBaseSearchPath-Daten angegeben sind. Standardmäßig enthält diese Registrierungszeichenfolge das CODEBASE-Schlüsselwort und Internet-URLs für die ActiveX-Steuerelementsammlung. Um einen Downloadserver für Internetkomponenten zu implementieren, müssen Sie die Standarddaten im CodeBaseSearchPath durch die URL des internen Servers ersetzen, auf dem Sie die von Ihrer Organisation genehmigten Steuerelemente hosten. Wie bei der vorherigen Vorgehensweise erfordert diese Lösung fortlaufende Verwaltung, und das Hosten eines internen Servers für ActiveX-Steuerelemente verursacht Kosten und Komplexität.

Es gibt andere Lösungen, z. B. die Modifizierung der URLActions der Internet Explorer-Zone, wobei die von Administratoren genehmigten Steuerelemente über die Gruppenrichtlinien angegeben und die Installation aller Steuerelemente aus dem Umkreisnetzwerk durch Firewallrichtlinien gesperrt werden. Bei allen diesen Ansätzen gibt es offensichtlich gewisse Probleme, und viele werden wegen ihres Mangels an Flexibilität schließlich verworfen. Schlimmer noch ist, dass manche dieser Lösungen nach wie vor Administratorrechte des Benutzers erfordern. Letztendlich versuchen diese Modifizierungen, Teile des Problems zu behandeln, z. B. die Steuerung (oder Sperrung) der Orte, von denen die ActiveX-Steuerelemente stammen, von denen aus sie aufgerufen werden können, und so weiter. Diese Lösungen verringern jedoch nicht das grundlegende Problem, dass Benutzer ohne Administratorrechte keine ActiveX-Steuerelemente installieren können.

Was kann AxIS für Sie tun?

AxIS in Windows Vista ermöglicht dem Unternehmensadministrator, ActiveX-Steuerelemente unter Aufrechterhaltung einer starken Sicherheit zu verwalten, indem Benutzer unter den Standardeinstellungen des Dateisystems als Standardbenutzer angesehen werden. AxIS stellt Gruppenrichtlinienoptionen bereit, um vertrauenswürdige Quellen von ActiveX-Steuerelementen zu konfigurieren, sowie einen Brokerprozess, um Steuerelemente aus diesen vertrauenswürdigen Quellen im Namen von Standardbenutzern zu installieren. Der wichtigste Vorteil ist, dass Sie auf Benutzerarbeitsstationen eine nicht administrative Sicherheitsfunktion unter der zentralen Kontrolle durch den Administrator unterhalten können. Bei Verwendung von AxIS identifiziert der IT-Administrator vertrauenswürdige Quellen für ActiveX-Steuerelemente (in der Regel Internet- oder Intranet-URLs). Wenn ein Objekttag Internet Explorer anweist, ein Steuerelement aufzurufen, führt AxIS die folgenden Schritte aus:

1. Überprüfung, ob das Steuerelement installiert ist. Ist dies nicht der Fall, muss es vor Verwendung installiert werden.
2. Prüfung anhand der AxIS-Richtlinieneinstellung, ob das Steuerelement aus einer vertrauenswürdigen Quelle stammt. Die spezifische Überprüfung vergleicht den im Attribut CODEBASE des Objekttags angegebenen Hostnamen der URL mit der in den Richtlinien angegebenen Liste vertrauenswürdiger Orte.
3. Herunterladen und Installieren des Steuerelements im Namen des Benutzers.

Wenn der Hostname der Quell-URL nicht in der AxIS-Richtlinieneinstellung aufgelistet ist, wird die normale Eingabeaufforderung der Benutzerkontensteuerung (User Account Control, UAC) aufgerufen, die für die Durchführung der Installation Administratorrechte erfordert. Darüber hinaus hält AxIS im Anwendungsereignisprotokoll von der Quelle AxInstallService ein Ereignis mit der Kennung 4097 fest. Darin wird die versuchte Installation eines ActiveX-Steuerelements unter Angabe des spezifischen Downloadpfads zum Steuerelement beschrieben. Ein Beispiel für das Ereignis 4097 wird in Abbildung 2 dargestellt. Der Unternehmensadministrator kann mithilfe der Daten aus diesem Ereignisprotokolleintrag die Gruppenrichtlinien dahingehend ändern, dass das Steuerelement durch AxIS bei nachfolgenden Besuchen der Website installiert werden kann.

Abbildung 2** Das AxInstallService-Ereignis 4097 **

AxIS ist eine optionale Komponente, die in den SKUs Business, Enterprise und Ultimate von Windows Vista enthalten ist. Sie kann durch eine unbeaufsichtigte Option oder über das Dialogfeld Systemsteuerung (Programme | Programme und Funktionen | Windows-Funktionen ein- oder ausschalten), wie in Abbildung 3 gezeigt, aktiviert werden. Nach der Aktivierung durchläuft AxIS die oben skizzierten Schritte, wann immer von Internet Explorer ein Steuerelement angefordert wird.

Abbildung 3** Aktivieren von AxIS in der Systemsteuerung **

Die Tatsache, dass sich in Windows Vista Aufgaben an Ereignisse anfügen lassen, bietet einem Administrator eine einfache Möglichkeit, vom AxIS-Dienst eine Benachrichtigung zu erhalten, z. B. wenn die Installation eines ActiveX-Steuerelements gesperrt ist. Es kann allerdings nicht immer davon ausgegangen werden, dass das ActiveX-Steuerelement von demselben URL-Hostnamen installiert wird, auf den der Endbenutzer von seiner Website aus zugreift. Aus diesem Grund können sich die vom AxInstallService-Ereignis 4097 bereitgestellten Informationen (versuchte Installation) als äußerst nützlich erweisen, um den Host, von dem aus die Installation des Steuerelements versucht wird, zu identifizieren.

Mit den Informationen aus dem Ereignis können Sie den vertrauenswürdigen Ort in den Gruppenrichtlinien konfigurieren. AxIS-Einstellungen für lokale oder Gruppenrichtlinien finden Sie in den Computerkonfigurationseinstellungen (siehe Abbildung 4). Die Richtlinieneinstellung für genehmigte Installationssites für ActiveX-Steuerelemente ermöglicht Ihnen, Host-URLs vertrauenswürdiger Orte anzugeben (siehe Abbildung 5). Für die Einstellung genehmigter Sites sind zwei Informationen erforderlich: von wo aus das ActiveX-Steuerelement installiert werden darf, sowie das Verhalten bei der Installation.

Abbildung 4** Einstellungen im Gruppenrichtlinienobjekt-Editor **

Abbildung 5** Von AxIS genehmigte Installationssites **

Wie oben erwähnt, ist zunächst eine Host-URL erforderlich, um den vertrauenswürdigen Ort des Steuerelements anzugeben. Im Unterschied zu früheren Lösungen, bei denen die CLSID des Steuerelements bekannt sein musste (die sich oft ändert, wenn Steuerelemente von Entwicklern überarbeitet werden), ermöglicht AxIS die Installation eines beliebigen Steuerelements vom vertrauenswürdigen Ort aus, was die administrative Gesamtbelastung verringert. Die zweite Information ist eine durch Komma getrennte Zeichenfolge von vier Werten, von denen jeder das Downloadverhalten des ActiveX-Steuerelements bestimmt. Die Werte geben vier Eigenschaften an: TPSSignedControl, SignedControl, UnsignedControl und ServerCertificatePolicy. Die ersten zwei Eigenschaften (TPSSignedControl und SignedControl) können einen der folgenden drei Werte annehmen: 0, 1 oder 2. Diese Werte ähneln denjenigen in URLAction-Einstellungen. Der Wert 0 verhindert die Installation des Steuerelements, beim Wert 1 wird der Benutzer aufgefordert, die Installation zu genehmigen, und beim Wert 2 wird das Steuerelement automatisch im Namen des Benutzers installiert. Nicht signierte Steuerelemente können nicht automatisch installiert werden. Daher kann UnsignedControl nur den Wert 0 oder 1 annehmen. Beachten Sie, dass die Standardwerte 2, 1 und 0 verwendet werden, wenn keine Richtlinie angegeben ist.

Die letzte Eigenschaft gibt das Installationsverhalten auf Grundlage der Zertifikatseinstellungen der signierten Einstellungssteuerung an. Wie die meisten SSL-Sites müssen Zertifikate einen Satz von Sicherheitstests durchlaufen, um zu gewährleisten, dass das Zertifikat gültig ist. In der Praxis treten ungültige Zertifikateigenschaften bei der Implementierung signierter ActiveX-Steuerelemente zuweilen auf. AxIS ermöglicht Administratoren aufgrund seiner Konfiguration, ungültige Informationen zu reduzieren, die manchmal von Zertifikaten auf einer URL-für-URL-Basis anzeigt werden. Die letzte Eigenschaft stellt sich als eine Bitmaskenkombination der in Abbildung 6 gezeigten Werte dar.

Figure 6 ServerCertificatePolicy

Die Standardeinstellung ist 0, was bedeutet, dass alle Sicherheitsüberprüfungen zu durchlaufen sind, bevor AxIS die Installation durchführt. Die Kombinationen aus Hosteinstellung und diesen vier Werten sind in der Richtlinieneinstellung angegeben, wie in Abbildung 7 gezeigt.

Abbildung 7** Genehmigte AxIS-Host-URLs **

Schlussbemerkung

Mit AxIS können Sie die Gruppenrichtlinie so konfigurieren, dass sie steuert, welche ActiveX-Steuerelemente von Benutzern ohne Administratorrechte oder komplexe Konfigurationen installiert werden können. Eine Steuerung auf dieser Ebene war in früheren Versionen von Windows oft eine Herausforderung, und früher verfügbare Lösungen brachten oft erhebliche Einschränkungen oder vermehrten Verwaltungsaufwand mit sich. Mit AxIS erhalten Organisationen ein weiteres Tool für einen Ansatz mit geringsten Rechten im Hinblick auf Endbenutzerrechte für Desktopsysteme, was die Implementierung eines Standardbenutzermodells ermöglicht, bei dem Endbenutzer keine Administratorrechte benötigen. Dank Windows Vista liegt die Kontrolle wieder beim IT-Administrator, da er und nicht der Endbenutzer auswählt, welche ActiveX-Steuerelemente in der durch die Organisation festgelegten Unternehmensumgebung vertrauenswürdig sind.

Rob Campbell ist Senior Technical Specialist im Microsoft Federation Team. Rob Campbell befasst sich hauptsächlich mit der Entwicklung und Bereitstellung von Sicherheitslösungen für die Bundesregierung der USA.

Joel Yoker ist Senior Consultant im Microsoft Federation Team. Joel Yoker befasst sich hauptsächlich mit der Entwicklung und Bereitstellung von Sicherheitslösungen für die Bundesregierung der USA.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.