Die DesktopdateienVom Administrator zum Benutzer

Wes Miller

Vor mehr als drei Jahren habe ich damit begonnen, auf meinem primären Windows-PC statt eines lokalen Administratorkontos ein lokales Benutzerkonto zu verwenden. Ich hatte mehr als sieben Jahre bei Microsoft gearbeitet und dort Windows immer als Administrator mit sämtlichen Berechtigungen ausgeführt. Sicherlich war das sehr praktisch, aber zugleich auch von einem Sicherheitsstandpunkt aus gesehen beängstigend.

Man kann von Glück sagen, dass nicht viel mehr Probleme auftreten, wenn jeder Benutzer jeden Tag Windows als Administrator ausführt.

Ich wünsche mir oft, dass es eine Möglichkeit gäbe, hierzu eine gute Statistik zu bekommen, aber sowohl mein Instinkt als auch die Branche sagen mir, dass zu viele Organisationen (und zu viele IT-Experten) Windows als lokale Administratoren ausführen. Als ich bei Winternals von einem Administratorkonto auf ein Benutzerkonto umgestiegen bin, wollte ich damit einerseits herausfinden, wie es einem normalen Benutzer ergeht, und andererseits auch sehen, welchen Mehrwert unser Produkt, Winternals Protection Manager, in einer durchschnittlichen Organisation liefern könnte. Da Benutzer in den meisten Organisationen früher und auch heute noch Windows als Administrator ausführen, bestand unser Ziel darin, es Administratoren zu ermöglichen, Windows als Benutzer auszuführen, aber den Übergang so schmerzlos wie möglich zu machen. Egal welche Technologie Sie verwenden, es ist nicht einfach, Ihre Organisation von einer Organisation, in der Benutzer Administratoren sind, zu einer Organisation zu machen, in der sie Benutzer sind. Es ist aber die effektivste Methode, um die Angriffsfläche in Ihrer Organisation zu verringern. Stellen Sie sich dazu eine systeminterne Firewall vor, denn darum handelt es sich in Wirklichkeit.

Wir sind wir dorthin gekommen?

Meine Herausforderung an Sie: Fühlen Sie den Schmerz

Wenn Sie noch nicht darüber nachgedacht haben, aus Ihren Administratoren Benutzer zu machen, sollten Sie das jetzt tun. Ich möchte Ihnen hierbei auch gleichzeitig nahelegen, zunächst selbst ein bisschen damit zu experimentieren, aber nicht auf einem zweiten PC, denn das wäre geschummelt! Probieren Sie es auf Ihrem normalen System, mit dem Sie jeden Tag arbeiten. Probieren Sie es sogar ohne Benutzerkontensteuerung, wenn Sie mit Windows Vista® arbeiten. Wenn Sie in Ihrer Organisation etwas ändern wollen, ist es immer besser, nicht nur über theoretisches Wissen zu verfügen, sondern auch praktische Erfahrung mitzubringen. Sie werden sehen, dass das Ausführen von Windows als Nichtadministrator gar nicht so schwierig ist und dass Sie durch die damit verbundene erhöhte Sicherheit die Angriffsfläche Ihrer Organisation erheblich verringern.

Dass die meisten Benutzer Windows als Administrator ausführen, geht auf die Anfänge von Windows® zurück. Bei den ersten Versionen von Windows (vor Windows NT® 3.1) hatten alle Benutzer die gleichen Rechte. Funktionstechnisch gesehen gab es keine Sicherheit. Zuhause war das kein Problem. Es bedeutete nur, dass alle Programme auf die gleiche Weise installiert wurden. Es wurde angenommen, dass der Computer dem Benutzer gehört und dass alle Programme für alle Benutzer dieses Computers installiert wurden.

Als Windows NT auf den Markt kam, hat es sich nicht sofort in Unternehmen (und schon gar nicht in Privathaushalten) durchgesetzt. Aufgrund der Win32®-Kompatibilität zwischen 32-Bit-Windows und Windows NT programmierten die meisten Softwarehersteller ihre Programme nicht extra um, nur damit sie die Sicherheitsinfrastruktur von Windows NT nutzen konnten. Erst als Windows 2000 auf den Markt kam, begannen viele unabhängige Softwarehersteller damit, sich für Windows NT zu interessieren. Mit Windows XP änderte sich das allerdings schlagartig, da mit Windows XP das Ende der 9x-Familie eingeläutet wurde.

Programme wurden aber dennoch weiter so entwickelt, als ob jeder Benutzer auf dem System für den Programmordner, für HKEY_LOCAL_MACHINE (HKLM) in der Registrierung und für HKEY_CLASSES_ROOT Schreibrechte besäße, obwohl das nicht der Fall ist. Gerade bei Spielen wird oft davon ausgegangen, dass jeder über Schreibrechte für alle Bereiche verfügt, siehe hierzu den Artikel von Matt Clapham zu diesem Thema unter technetmagazine.com/issues/2007/02/Gaming.

Das ist problematisch, weil die meisten systemübergreifenden Programme ihre Dateien und Registrierungseinstellungen in diesen Bereichen speichern und Sie einen Lese- und Schreibzugriff für diese Bereiche haben müssen, um die Programme installieren zu können. Leider bestehen einige Programme darauf, nach der Installation in diese Schlüssel zu schreiben. Meine Tochter besitzt zum Beispiel ein Spiel, das auf Flash basiert. Das Spiel versucht jedes Mal, wenn man es ausführt, einen benutzerdefinierten Spieler zu installieren. Wenn meine Tochter das Spiel als Benutzer und nicht als Administrator ausführt, schlägt der Programmstart mit einem schweren Fehler fehl. Das ist zwar extrem, und es handelt sich hierbei um eine Verbraucheranwendung, aber die Realität ist, dass viele Unternehmensanwendungen immer noch nicht gut in einer Welt mit Benutzern ohne Administratorrechte laufen. Wenn Sie meine Herausforderung annehmen (siehe Randleiste „Meine Herausforderung an Sie: Fühlen Sie den Schmerz“), werden Sie feststellen, wie wenig tolerant Windows bei der Ausführung als Benutzer ist.

Wenn Sie sich Abbildung 1 ansehen, sehen Sie, wie die Ausführung von IPConfig /release als Benutzer unter Windows XP aussieht. Wenn Sie das mit Abbildung 2 vergleichen, sehen Sie, dass der gleiche Befehl unter Windows Vista auch nicht viel besser funktioniert, aber zumindest wissen Sie, warum der Befehl fehlschlägt. Die Netzwerktools sind insgesamt allerdings verbessert worden, um es Benutzern zu ermöglichen, ihre IP-Adressen zu aktualisieren. Wenn Sie die Computerverwaltung (compmgmt.msc) als Benutzer unter diesen beiden Versionen ausführen, können Sie nur eine begrenzte Zahl von Aufgaben durchführen, was aber in der Regel in frustrierenden Sackgassen endet, wie Abbildung 3 zeigt. Windows Vista aktiviert zwar anfänglich nicht viele der Tools in der Computerverwaltung, gibt aber klarere Meldungen bei einer Zugriffsverweigerung zurück.

Abbildung 1 Ausführen von Programmen als Benutzer unter Windows XP

Abbildung 1** Ausführen von Programmen als Benutzer unter Windows XP **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 2 Ausführen von Programmen als Benutzer unter Windows Vista

Abbildung 2** Ausführen von Programmen als Benutzer unter Windows Vista **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 3 Irreführende Meldung, nachdem compmgmt.msc als Benutzer unter Windows XP ausgeführt wurde

Abbildung 3** Irreführende Meldung, nachdem compmgmt.msc als Benutzer unter Windows XP ausgeführt wurde **(Klicken Sie zum Vergrößern auf das Bild)

Warum es einen Unterschied macht

Warum sollten Sie sich also mit diesem Thema befassen? Weil wir als IT-Experten damit beginnen sollten, Anwendungen zu zwingen, sich an Benutzer mit den geringsten Rechten anzupassen, statt Anwendungen zu erlauben anzunehmen, dass dem Benutzer das System gehört.

Leider gewähren die gleichen Richtlinien, die es Administratoren ermöglichen, in Registrierungsschlüssel zu schreiben, auch Malware im Benutzerkontext vollen Zugriff auf alles, das nicht explizit über Zugriffssteuerungslisten verweigert wird. In der UNIX-Welt folgt man der Regel, das Betriebssystem nicht als „root“ (das Äquivalent des Windows-Administratorkontos) auszuführen, größtenteils deshalb, weil das Ökosystem der Software, das die Grenzen des Sicherheitsmodells verschiebt, winzig bis nicht existent ist.

Das Beste, was Sie tun können, ist aber immer noch, dem gleichen Prinzip zu folgen und Windows nur dann als Administrator auszuführen, wenn es explizit gefordert wird, oder (noch besser) nur einzelne Programme als Administrator auszuführen. Hierdurch bauen Sie die weiter oben erwähnte systeminterne Firewall auf. Wenn Malware oder Spyware dann versucht, etwas Unerlaubtes zu tun, schlägt dies fehl, weil die Malware oder Spyware nicht in die Registrierung oder in die Dateisystemordner schreiben kann, um Ihr System wirklich zu infizieren (z. B. um einen Dienst oder Treiber oder ein Programm für alle Benutzer zu installieren). Außerdem wird hierdurch ermöglicht, dass Antimalware Malware enthält, die es erkennt, ohne dabei das gesamte System zu gefährden.

Es ist aber zu beachten, dass Benutzer vor Angriffen nicht komplett geschützt sind. Obwohl diese Malwareklasse noch nicht sehr verbreitet ist, kann Malware den Kontext eines einzelnen Benutzers infizieren oder seine Daten zerstören. Die Angriffsmöglichkeiten durch Software dieser Art sind aber begrenzt. Demzufolge kann durch das gleiche Prinzip, das Malwareinstanzen unter Linux oder unter Mac OS niedrig hält (weniger potentielle Opfer sind für Malwareersteller nicht so interessant) dabei helfen, die allgemeine Sicherheit Ihrer Endbenutzer und Ihre eigene Sicherheit zu gewährleisten.

Gehören Poweruser der Vergangenheit an?

Als wir den Protection Manager entwickelten, lautete einer der Kommentare unserer Kunden: „Wir führen Windows XP mit allen unseren Benutzern als Poweruser und nicht als Administrator aus, darum treten bei uns keine Sicherheitsprobleme auf.“ Die Realität ist aber, dass Poweruser nur ein paar Schritte von Administratoren entfernt sind. Es gibt mehrere potenzielle Sicherheitslücken, die es (mit ein bisschen Arbeit) einem Poweruser unter Windows XP ermöglichen würden, ein Administrator zu werden. Die Powerusergruppe gibt es unter Windows Vista und Windows Server® 2008 nicht mehr. Nur Systeme, die von einer früheren Version von Windows aktualisiert wurden, haben eine Powerusergruppe. Generell sollten Sie immer vermeiden, die Powerusergruppe zu verwenden, selbst wenn Sie mit Windows XP arbeiten.

Weniger Berechtigungen

Wenn Sie meinen Artikel des Monats März zu Windows-Thin Clients (technetmagazine.com/issues/2008/03/DesktopFiles) gelesen haben, werden Sie sich daran erinnern, dass ich mich darin gegen ein Ausdünnen von Windows XP zum Sparen von Platz ausgesprochen habe. Im gleichen Sinne müssen beim Übergang von Administrator- zu Benutzerkonten einige Punkte berücksichtigt werden. Zum einen die Praxis, ACLs in der Registrierung und im Dateisystem anzupassen, damit Benutzer in Ordner schreiben können, in die sie normalerweise nicht schreiben dürfen, und somit problematische Anwendungen ausführen können.

Natürlich ist es am besten, eine aktualisierte Version eines Programms zu besorgen, die diese Änderung nicht erfordert, aber das ist nicht immer möglich. Wenn Sie Berechtigungen ändern (d. h. mehr Zugriffsrechte gewähren) müssen, sollten Sie sehr vorsichtig vorgehen. Denken Sie daran, dass die Firewall zwischen einem Benutzer und einem Administrator größtenteils durch die Berechtigungen für die Registrierung und das Dateisystem definiert wird. Wenn Sie mehr Zugriffsrechte gewähren, verringern Sie Ihren Schutz und vergrößern potenziell die Angriffsfläche für Malware. Seien Sie deshalb vorsichtig.

Was ist mit der Benutzerkontensteuerung?

Keine Diskussion über den Übergang von Administratoren zu Benutzern ist vollständig, wenn nicht auf die Benutzerkontensteuerung in Windows Vista eingegangen wird. Die Benutzerkontensteuerung lässt Sie, wie die ähnliche Funktion unter Mac OS X, Programme als Administrator ausführen, ohne Sie dabei zu stark zu gefährden.

Wie funktioniert das? Sehen Sie sich in Abbildung 4 an, welche Informationen Process Explorer zu cmd.exe anzeigt. Die cmd.exe-Instanz auf der rechten Seite wurde ohne eine Erhöhung der Zugriffsrechte mit mir als Administrator gestartet. Selbst wenn der Benutzer auf der rechten Seite identisch mit dem Benutzer auf der linken Seite ist (auf der cmd.exe mit erhöhten Benutzerrechten gestartet wurde), enthält die Anwendung selbst nicht die notwendigen Berechtigungen und Token (und den Benutzer, der die Instanz ausführt), um Aufgaben durchzuführen, die Administratorrechte erfordern. Die Benutzerkontensteuerung verringert die Angriffsfläche innerhalb des interaktiven Kontexts eines Benutzers. Das einzige Problem besteht darin, dass jemand Windows mitteilen muss, dass diese Aufgabe Administratorrechte erfordert und dass der Benutzer damit einverstanden ist, die Zugriffsrechte zu erhöhen, um diese Aufgabe abzuschließen.

Abbildung 4 Zwei Instanzen von cmd.exe mit unterschiedlichen Berechtigungen

Abbildung 4** Zwei Instanzen von cmd.exe mit unterschiedlichen Berechtigungen **(Klicken Sie zum Vergrößern auf das Bild)

Die kleinen Schildsymbole in Windows Vista zeigen Ihnen, für welche Aufgaben erhöhte Zugriffsrechte erforderlich sind (siehe Abbildung 5). Für diese Aufgaben müssen jedes Mal, wenn Sie sie ausführen, die Zugriffsrechte erhöht werden, und das ist eine der Schwachstellen, die die Presse bei Windows Vista hervorgehoben hat. Die Alternative, bei der die Anmeldeinformationen automatisch dazu genutzt werden, die Zugriffsrechte zu erhöhen, stellt eine potenzielle Sicherheitsbedrohung dar, die genutzt werden könnte, um leichter in das System einzudringen.

Abbildung 5 Schildsymbole in Windows Vista zeigen an, wenn erhöhte Zugriffsrechte erforderlich sind

Abbildung 5** Schildsymbole in Windows Vista zeigen an, wenn erhöhte Zugriffsrechte erforderlich sind **(Klicken Sie zum Vergrößern auf das Bild)

Wenn die Benutzerkontensteuerung aktiviert ist und Ihre Benutzer Windows als normale Benutzer ausführen, werden sie zur Eingabe administrativer Anmeldeinformationen aufgefordert, wenn eine Anwendung Administratorrechte erfordert. In diesem Fall ist wie beim Verwenden von „runas“ oder „psexec“ zu beachten, dass die Anwendung buchstäblich im Kontext des Benutzers ausgeführt wird, in dem sie gestartet wurde, und nicht wie bei der Benutzerkontensteuerung als Administrator. In diesem Fall werden die Aufgaben zwar in Ihrem Kontext, aber mit erhöhten Berechtigungen ausgeführt.

Ausführen von Windows Vista als Benutzer?

Persönlich ziehe ich es vor, Windows Vista als Benutzer und nicht als Administrator mit Benutzerkontensteuerung auszuführen, weil ich der Meinung bin, dass das in einem durchschnittlichen Unternehmen immer noch das Beste ist. Ihre Benutzer haben ja weiterhin volle Kontrolle über ihre Systeme, und Sie haben potenzielle Sicherheitslücken verringert.

Wenn Sie außerdem vorhaben, Ihre Benutzer mit Gruppenrichtlinien, Virenscannern, Antimalware oder anderer Software zu verwalten und eine zentrale Kontrolle darüber haben wollen, ob diese Aufgaben tatsächlich durchgesetzt oder abgeschlossen werden, ist die Gewährleistung, dass Ihre Endbenutzer keine Administratoren sind, ein entscheidender Schritt. Wenn Ihre Benutzer Administratoren sind, können sie Dienste anhalten, Treiber hinzufügen oder entfernen und andere Aufgaben durchführen. Selbstverständlich kann ein geschickter Endbenutzer, der Windows PE als Benutzer ausführt, einige Sicherheitshürden überwinden. BitLocker® kann das erschweren, aber auch hier sollten Sie nicht vergessen, dass Endbenutzer mit einem direkten Zugang zu ihrem PC tun können, was immer sie wollen, wenn sie genügend Zeit und Wissen haben und entsprechend motiviert sind.

Das Ausführen von Windows Vista als Benutzer unterscheidet sich nicht allzu sehr vom Ausführen von Windows XP als Benutzer. Ich verwende die gleichen Tools – PSExec, RunAs (und jetzt die Benutzerkontensteuerung) –, um bei Bedarf Aufgaben als Administrator durchzuführen. Das Gute dabei ist, dass ziemlich viele Aufgaben in Windows XP, für die früher Administratorrechte erforderlich waren, heute keine Administratorrechte mehr erfordern. Zum Beispiel kann ein Windows Vista-Benutzer einen lokalen Drucker installieren. (Netzwerkdrucker konnten von Benutzern in Windows XP installiert werden, aber für die Installation eines lokalen Druckers waren Administratorrechte erforderlich.) Solange der Benutzer in Windows Vista direkt am Computer sitzt und sich der Druckertreiber im Treiberverzeichnis befindet, kann ein Benutzer einen Drucker installieren und darauf Druckaufträge verwalten. (Weitere Informationen finden Sie unter go.microsoft.com/fwlink/?LinkId=111534.) Beachten Sie, dass diese Funktionalität in Windows Server 2008 deaktiviert ist.

Oftmals machen sich Personen über die Uhrfunktion (bzw. die Nichtexistenz dieser Funktion) beim Ausführen von Windows XP als Benutzer lustig. Versuchen Sie einmal, als Benutzer auf die Uhr doppelzuklicken (etwas, das Benutzer oft tun, um zu sehen, welches Datum heute ist, egal ob die Funktion hierfür gedacht war oder nicht). Sie erhalten in diesem Fall den in Abbildung 6 gezeigten Fehler. Nicht gerade sehr freundlich. Unter Windows XP können Sie die Richtlinie ändern, damit Benutzer dies tun können, aber unter Windows Vista wurde dies geändert. Alles in allem ist das Ausführen von Windows Vista als Benutzer (ob Sie nun die Benutzerkontensteuerung verwenden oder Windows als formaler Benutzer oder als ein anderer Benutzer mit erhöhten Zugriffsrechten ausführen) also angenehmer als unter Windows XP.

Abbildung 6 Unter Windows XP konnten Nichtadministratoren die Uhrzeit nicht ändern

Abbildung 6** Unter Windows XP konnten Nichtadministratoren die Uhrzeit nicht ändern **(Klicken Sie zum Vergrößern auf das Bild)

Denken Sie an die Beschränkungen

Denken Sie daran, dass der Umstieg auf die Ausführung von Windows als Nichtadministrator kein Allheilmittel ist. Endbenutzer sitzen immer noch direkt vor ihren eigenen PCs und können die Sicherheitsmaßnahmen ihrer eigenen Systeme umgehen, insbesondere wenn die Richtlinie oder die Benutzerberechtigungen sie stören oder daran hindern, ihre Arbeit zu erledigen.

Wenn Ihre Benutzer Windows als Administratoren ausführen, lassen sich Gruppenrichtlinien schnell umgehen. Mit etwas mehr Aufwand können Benutzer zu Windows PE booten und Berechtigungen ändern, die sie normalerweise nicht ändern können, aber wenn Sie BitLocker oder eine andere Laufwerk-/Volumeverschlüsselung verwenden, können Sie das unmöglich machen oder zumindest erschweren.

Das Wichtigste, das Sie tun können, wenn Ihre Organisation noch nicht damit begonnen hat, Endbenutzer Windows als Benutzer ausführen zu lassen, besteht darin, sich mit den Gründen vertraut zu machen, warum Sie und die Organisation Zeit, Geld und Arbeit investieren sollten, um sich von dem Prinzip wegzubewegen, dass Benutzer Windows als Administratoren ausführen.

Natürlich ist es nicht leicht, sich von Legacyanwendungen zu trennen, aber wenn Sie ein Programm haben, das einfach nicht als Benutzer ausgeführt werden kann, ist es keine gute Idee, an diesem Programm festzuhalten, da es die Sicherheit Ihrer Organisation gefährdet. Sie sollten in Erwägung ziehen, das Programm zu virtualisieren, also buchstäblich auf einen virtuellen Computer zu verschieben, wo der Benutzer ein Administrator ist. Hierdurch kann das Programm wie erforderlich verwendet werden, ermöglicht es Ihnen aber dennoch, das restliche System sicherer zu machen, indem sich Benutzer als Benutzer und nicht als Administratoren anmelden.

Beachten Sie, dass ich in diesem ganzen Artikel nicht einmal den Ausdruck „Benutzerrechte einschränken“ oder ähnliche Ausdrücke verwendet habe. Wenn sich Benutzer als Benutzer und nicht als Administratoren anmelden, fällt in diesem Zusammenhang oftmals dieser oder ein ähnlicher Ausdruck. Vielleicht liegt das an meinem Psychologiehintergrund oder an meinem momentanen Marketingumfeld, aber ich bin der Meinung, dass es wichtig ist, keine Wörter zu verwenden, die Ihren Endbenutzern den Eindruck vermitteln, dass ihnen Zugriffsrechte weggenommen wurden (selbst wenn das semantisch gesehen der Fall ist).

Konzentrieren Sie sich stattdessen auf die Sicherheitsvorteile für die Organisation, und halten Sie Alternativen für Randfälle bereit, in denen Benutzer bestimmte Programme oder Aufgaben nicht als Benutzer ausführen können. Ob Sie nun manuelle Methoden wie das Skript „Run.vbs“ (das Sie unter technetmagazine.com/issues/2007/03/DesktopFiles finden) verwenden oder eine kommerzielle Lösung nutzen, um den Umstieg vorzunehmen (der Ihnen erlaubt, Details vor Ihren Endbenutzern zu verbergen und dafür zu sorgen, dass alles „einfach funktioniert“): Es ist wichtig, so schnell wie möglich vom Administratorkonzept auf das Benutzerkonzept umzusteigen. Aaron Margosis schreibt regelmäßig Artikel für das TechNet Magazin und ist Experte, wenn es darum geht, Windows als Nichtadministrator auszuführen. Wenn Sie seinen Blog noch nicht gelesen haben, sollten Sie das unbedingt tun (siehe blogs.msdn.com/aaron_margosis). 

Wes Miller ist momentan Senior Technical Product Manager bei CoreTrace (www.CoreTrace.com) in Austin, Texas. Zuvor war er bei Winternals Software und als Programmmanager bei Microsoft tätig. Sie können Wes Miller unter technet@getwired.com erreichen.

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