June 2008 June 2008
Sicherheit: Die große Debatte: Sicherheit durch Verschleierung
Das Konzept der Sicherheit durch Verschleierung (Security by Obscurity) beinhaltet Maßnahmen, durch die Sicherheitslücken nicht beseitigt, aber verborgen werden. Während einerseits die Meinung vorherrscht, dass dies kein empfehlenswertes Verfahren sei, sind andere davon überzeugt, dass im Rahmen einer umfassenderen Strategie jede Maßnahme zählt. Das Thema wird kontrovers diskutiert, und einige unserer besten Sicherheitsexperten stehen sich dabei gegenüber und vertreten gegensätzliche Standpunkte. Jesper M. Johansson and Roger Grimes
Sicherheit: Neue Elevation PowerToys für Windows Vista
Michael Murgolo stellt eine Aktualisierung seiner Elevation PowerToys vor. Sie erhalten Informationen über die verbesserte Funktion „Run as Administrator“, die mit Skripterstellungstools von Drittanbietern arbeitet, Anweisungen zum Ersetzen eines nützlichen Windows XP-Features, das aus Windows Vista entfernt wurde, sowie Angaben zu vielen weiteren nützlichen Tools. Michael Murgolo
Sicherheit: Fortschritte bei der BitLocker-Laufwerkverschlüsselung
Seit Windows Vista SP1 und Windows Server 2008 gibt es wichtige Änderungen an BitLocker, einschließlich Unterstützung für Datenvolumes und verbessertem Schutz vor kryptografischen Angriffen. Byron Hynes erkundet die neuen Features, zeigt, wie BitLocker auf einem Server verwendet wird, und erörtert die aktuelle Medienberichterstattung über BitLocker. Byron Hynes
Sicherheit: Sperren von Anwendungen mit Softwareeinschränkungsrichtlinien
Wenn Sie die Gesamtkosten der Desktopcomputer in Ihrer Organisation verringern möchten, kann die Sperrung von Anwendungen eine große Hilfe sein. Sie ermöglicht es Ihnen, IT-Probleme in Verbindung mit nicht unterstützten Anwendungen zu begrenzen. Erfahren Sie, wie Sie Softwareeinschränkungsrichtlinien und die Gruppenrichtlinie dazu verwenden können, die in Ihrer IT-Infrastruktur ausgeführten Anwendungen zu kontrollieren. Chris Corio and Durga Prasad Sayana
Sicherheit: Verwalten der Windows Vista-Firewall
Das neue Update für die Windows Vista-Firewall bietet einige beeindruckende neue Features, die in einer Unternehmensumgebung unverzichtbar sind. Jesper Johansson gibt einen kurzen Überblick über die Entwicklung der Windows-Firewall und befasst sich mit Verbesserungen wie neuen Regeln und Profilen, Domänenisolation und Verschlüsselung, die für Administratoren interessant sind. Jesper M. Johansson
Sicherheit: Sichern von E-Mails mithilfe digitaler Zertifikate
Mit S/MIME (Secure Multi-Purpose Internet Mail Extensions) können Sie Informationen während der Übertragung ausblenden, Absender überprüfen und Nachrichten authentifizieren. Erfahren Sie, wie E-Mails mithilfe digitaler Zertifikate gesichert und potentielle Probleme in Ihrem S/MIME-System behandelt werden können. Matt Clapham and Blake Hutchinson
Columns
Mitteilung der Redaktion: Die große Debatte: | Briefe: Leser sagen ihre Meinung: | Toolbox: Neue Produkte für IT-Experten:
SQL – Fragen und Antworten: E/A-Fehler, Datenbankspiegelung und mehr: Paul Randal beantwortet Ihre Fragen zu SQL Server. Er zeigt Ihnen, wie Sie Beschädigungen in einer Testdatenbank erzeugen, hilft Ihnen beim Vermeiden von Jo-Jo-Effekten in den Zyklen und erläutert, wie Sie die Anzahl der möglichen Datenbanken für die Spiegelung ermitteln, bevor die Leistung absinkt.Paul S. Randal | Schwerpunkt Dienstprogramme: Windows Vista Upgrade Advisor: Sind Sie bereit, die Systeme in Ihrer Organisation auf Windows Vista zu aktualisieren? Erfahren Sie, wie sich mithilfe von Windows Vista Upgrade Advisor feststellen lässt, ob Ihre Systeme für Windows Vista tauglich sind und welche Versionen unterstützt werden können.Lance Whitney | Einblicke in SharePoint: Dezentralisieren der Websiteverwaltung: Erkunden Sie die Vorteile und die Auswirkungen, die sich ergeben, wenn die administrative Kontrolle der SharePoint-Websites an einzelne Abteilungen delegiert wird, während die zentrale administrative Kontrolle der SharePoint-Infrastruktur erhalten bleibt.Pav Cherny
Windows PowerShell: Es sieht gut aus: Erfahren Sie, wie Sie dank des objektorientierten Aufbaus von Windows PowerShell auf seine Ausgaben Formatierungen anwenden können.Don Jones | Hey, Scripting Guy!: Auch nicht so harte Arbeit hat ihren Lohn: Die Scripting Guys machen sich ihre Gedanken über harte Arbeit, wahres Glück und das Ausgeben von Daten im Befehlsfenster in einem lesbaren Tabellenformat.The Microsoft Scripting Guys | Die Desktopdateien: Sicherheit und Einhaltung von Bestimmungen: IT-Experten stehen oft Zielen gegenüber, die sich widersprechen. Erfahren Sie, weshalb die Einhaltung von Bestimmungen oftmals zu Abstrichen bei der Sicherheit führt.Wes Miller
Führung eines IT-Unternehmens: 10 Wege, um eine Führungsperson im Bereich Umweltfragen zu werden: Da IT-Abteilungen bei unternehmerischen Umweltschutzmaßnahmen eine zunehmend wichtige Rolle spielen, finden IT-Experten hier eine Gelegenheit, Veränderungen zu unterstützen und sich zu so genannten Thought Leaders in ihren Unternehmen und Branchen zu entwickeln. Hier erhalten Sie eine Übersicht, wie Sie sich zu einer effektiven innovativen Führungsperson für Initiativen im Bereich Umwelt und Nachhaltigkeit in Ihrer Organisation entwickeln.Michael Walsh and Eliza Walsh | Berichte aus der Praxis: Gemeinsame Monitornutzung mittels Split Screen: Das von Microsoft Research India entwickelte Split Screen ermöglicht zwei Benutzern, sich einen Monitor zu teilen, wobei auf jeder Seite separate Instanzen des Betriebssystems ausgeführt werden.Kentaro Toyama | Windows Confidential: Die beiden schlechtesten PCs, die es je gab: Raymond Chen erinnert sich gerne an die beiden schlechtesten Computer zurück, mit denen er je gearbeitet hat.Raymond Chen


Sicherheit
Die große Debatte: Sicherheit durch Verschleierung
Jesper M. Johansson and Roger Grimes
Auf einen Blick:
  • Sicherheit durch Verschleierung
  • Evaluierung von Maßnahmen auf dem Gebiet Sicherheit durch Verschleierung
  • Bewertung des Nutzens der Umbenennung des Administratorkontos
  • Treffen fundierter Entscheidungen zum Risikomanagement

Der Begriff „Sicherheit durch Verschleierung“ wird von Sicherheitsverantwortlichen oft belächelt, insbesondere von denjenigen, die sich für Experten halten. In manchen Kreisen wird „Sicherheit
durch Verschleierung“ beinahe als anstößiger Ausdruck betrachtet, und wie bei Wikipedia zu lesen ist (en.wikipedia.org/wiki/Security_through_obscurity), handelt es sich um ein äußerst umstrittenes Sicherheitskonzept. Man hört oft spöttische Bemerkungen über Personen, deren Bemühungen mit „nichts als Sicherheit durch Verschleierung“ abgetan werden.
Sicherheit durch Verschleierung ist, kurz gesagt, ein Verstoß gegen Kerckhoffs Prinzip, das besagt, dass ein System aufgrund seines Designs sicher sein sollte, und nicht, weil das Design dem Angreifer unbekannt ist. Die Prämisse von Kerckhoffs Prinzip ist, dass Geheimnisse nicht lange Geheimnisse bleiben.
Ein gutes Beispiel hierfür ist das NTLM-Authentifizierungsprotokoll (Windows NT®-LAN-Manager), das anfangs als Designgeheimnis erachtet wurde. Um das Samba-Interoperabilitätsprodukt für UNIX-basierte Betriebssysteme zu implementieren, musste das Samba-Team das Protokoll rekonstruieren. Das Ergebnis war die umfassendste Dokumentation zu NTLM, die es gibt (monyo.com/technical/samba/translation/ntlm.en.html), und es wurde eine Reihe von Fehlern entdeckt. Da im Bereich Sicherheit so vieles aus der Kryptografie erwachsen ist und eine so große Anzahl geheimer Designs offengelegt wurde, glauben viele Sicherheitsfachleute, dass Informationssicherheit voll und ganz auf Kerckhoffs Prinzip basieren sollte.
Aber ist Sicherheit durch Verschleierung immer etwas Schlechtes? In diesem Artikel wird erklärt, was Sicherheit durch Verschleierung bedeutet. Es wird erläutert, weshalb dieses Konzept von vielen als Zeitverschwendung betrachtet wird (und von anderen nicht), und es wird aufgezeigt, warum die Antwort, wie es so oft der Fall ist, deutlich komplizierter ausfällt, als es zunächst den Anschein hat.

Einführung in Sicherheit durch Verschleierung
„Kein Ändern von Standardeinstellungen“ von Steve Riley
Ich vertrete beim Thema Umbenennung den Standpunkt „Keine Änderung“. Dabei handelt es sich nicht um eine Sicherheitsfrage, sondern eine Frage der Systemverwaltung. Je mehr ich über Systemverwaltung nachdenke (weil Verwaltung und Sicherheit miteinander verschmelzen), desto mehr werde ich zum Anhänger des Ansatzes, nichts zu tun, was die Stabilität eines Systems u. U. beeinträchtigen könnte. Eine sichere Möglichkeit, die Stabilität zu beeinträchtigen, ist das Ändern von Standardeinstellungen. Es gibt zwei (oder auch drei) Gründe, weshalb Benutzer Standardeinstellungen ändern:
  • Die durch die Änderung ermöglichte Funktionalität ist erforderlich.
  • Es besteht die Annahme, dass durch die Änderung die Sicherheit verbessert wird.
  • (Achtung: Dummheit!) Die Änderung wird aufgrund der Lektüre eines Zeitschriftenartikels vorgenommen.
Wenn Sie einen Standardnamen aus Grund 1 ändern müssen, lassen Sie sich davon nicht abhalten. Diese Arten von Änderungen führen selten zu Systeminstabilität, was oft daran liegt, dass sie zuvor getestet wurden.
Wenn Sie eine Standardeinstellung aus Grund 2 ändern, überdenken Sie dies noch einmal. Diese Arten von Änderungen werden fast nie vom Softwarehersteller getestet, und deshalb kann der Hersteller nicht voraussagen, wie das System sich nach der Änderung verhalten wird. Außerdem gibt es meist viel bessere Alternativen, die wirkliche Sicherheit bieten.
Was macht es schon, wenn ein Angreifer einen Kontonamen kennt? Es sind das Kennwort und die Stärke des Kennworts, die den Angreifer von Ihrem System fernhalten. Der Drang, Standardkontonamen wie „Administrator“ und „Gast“ in etwas zu ändern, das nicht so leicht zu erraten ist, ist oft in Wirklichkeit Ausdruck des Wunschs, starke Kennwörter oder Kennsätze zu vermeiden. Beheben Sie das eigentliche Problem (schlechte Geheimnisse), und Sie können Instabilität (infolge der Änderung von Standardnamen) vermeiden.

Sicherheit durch Verschleierung beinhaltet keine Maßnahmen, die nicht zum Verringern eines Problems beitragen. Eine Organisation, die das Network News Transfer-Protokoll (NNTP) an den Grenzroutern blockiert, um Mitarbeiter am Lesen von Newsgroups zu hindern, aber das ausgehende Secure Shell (SSH) zulässt, handelt nicht nach dem Prinzip der Sicherheit durch Verschleierung. Da SSH jedes Protokoll tunneln kann, wird das Problem nicht verschleiert. Die sinnlosen Schutzmaßnahmen, die implementiert wurden, hindern legitime Benutzer lediglich daran, legitime Aufgaben ohne Verstoß gegen die Sicherheitsrichtlinien auszuführen. Solche zwecklosen Maßnahmen bieten keinerlei Sicherheit durch Verschleierung.
Wie das Wort „Sicherheit“ im Ausdruck „Sicherheit durch Verschleierung“ impliziert, bietet die Maßnahme Schutzfunktionen. Ebenfalls impliziert ist aber, und darin liegt das Problem, dass Sie in Wirklichkeit nichts tun, um eine Sicherheitslücke zu beseitigen. (Eine Sicherheitslücke gibt einem Angreifer die Möglichkeit, auf ein System zuzugreifen.)
Angenommen Sie verfügen über einen anfälligen Webserver, der mithilfe einer öffentlich bekannten Sicherheitsanfälligkeit über TCP-Port 80 angegriffen werden kann. Um diese Sicherheitslücke zu schließen, können Sie das beim Webserver vorliegende Problem beheben, oder Sie können ihn abschalten. Durch beide Aktionen würde die Sicherheitslücke beseitigt. Sie könnten die Sicherheitslücke teilweise beseitigen, indem Sie eine Firewall oder IPsec verwenden, um Port 80 für alle außer für einige ausgewählte Computer zu schließen. Dadurch würde die Sicherheitsanfälligkeit nicht vollständig behoben, aber das Problem deutlich verringert.
Sicherheit durch Verschleierung andererseits beinhaltet das Ergreifen von Maßnahmen, durch die die Sicherheitslücke nicht beseitigt, sondern lediglich verborgen wird. Sie können dem Webserver z. B. Port 81 statt Port 80 zuweisen, sodass der Webserver nur von Benutzern gefunden werden kann, denen dies bekannt ist. Das ist zumindest die Idee. Ihrem Webserver Port 81 zuzuweisen, verhindert in Wirklichkeit nur bestimmte Angriffe und verursacht hauptsächlich Unannehmlichkeiten für den Endbenutzer. Ein fähiger Angreifer würde einfach einen Portscanner und einen so genannten Webbannergrabber auf eine große Zahl von Ports ansetzen, um Webserver auf nicht standardmäßigen Ports zu finden. Sobald ein Webserver entdeckt wird, kann über die Sicherheitsanfälligkeit ein Angriff auf den Server durchgeführt werden, weil Sie die Sicherheitslücke nicht wirklich beseitigt, sondern nur (vorübergehend) verschleiert haben.
Bedeutet das, dass Sie es gar nicht erst versuchen sollten? Das kommt ganz darauf an. Wie bei allem im Bereich Informationssicherheit läuft es auf das Risikomanagement hinaus. Um die Hauptfaktoren zu verstehen, die dabei berücksichtigt werden müssen, werfen wir einen kurzen Blick auf einige weitere Maßnahmen im Bereich Sicherheit durch Verschleierung und erörtern dann eine solche Maßnahme – das Umbenennen des Administratorkontos – ausführlicher.

Bewertung von Sicherheitsmaßnahmen
Beispiele für Sicherheit durch Verschleierung sind reichlich vorhanden. Es kann sich um Maßnahmen handeln, die von System- und Netzwerkmanagern oder von Softwareentwicklern ergriffen werden. Alle diese Maßnahmen haben jedoch gemeinsam, dass sie eine Sicherheitsanfälligkeit beseitigen sollen, indem diese vor potenziellen Angreifern verborgen wird.
Könnten nicht einige dieser Verfahren zumindest eine positive Wirkung haben? Ist es wirklich angemessen zu behaupten, dass Sicherheit durch Verschleierung immer schlecht ist? Sie werden sicherlich Befürworter zumindest einiger dieser Maßnahmen finden. In Windows® ist es z. B. möglich, Laufwerkbuchstaben in Windows-Explorer auszublenden. In vielen Umgebungen, besonders in Computerpools von Schulen, werden Benutzer mithilfe dieses Verfahrens daran gehindert, Daten auf der Festplatte zu speichern. Selbstverständlich können die meisten Anwendungen weiterhin Daten auf der Festplatte speichern. Deshalb bietet dieses Verfahren als ultimative Sicherheitsmaßnahme nur geringen Wert. Die Institutionen, die zu dieser Maßnahme gegriffen haben, behaupten aber oft, dass dadurch die Datenmenge auf der Festplatte verringert wurde.
Eine andere Art von Maßnahme im Rahmen von Sicherheit durch Verschleierung, die unter Windows oft implementiert wird, besteht im Abschalten administrativer Netzwerkfreigaben (z. B. C$, Administrator$ usw.). Dadurch soll ein Angreifer daran gehindert werden, von einem Remotestandort aus eine Verbindung zum Computer herzustellen. In Wirklichkeit ist dies nicht nur unrichtig, sondern ein Angreifer, der über ein Konto verfügt, das die administrativen Freigaben verwenden kann, kann von einem Remotestandort aus genau diese Freigaben reaktivieren. Trotzdem bestehen viele Organisationen darauf, dass durch das Deaktivieren dieser Freigaben die Zahl der Fälle von Malware auf ihren Netzwerken verringert wird.
Eines unserer Lieblingsbeispiele für unangebrachte Bemühungen ist die Windows-Einstellung „Entfernen ohne vorherige Anmeldung erlauben“. Wenn diese Einstellung deaktiviert wird, wird die Schaltfläche „Computer abdocken“ nicht im Anmeldebildschirm angezeigt. Die Idee hierbei besteht darin, dass ein Angreifer den Computer dann nicht ordnungsgemäß abdocken kann. Selbstverständlich kann ein Angreifer den Computer und die Dockingstation einfach in eine Tasche stecken und davonspazieren, unabhängig davon, ob die Schaltfläche sichtbar ist oder nicht. Diese Möglichkeit bietet im Grunde nicht einmal Sicherheit durch Verschleierung.
Ein anderes klares Beispiel ist die Einstellung „Serveroperatoren das Einrichten von geplanten Tasks erlauben“. Wie der Name schon sagt, wird Benutzern, die Mitglieder der Gruppe der Serveroperatoren sind, hierdurch ein Planen von Aufgaben ermöglicht. Dies ist ein erhebliches Problem, weil solche Aufgaben u. U. als lokales System ausgeführt werden, und nur Administratoren sollten Aufgaben planen können, die als lokales System ausgeführt werden. Selbstverständlich können sich Serveroperatoren theoretisch durch eine ganze Reihe verschiedener Angriffsmethoden zu Administratoren machen. Sie auf diese Weise am Planen von Aufgaben zu hindern, ist daher ziemlich wertlos.
Trotzdem mögen viele Organisationen diese Einstellung, weil dadurch Technikern ermöglicht wird, als Serveroperatoren statt Administratoren zu agieren, was es weniger wahrscheinlich macht, dass sie unbeabsichtigt den Server zerstören. Dies könnte somit von Vorteil sein.
Wie lautet also der Urteilsspruch? Offensichtlich können einige dieser Probleme äußerst kompliziert sein. Wir haben viele schöne Stunden damit verbracht, diese Arten von Maßnahmen zu diskutieren. Roger Grimes gehört zu denjenigen, die solche Maßnahmen für sinnvoll halten. Jesper Johansson dagegen meint, dass es sich dabei in den meisten Fällen bestenfalls um Zeitverschwendung handelt. Werfen wir einen Blick auf einen der am häufigsten genannten – und diskutierten – Fälle für Sicherheit durch Verschleierung: die Umbenennung des Administratorkontos. Roger Grimes argumentiert für diese Maßnahme, Jesper Johansson dagegen. Die bekannten Sicherheitsexperten Aaron Margosis und Steve Riley kommen in den Randleisten „Umbenennen des Administratorkontos“ und „Kein Ändern von Standardeinstellungen“ ebenfalls zu Wort.

Ausblenden des Administratorkontos
Die Maßnahme, dem Administratorkonto, relativer Bezeichner (RID) 500, einen der Allgemeinheit unbekannten Namen zu geben, wird von Sicherheitsfachleuten oft empfohlen und ist in mehreren Microsoft-Absicherungshandbüchern enthalten. Die Gruppenrichtlinie enthält sogar eine Einstellung zum Umbenennen des Administratorkontos (siehe Abbildung 1). Der Gedanke dabei ist, dass es bei Umbenennung des Administratorkontos für einen Angreifer schwieriger wird, sich als echter Administrator anzumelden. Das offensichtliche Problem beim Verwenden der Gruppenrichtlinie für diesen Vorgang besteht darin, dass das umbenannte Administratorkonto auf jedem Computer, auf den dieses Gruppenrichtlinienobjekt angewendet wurde, den gleichen Namen hat. Dadurch wird der Verschleierungswert dieser konkreten Sicherheitsmaßnahme verringert.
Abbildung 1 Umbenennung des Administratorkontos.
Abbildung 1 Umbenennung des Administratorkontos. (Zum Vergrößern auf das Bild klicken)
In diesem Kontext muss auch erkannt werden, dass jeder Benutzer mit einem legitimen Konto den Namen des Administratorkontos abrufen kann, unabhängig davon, ob es umbenannt wurde oder nicht. Das Administratorkonto hat immer die RID 500. Wenn Benutzer mit einem Konto also einfach nach dem Namen des Kontos mit der RID 500 fragen, können sie den tatsächlichen Namen ermitteln (siehe Abbildung 2).
Abbildung 2 Suchen des umbenannten Administratorkontos
Abbildung 2 Suchen des umbenannten Administratorkontos (Zum Vergrößern auf das Bild klicken)

Der Standpunkt von Roger Grimes
Das mir bekannte Hauptargument gegen das Umbenennen des Administratorkontos lautet, dass es so einfach ist, den Kontonamen eines Sicherheitsprinzipals in seine verwandte Sicherheits-ID (SID) zu konvertieren und die RID zu ermitteln. Das echte Administratorkonto hat immer die RID 500. Was macht es schon, wenn ein Angreifer problemlos Benutzerkontonamen in die SID/RID-Kombination konvertieren und die RID mit dem Wert 500 ermitteln kann?
Aber so einfach ist es nicht. Um Benutzerkontonamen in SID/RID-Kombinationen zu übersetzen, müssen Sie auf die NetBIOS- oder die LDAP-Ports zugreifen können. Die meisten Umkreisfirewalls lassen diese Art von Zugriff über das Internet nicht zu. Solange der Angreifer die Firewall also nicht vollständig umgeht, kann er auch nichts übersetzen. Außerdem funktionieren anonyme SID-Übersetzungen nicht bei Windows XP und höheren Windows-Versionen, außer auf Domänencontrollern (DCs). Bei den meisten von außen zugänglichen Computern (den am meisten gefährdeten) benötigt der Angreifer authentifizierte Anmeldeinformationen, um Namen in SIDs zu übersetzen.
Es gibt eine erhebliche Zahl echter Tiefenverteidigungsmaßnahmen, die umgangen werden müssen, um einen Übersetzungsangriff zu starten. Selbst wenn der Angreifer es so weit schafft, befindet er sich an der gleichen Stelle, an der er auch ohne eine Umbenennung des Kontonamens gelandet wäre. Das Umbenennen des Administratorkontos kann die Sicherheit nur verbessern. Es kann ihr sicherlich nicht schaden.
Ein weiteres Geheimnis Wenn ein Angreifer den Namen des Administratorkontos nicht kennt, wird dieser zu einer weiteren „geheimen“ Bezeichnung, ähnlich wie ein Kennwort, das ein Angreifer kennen muss. Zugegeben, es ist wenig wahrscheinlich, dass Benutzerkontonamen ebenso komplex sind wie ein Administratorkennwort, aber es ist immerhin eine weitere Hürde, die das Ermitteln des Kennworts exponentiell erschwert. Wenn Sie jemals Kennwortpenetrationstests durchgeführt haben, wissen Sie bereits, wie viel mehr Arbeit es erfordert, sowohl den Benutzernamen als auch das Kennwort zu erraten. Dadurch wird eine ohnehin schwierige Aufgabe nur noch schwieriger.
Wehrt automatisierte Malware und Skriptkiddies ab Ich wende seit 22 Jahren Windows-Sicherheitsstrategien an und unterhalte seit 5 Jahren acht Windows-Honeypots, die über das Internet zugänglich sind. In der ganzen Zeit ist es nie vorgekommen, dass automatisierte Malware (die die große Mehrheit aller Angriffsarten darstellt) jemals eine andere Benutzerkontobezeichnung als „Administrator“ (oder „root“ im Fall von *NIX-Systemen) verwendet hätte. Wenn Sie Ihr Administratorkonto umbenennen, wehren Sie damit alle Malware ab, die auf dem Administratornamen basiert. Das ist gleichbedeutend mit einem verringerten Sicherheitsrisiko.
Dasselbe gilt für Skriptkiddies. Jedes „angesagte“ Windows-Hackerhandbuch, das ich kenne, erwähnt Verfahren zur Übersetzung von Namen in SIDs, aber aus irgendeinem Grund habe ich ein solches Verfahren noch nie bei einem meiner Honeypots festgestellt, wenn zur Abwehr auch ein „gefälschtes“ Administratorkonto vorhanden war. Gute Hacker sollten immer überprüfen, ob das Administratorkonto, das sie gefunden haben, das wirkliche Administratorkonto ist (RID 500), aber sie tun es aus unerfindlichen Gründen nicht. Es ist wohl auf die Faulheit der Hacker und auf gewöhnliche menschliche Verhaltensweisen zurückzuführen.
Hält auch die meisten Profis fern Dies ist für die meisten überraschend. Wenn Sie einige Jahre lang Honeypots unterhalten haben, erkennen Sie schnell den Unterschied zwischen automatisierten Angriffen, Skriptkiddies und Profis. In den vergangenen fünf Jahren gab es Millionen gemeldeter Angriffe auf meinen Honeypots, aber Profis haben nie SID-Übersetzung verwendet, wenn das gefälschte Administratorkonto vorhanden war.
Ich bin sicher, dass einige der professionellen Kriminellen SID-Übersetzung verwenden, aber mit Sicherheit ist dies nur eine kleine Minderheit, die mir in der Realität nie begegnet ist. Weshalb tun Profis dies nicht? Sie sehen wohl keinen Grund darin, etwas zu versuchen, das von der Mehrheit der anderen Profis nicht verwendet wird.
Erleichtert Warnungen Die andere Seite mag behaupten, dass das Administratorkonto seinen Wert als Verschleierungsverfahren verlieren würde, wenn ein Umbenennen dieses Kontos weit verbreitet wäre. Das Argument lautet, dass Malware, Skriptkiddies und Profis ihre Standardtaktiken ändern und nach anderen Namen als nur nach „Administrator“ suchen würden. Das ist ein berechtigter Einwand. Glücklicherweise ändert dies nichts am wesentlichen Aspekt. Wenn das extrem privilegierte Windows-Konto nicht „Administrator“ heißt, müssen Hacker härter arbeiten. Das ist eine Tatsache. Wenn Hacker härter arbeiten müssen, ist es etwas weniger wahrscheinlich, dass sie es mit dieser Angriffsmethode versuchen, was vielleicht dazu führt, dass ein anderes Tiefenverteidigungsverfahren schädliche Aktivitäten noch schneller erkennt.
Das führt zu meinem letzten Argument zugunsten des Umbenennens. Wenn Ihr Administratorkonto nie „Administrator“ genannt wird und Sie ein anderes Konto mit diesem Namen erstellen (siehe Abbildung 3), verfügen Sie über einen guten Warnmechanismus. Wenn die Ereignisüberwachung dann eine versuchte Anmeldung mithilfe des Standardnamens erkennt, ist dies ein Ereignis, das sofort untersucht werden sollte.
Abbildung 3 Anmeldeversuche bei einem Köderkonto namens „Administrator“ können als frühe Warnung dienen
Abbildung 3 Anmeldeversuche bei einem Köderkonto namens „Administrator“ können als frühe Warnung dienen (Zum Vergrößern auf das Bild klicken)
Unsere Ereignisprotokolle sind voll von „falschen“ Anmeldungen, die nichts bedeuten. In der Regel sind es nur Benutzer (oder Windows), die versuchen, sich mithilfe eines falschen Kennworts oder Ähnlichem anzumelden. Wenn Ihr Administratorkonto aber den Namen „Administrator“ trägt, wie können Sie dann problemlos ordnungsgemäße Anmeldeversuche von Anmeldeversuchen eines Angreifers unterscheiden? Wenn Sie kein Anmeldekonto namens „Administrator“ haben und eine versuchte Anmeldung mithilfe dieses Kontonamens feststellen, wissen Sie, dass wahrscheinlich eine böswillige Absicht dahintersteckt. Frühe unauffällige Warnungen sind heutzutage für Sicherheitsbelange von großem Wert.

Die Meinung von Jesper Johansson
„Umbenennen des Administratorkontos“ von Aaron Margosis
In einer idealen Welt hätte Jesper Johansson vollkommen Recht. Kennwörter wären immer stark genug, um ein Erraten durch Brute-Force-Angriffe unmöglich zu machen, und lokale Administratorkonten mit der RID 500 würden ausschließlich für die Notfallwiederherstellung verwendet. In der Praxis trifft aber keines von beidem zu.
Obwohl Jesper Johansson so viel Öffentlichkeitsarbeit im Interesse der Sicherheit geleistet hat, und insbesondere angesichts seiner großartigen Artikelreihe zu Kennsätzen („Die großen Debatten: Kennsätze oder Kennwörter“, Teile 1, 2 und 3, unter go.microsoft.com/fwlink/?LinkId=113157, go.microsoft.com/fwlink/?LinkId=113159 und go.microsoft.com/fwlink/?LinkId=113160), wissen viele Systemadministratoren nicht, was heutzutage ein starkes Kennwort ausmacht.
Vor nicht allzu langer Zeit war ein Kennwort, das aus acht zufälligen Zeichen aus mehreren Zeichensätzen bestand, ein starkes Kennwort. Aufgrund des Mooreschen Gesetzes ist diese Auffassung veraltet. Die Schulung von Benutzern (und Systemadministratoren) ist ein Schwachpunkt und wird dies höchstwahrscheinlich auch bleiben, zumindest so lange wie das Thema Kennwortstärke nicht in den Schlagzeilen der Kabelnachrichtenkanäle erscheint.
In Anbetracht der Tatsache, dass das Erraten eines Kennworts in der heutigen Praxis keine 600 Milliarden Jahre dauert, sondern oft während der Mittagspause durchgeführt werden kann, kann das Hinzufügen des Faktors 1.000 wirklich nützlich sein. Ein Umbenennen würde das Administratorkonto für die vielen automatisierten Angriffe, die auf das Konto abzielen, unverwundbar machen.
Der Zeit- und Arbeitsaufwand, der in der Regel mit dem Umbenennen des Administratorkontos verbunden ist, ist meist gering. Wie bereits erwähnt, ist dafür meist nur eine einfache GPO-Einstellung erforderlich. Der Federal Desktop Core der US-Regierung (csrc.nist.gov/fdcc) erfordert in der Tat ein Umbenennen des Kontos mit der RID 500. Das Umbenennen ist nur eine von vielen erforderlichen Einstellungen und keine, die nach meiner Erfahrung übermäßig viel Zeit oder Aufmerksamkeit erfordert. Mir ist auch nicht bekannt, dass jemand deshalb ein falsches Gefühl der Sicherheit entwickelt hätte – ich habe noch nie jemanden sagen hören: „Wir benötigen keine Patchverwaltung, weil wir unsere Administratorkonten umbenannt haben.“
Ist das Umbenennen von Nutzen, wenn das Konto in der gesamten Organisation den gleichen Namen erhält? Der Nutzen ist nicht groß, aber vorhanden: Zum einen werden automatisierte Angriffe, die den Namen „Administrator“ erwarten, dadurch blockiert, und zum anderen ist die Menge potenzieller Angreifer nicht unbedingt eine Teilmenge all derer, die den neuen Namen kennen. (Das größere Risiko besteht, wenn lokale Administratorkonten – ob umbenannt oder nicht – innerhalb einer Organisation das gleiche Kennwort verwenden. Ihre Verwaltung bleibt das größere und wichtigere Problem. Das Konto mit der RID 500 zu deaktivieren, ist eine Möglichkeit zur Behandlung des Problems, aber dadurch wird eine wichtige Wiederherstellungsmethode blockiert, wenn Domänenkonten nicht verwendet werden können.) Es soll auch darauf hingewiesen werden, dass unsere Sicherheitshandbücher seit langem das Umbenennen von Standardkonten empfehlen. Deshalb wurde diese Maßnahme gründlich getestet und wird vollständig unterstützt.
Es ist inzwischen wohl allgemein bekannt, dass Verschleierungsmaßnahmen für sich allein keine angemessene Verteidigung darstellen. Dadurch können jedoch andere Sicherheitsmaßnahmen unterstützt werden, und die Daten von Roger Grimes zeigen dies recht deutlich. Solange die Implementierungskosten gering sind, sollten Organisationen diese Maßnahmen in Erwägung ziehen.

Es gibt nicht nur Argumente für, sondern auch gegen das Umbenennen des Administratorkontos. Bevor ich darauf eingehe, muss ich aber zugestehen, dass das letzte Argument von Roger Grimes ziemlich plausibel ist. In einer intensiv verwalteten Umgebung sollte aber jede Anmeldung beim Administratorkonto untersucht werden, weil dieses Konto wirklich nur für eine Notfallwiederherstellung dient.
Es ist überflüssig Das Hauptrisiko, das durch das Umbenennen des Administratorkontos verringert werden soll, besteht darin, dass jemand das entsprechende Kennwort von einem Remotestandort aus erraten könnte. Es würde aber nur ein Benutzer, der kein anderes autorisiertes Konto auf dem Computer besitzt, durch das Umbenennen des Administratorkontos ferngehalten werden. Solch ein Angreifer versucht in der Regel, sich mithilfe einer Reihe zufälliger Kennwörter beim Administratorkonto anzumelden. Er erhält dabei aber stets die gleiche Fehlermeldung, unabhängig davon, ob er den Kontonamen oder das Kennwort falsch geraten hat.
Daraus folgt, dass eines der Hauptargumente für das Umbenennen des Administratorkontos – dass die Skriptkiddies ferngehalten werden – fehlerhaft ist. Es spielt keine Rolle, ob das Administratorkonto umbenannt wurde oder ob es noch den ursprünglichen Namen trägt, weil der Unterschied nicht festgestellt werden kann! Die Skriptkiddies verwenden in beiden Fällen den gleichen Satz zufälliger Kennwörter und wenden sich dann dem nächsten potenziellen Opfer zu.
Ein Umbenennen des Kontos bietet also keinen zusätzlichen Nutzen, solange das Kennwort des Administratorkontos stark genug ist, um Angriffe abzuwehren. Angenommen das Administratorkonto hätte ein aus 15 Zeichen bestehendes Kennwort, das sich aus Groß- und Kleinbuchstaben, Ziffern und Symbolen der Tastatur zusammensetzt. Das Erraten dieses Kennworts über das Netzwerk würde ungefähr 591.310.404.907 Jahre dauern. Das ist ungefähr 43 Mal länger als das Universum alt ist.
Weiterhin wird angenommen, dass das Administratorkonto umbenannt und ihm einer von 1.000 möglichen Namen zugewiesen wird. Die Zeit, die für das Erraten des Kennworts erforderlich ist, würde damit auf 591.310.404.906.787 Jahre verlängert. Das ist 43.161 Mal so lange wie das Universum bereits existiert. Bietet dies erhöhte Sicherheit? Ja, die Sicherheit erhöht sich um drei Zehnerpotenzen. Wird es dadurch weniger wahrscheinlich, dass ein Angreifer das Kennwort errät? Die Wahrscheinlichkeit ist beiden Fällen unendlich klein. Praktisch gesehen stehen Sie nicht besser da als mit dem ursprünglichen Administratorkontonamen. Nur weil durch das Umbenennen des Kontos Malware abgewehrt wird, die versucht, dieses Konto zu verwenden, bedeutet das nicht, dass diese Malware erfolgreich gewesen wäre, hätten Sie das Konto nicht umbenannt. Wenn Sie ein starkes Kennwort verwenden, wie es empfohlen wird, können Sie praktisch garantieren, dass ein Malwareangriff keinen Erfolg hat, unabhängig vom Namen des Kontos.
In vielen Sicherheitsleitfäden wird ein Umbenennen des Administratorkontos gefordert, aber das macht es nicht zu einer nützlichen oder berechtigten Sicherheitsmaßnahme. Es nimmt Ihnen einfach die Möglichkeit, eine fundierte Entscheidung für das Risikomanagement zu treffen. Sicherheitshandbücher fordern oft Einstellungen, die keinen Unterschied machen, und in vielen Fällen sogar Einstellungen, die gar nicht existieren. Um Verbesserungen im Bereich Sicherheit zu erzielen, müssen Sie diese Forderungen überdenken, die Probleme analysieren sowie einschätzen, ob die Schutzmaßnahmen wirklich sinnvoll sind. An dieser Stelle sollten Sie sich einen wichtigen Punkt in Erinnerung rufen – die Tatsache, dass ein Angreifer auf ein Feature abzielt, ist für sich allein kein ausreichender Grund, das Feature zu ändern. Sie sollten ein Feature nur ändern, wenn Sie berechtigterweise erwarten können, dass ohne Änderung des Features ein erfolgreicher Angriff durchgeführt werden kann.
Unter Verwendung eines starken Kennworts ist die Erfolgswahrscheinlichkeit praktisch null, unabhängig davon, ob das Konto umbenannt wurde oder nicht. Solange Sie also ein starkes Kennwort verwenden, haben Sie keinen Grund, das Konto umzubenennen. Wenn Sie außerdem wie ich nach dem Prinzip vorgehen, dass ein Computer wahrscheinlich umso stabiler ist, je weniger Feinabstimmungen und Änderungen vorgenommen werden (was eine wohlbelegte Tatsache ist), ist das ein weiterer Grund, das Administratorkonto nicht umzubenennen.
Verschieben des Schwerpunkts auf Schutzmaßnahmen mit geringem Nutzen Ein Problem bei geringwertigen Schutzmaßnahmen durch Verschleierung besteht darin, dass sich der Schwerpunkt der Sicherheitsstrategie von Organisationen dadurch möglicherweise so verlagert, dass höherwertige Schutzmaßnahmen vernachlässigt werden. Der Zeit und die Arbeit, die in das Umbenennen des Administratorkontos investiert wird, kann nicht für andere Aufgaben verwendet werden. Wenn diese anderen Aufgaben einen höheren Nutzen bieten als das Umbenennen der Administratorkonten, hat die Organisation eine Gelegenheit verschenkt. Dies mag nicht nach wirklichen Kosten klingen, aber stellen Sie sich einmal vor, es müssten 50.000 Administratorkonten umbenannt werden.
Noch schlimmer ist die sehr reale Möglichkeit, dass die Organisationsleitung ihre Bemühungen ruhen lässt, sobald die Schutzmaßnahmen mit geringem Nutzen implementiert sind. Die Verantwortlichen für das Management verstehen möglicherweise nicht immer den geringen Wert, den Schutzmaßnahmen nach dem Prinzip Sicherheit durch Verschleierung bieten, und unterlassen es, zusätzliche Maßnahmen zu ergreifen. Dies stellt für eine Organisation möglicherweise ein erhebliches Risiko dar. Dieses Risiko lässt sich aber durch Einsatz von etwas Zeit und Arbeit von Seiten des Managements, um den Nutzen der Schutzmaßnahmen zu verstehen, relativ leicht vermeiden.
Teure Verwaltung Abhängig davon, wie gut die Schutzmaßnahmen implementiert werden, kann ihre Verwaltung ziemlich teuer sein. Wenn Sie einfach ein Gruppenrichtlinienobjekt (Group Policy Object, GPO) für das Umbenennen des Administratorkontos einrichten, sind die Kosten sehr gering. Jeder kennt den Namen, und die Kosten der Bereitstellung sind nahezu null. Der Nutzen ist allerdings ebenfalls ziemlich gering, weil, wie gesagt, jeder Benutzer mit einem Konto den Namen kennt. Um also wirklich großen Nutzen aus diesen Schutzmaßnahmen zu ziehen, müssen Sie verschiedene Namen auf verschiedenen Hosts verwenden, und das macht die Verwaltung des Systems ziemlich teuer.
Erheblich besser wäre es, wenn Sie mithilfe eines Tools wie „passgen“ (protectyourwindowsnetwork.com/tools.htm) auf allen Administratorkonten im Netzwerk ein vollkommen zufälliges Kennwort aus 100 Zeichen einrichten und verschiedene Konten für alltägliche Verwaltungsaufgaben verwenden. In Anbetracht der Tatsache, dass das Administratorkonto allein für die Notfallwiederherstellung gedacht ist (außer unter Windows Small Business Server 2003), dürfte dies keinerlei Einfluss auf Ihr Netzwerkverwaltungssystem haben. Außerdem hätte der Angreifer bessere Chancen, eine Nadel auf dem Grund des pazifischen Ozeans zu finden, als das Kennwort eines Ihrer Administratorkonten zu erraten. Bei Verwendung starker, eindeutiger Kennwörter können die Skriptkiddies raten, solange sie wollen.

Alles dreht sich um das Risikomanagement
Praktisch jede Maßnahme nach dem Prinzip Sicherheit durch Verschleierung kann so analysiert werden, wie es hier erfolgt ist. Es gibt Argumente für und gegen jedes Schema, und der richtige Ansatz für eine Organisation ist nicht unbedingt auch für eine andere Organisation geeignet. Letzen Endes handelt es sich um ein Risikomanagementproblem. Überwiegen die Risiken die Implementierungskosten für die Lösung? Jede Entscheidung, die Sie beim Schutz Ihrer Informationsressourcen treffen, muss eine informierte Risikomanagemententscheidung sein, und es ist selten eine Frage von Schwarz oder Weiß.
Einige Entscheidungen wurden zwar bereits für Sie getroffen. Sie können sich z. B. dafür entscheiden, Kreditkarteninformationen nicht zu verschlüsseln oder die Überprüfungscodes von Kreditkarten nicht zu speichern, allerdings nehmen Ihnen beide Maßnahmen wahrscheinlich die Möglichkeit, Kreditkarten als Zahlungsmethode zu akzeptieren. Die negativen Auswirkungen dieser Entscheidung auf Ihr Geschäft lassen Ihnen hierbei wahrscheinlich keine Wahl. Dies ist also sicherlich eine Risikomanagemententscheidung, die sich ziemlich leicht treffen lässt.
Ebenso stimmt es auch, dass niemand, der noch bei Trost ist, ein offenes Drahtlosnetzwerk mit dem Back-End des speicherinternen Netzwerks in einem physischen Speicher verbinden würde. Das bedeutet aber nicht, dass die Entscheidung keine Risikomanagemententscheidung ist. Sie ist es. Wenn eine solche Entscheidung getroffen wird, müssen eben die Konsequenzen getragen werden (was leider nie der Fall zu sein scheint).
Der wichtigste Schritt besteht hierbei darin, das vorliegende Problem, die vorgeschlagenen Problemlösungen sowie die Argumente für und gegen jede Lösung eingehend zu untersuchen. Nur so erhalten Sie die Informationen, die für eine informierte Risikomanagemententscheidung erforderlich sind. Andernfalls treffen Sie Entscheidungen einzig und allein auf der Grundlage von Vermutungen, und das sind selten gute Entscheidungen.

Jesper M. Johansson ist Softwarearchitekt mit dem Schwerpunkt Sicherheitssoftware und schreibt redaktionelle Beiträge für das TechNet Magazin. Er hat seine Doktorarbeit zum Thema Management Information Systems geschrieben, verfügt über mehr als 20 Jahre Erfahrung auf dem Gebiet der Sicherheit und ist Microsoft MVP im Bereich Unternehmenssicherheit. Sein aktuelles Buch heißt Windows Server 2008 Security Resource Kit.
Roger Grimes (CPA, CISSP, MCSE: Sicherheit), leitender Sicherheitsberater für das Microsoft-ACE-Team, hat acht Bücher über Computersicherheit geschrieben oder mitverfasst und mehr als 200 Artikel veröffentlicht. Er hält oft Vorträge auf Sicherheitskonferenzen und schreibt für InfoWorld Beiträge zum Thema Sicherheit.
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


Sicherheit
Neue Elevation PowerToys für Windows Vista
Michael Murgolo
Auf einen Blick:
  • „Run as Administrator“ (Ausführen als Administrator) für Skripterstellungstools von Drittanbietern
  • „Run as Another User“ (Ausführen als anderer Benutzer)
  • „Prompt Here as System“ für CMD und Windows PowerShell
  • Drag & Drop-Elevation-Gadget
Laden Sie den Code für diesen Artikel herunter: Elevation2008_06.exe (197KB)

Willkommen bei einer neuen Ausgabe der Elevation PowerToys für Windows Vista. In der Ausgabe des TechNet Magazins vom Juni 2007 wurde dies bereits eingehend besprochen. Seitdem ist ein Jahr vergangen. Diesmal erfahren Sie, wie die Funktion „Run as Administrator“ für einige
meiner bevorzugten Skripterstellungstools von Drittanbietern erweitert wird und wie ein nützliches Windows® XP-Feature, das in Windows Vista® entfernt wurde, ersetzt werden kann. Zusätzlich finden Sie hier Informationen zu einigen nützlichen Tools, die in den Elevation PowerToys enthalten sind.

„Run as Administrator“ für zusätzliche Skripterstellungstools
Bei einem Thema, das im vorherigen Artikel erörtert wurde (er kann unter technet.microsoft.com/magazine/cc162321.aspx eingesehen werden), ging es um das Aktivieren der Option „Run as Administrator“ bei systemeigenen Windows-Skripterstellungstools. Für diesen Artikel wurden „Run as Administrator“-PowerToys für eine Reihe von Skripterstellungstools von Drittanbietern erstellt:
  • AutoIt v3 (www.hiddensoft.com)
  • AutoHotkey (www.autohotkey.com)
  • ActivePerl (www.activestate.com)
  • KiXtart 2010 (www.kixtart.org)
Der Code ist jeweils im Download für diesen Artikel enthalten. Sie finden Ihn unter technetmagazine.com. Die eigentlichen Dateien heißen „ElevateAutoIt3.inf“, „ElevateAutoHotKey.inf“, „ElevatePerlScript.inf“ und „ElevateKiXtart.inf“. Für AutoIt v3, AutoHotkey und ActivePerl ist die Einrichtung recht einfach. Laden Sie die entsprechende Anwendung herunter, und installieren Sie sie am Standardspeicherort. Nach dem Installieren der für Sie interessanten Anwendungen können Sie das entsprechende „Run as Administrator“-PowerToy für das jeweilige Tool installieren.
Leider stellt KiXtart 2010 kein Installationsprogramm bereit. Um sicherzustellen, dass KiXtart an einem Standardspeicherort installiert wird, damit das PowerToy richtig funktioniert, habe ich eine INF-Datei bereitgestellt, mit der KiXtart 2010 (V 4.60) unter Programme\KiXtart installiert und die .kix-Dateierweiterung registriert wird.
Besuchen Sie www.kixtart.org/?p=downloads, laden Sie KiX2010_460.zip herunter, und entpacken Sie die .zip-Datei in einem Ordner. Kopieren Sie die Install_KiXtart.inf-Datei in denselben Ordner (diese Datei ist im Codedownload zu diesem Artikel enthalten). Dann klicken Sie mit der rechten Maustaste auf Install_KiXtart.inf und wählen „Install“ aus. Anschließend kann das ElevateKiXtart.inf-PowerToy einfach installiert werden.

„Run as Another User“-PowerToy
Die Benutzerkontensteuerung (User Account Control, UAC) wurde erstellt, damit das Betriebssystem gegenüber Malware weniger anfällig ist, indem die Benutzer (selbst Administratoren) die meisten Anwendungen mit Standardbenutzerberechtigungen ausführen. UAC bietet Erhöhungspotenzial für administrative Aufgaben und andere Anwendungsfunktionen. Dieses Erhöhungspotenzial wird mithilfe der Option „Run as Administrator“ bereitgestellt, die durch Klicken mit der rechten Maustaste auf ausführbare Dateien aufgerufen wird. Mit den Elevation PowerToys, die in der Ausgabe vom Juni 2007 vorgestellt wurden, wurde diese Funktion für andere Datei- und Objekttypen erweitert.
Die in Windows Vista integrierte Funktion arbeitet für viele administrative Aufgaben sehr gut. Doch ein wichtiges Szenario wurde bei Windows Vista ausgelassen. In vielen IT-Abteilungen gibt es eine Richtlinie, nach der Netzwerkadministratoren ein Benutzerkonto für ihre alltäglichen Aufgaben (Verwenden von E-Mail, Erstellen von Dokumenten und ähnliches) verwenden und ein anderes Konto nur für die Netzwerkverwaltung (oder lokale Computerverwaltung).
Dadurch soll das Risiko gesenkt werden, dass ein Netzwerkadministrator bei seinen alltäglichen Aufgaben unbeabsichtigt Malware ausführt, wodurch sein gesamtes System oder die Domäne, in der er sich befindet, beeinträchtigt würde. Dies wurde in Windows XP mithilfe der Option „Ausführen als...“ erzielt, die mit der rechten Maustaste aufgerufen wurde. Doch diese Option ist in Windows Vista nicht mehr vorhanden, da sie durch die Option „Ausführen als Administrator“ ersetzt wurde.
Das runas-Befehlszeilentool ist jedoch in Windows Vista immer noch vorhanden. Leider kann es für die häufigsten Doppelkontoaufgaben (das Ausführen von Snap-Ins der Microsoft® Management Console (MMC)) nicht verwendet werden. Ein Beispiel: Angenommen, es wurden einige Kontenverwaltungsaufgaben in Active Directory® an Sie delegiert. Sie führen Ihre alltäglichen Aufgaben als Standardbenutzer aus, und Ihr Netzwerkverwaltungskonto ist auch Mitglied der lokalen Administratorgruppe auf einem Windows Vista-Computer, bei dem UAC aktiviert ist (damit Sie bei Bedarf Netzwerkverwaltungstools installieren können). Sie möchten nun Active Directory User & Computer (ADU&C) mit Ihrem Active Directory-Administratorkonto starten. Sie versuchen es wie folgt mit dem runas-Befehl:
runas /user:mydomain\admin
"mmc.exe %windir%\system32\dsa.msc"
Leider wird ADU&C dadurch nicht gestartet. Stattdessen erhalten Sie die runas-Fehlermeldung „Der angeforderte Vorgang erfordert erhöhte Rechte.“ In diesem Fall geschieht Folgendes: Die ausführbare MMC-Datei ist so gekennzeichnet, dass sie auf der highestAvailable-Berechtigungsstufe ausgeführt wird. Da „Administrator“ die highestAvailable-Ebene für Ihr Netzwerkverwaltungskonto ist, wäre für das Starten von ADU&C auf diese Weise eine Erhöhung erforderlich. Da „runas“ keine Aufforderung zur Erhöhung gibt, kommt es zu diesem Fehler.
Windows Vista erschwert dieses Szenario also, indem kein Kontextmenüelement für „Ausführen als...“ und keine integrierten Möglichkeiten zum Ausführen eines Prozesses als anderer Benutzer bereitgestellt werden, für den Erhöhung erforderlich ist.
Dieser Artikel wäre sehr frustrierend, wenn es dafür keine Lösung gäbe, doch glücklicherweise stellt eins meiner ursprünglichen Elevation PowerToys die Lösung für das zweite Problem bereit, und auch für das erste wurde eine Lösung gefunden. (Leider habe nicht ich die Lösung für das Erhöhungsproblem gefunden, sondern Gov Maharaj im Windows AppCompat-Team.)
Wie sich herausstellt, kann das Elevate Command PowerToy mit dem runas-Befehl verwendet werden. Da der vorherige Befehl bei der Aufforderung für erweiterten Zugriff versagt hat, wird die Aufforderung nun folgendermaßen ausgelöst:
runas /user:mydomain\admin
"elevate mmc.exe%windir%\system32\dsa.msc"
Dies führt dazu, dass „runas“ elevate.cmd als anderer Benutzer startet (technisch gesehen handelt es sich bei dem gestarteten Prozess um cmd.exe), und der elevate-Befehl sorgt dafür, dass mmc.exe mit einer Aufforderung für erweiterten Zugriff gestartet wird.
Schließlich habe ich diesen Trick mit den Dateizuordnungen für .exe- und .msc-Dateien kombiniert und ihn mit einer HTML-Anwendungsoberfläche versehen, um ein PowerToy zu erstellen, das die Option „Run as Another User“ erstellt, die über das Kontextmenü zugänglich ist. Wenn Sie „Run as Another User“ auswählen, erhalten Sie eine HTML-Anwendung wie die in Abbildung 1 dargestellte.
Abbildung 1 Tool für „Run as Another User“
Abbildung 1 Tool für „Run as Another User“ (Zum Vergrößern auf das Bild klicken)
Hier geben Sie einfach nur den Benutzernamen und die Domäne ein. Für ein Konto auf dem lokalen Computer aktivieren Sie das Kontokontrollkästchen „Use Local Account“ (Lokales Konto verwenden). Dann kann die Anwendung durch Klicken auf die Schaltfläche „Ausführen“ als Standardbenutzer ausgeführt werden. Alternativ klicken Sie auf die Schaltfläche „Run as Admin“, um die Anwendung mit erhöhten Berechtigungen zu starten. Nach dem Klicken auf eine der beiden Schaltflächen wird runas.exe ausgeführt und eine Aufforderung zur Eingabe eines Kennworts oder einer Smartcard-PIN angezeigt.
Da dieses PowerToy das Elevate Command PowerToy verwendet, muss dieses zuerst installiert werden. Dann klicken Sie mit der rechten Maustaste auf die RunAs.inf-Datei, wählen „Install“ aus und genehmigen die Erhöhung. Zum Deinstallieren des Tools verwenden Sie das Dienstprogramm für Programme und Features in der Systemsteuerung.
Sie werden feststellen, dass einige Verknüpfungen mit .msc-Dateien in der Verwaltung (beispielsweise die Computerverwaltung) mit diesem PowerToy funktionieren. Beachten Sie jedoch Folgendes: Wenn die Windows Server® 2003-Verwaltungstools mithilfe von adminpak.msi installiert werden, sind die erstellten Verknüpfungen keine Standardverknüpfungen mit den .msc-Dateien. Vielmehr handelt es sich um Windows Installer-Verknüpfungen, und daher zeigt Windows-Explorer die Option „Run as Another User“ für diese Verknüpfungen nicht an.
Für diese Verknüpfungen müssen Sie entweder die eigentlichen .msc-Dateien suchen und mit der rechten Maustaste auf sie klicken oder neue Verknüpfungen zu den .msc-Dateien erstellen. Außerdem funktioniert „runas“ nicht mit Internet Explorer® aufgrund der Art und Weise, wie Internet Explorer für den geschützten Modus in Windows Vista neu entworfen wurde (zusätzliche Informationen dazu finden Sie unter support.microsoft.com/?id=922980).
Hinweis: Seit dem Abschluss meiner Arbeiten an diesen PowerToys und der Veröffentlichung dieses Artikels hat Windows Sysinternals ein neues Tool veröffentlicht, dessen Funktion meinem „Run as Another User“-PowerToy sehr ähnelt. Es heißt ShellRunas. Sie finden es auf der Windows Sysinternals-Website: technet.microsoft.com/sysinternals/cc300361.
Da die Mitarbeiter bei Sysinternals ihren Lebensunterhalt mit dem Schreiben von Code verdienen, bevorzugen Sie möglicherweise ihr Tool. Ich habe entschieden, mein Tool in diesem Artikel als Beispiel dafür zu belassen, wie diese Aufgabe im Besonderen und Shellerweiterungen im Allgemeinen mithilfe von HTML-Anwendungen mit Skriptcode durchgeführt werden können.

CMD- und PowerShell-„Prompt Here as System“
Hin und wieder ist es erforderlich, Programme im Kontext „Lokales System“ auszuführen. So verwenden viele Softwareverteilungstools, z. B. System Center Configuration Manager (SCCM), einen Client-Agent, der zum Durchführen seiner Aufgaben als „Lokales System“ ausgeführt wird.
Um das Verhalten eines Softwareinstallationsprogramms zu testen, das als „Lokales System“ ausgeführt wird, bevor versucht wird, eine Verteilung mit einem Produkt wie SCCM durchzuführen, kann es hilfreich sein, das Installationsprogramm mithilfe einer Eingabeaufforderung zu starten, die als „Lokales System“ ausgeführt wird. Daher habe ich die CMD- und PowerShell-„Prompt Here as System“-PowerToys erstellt.
In Windows XP konnte eine solche Funktion mit einem Befehlsshellskript durchgeführt werden:
@echo off
sc create CmdAsSystem type= own type= interact
binPath= "cmd /c start cmd /k (cd c:\ ^& color ec ^&
title ***** SYSTEM *****)"
net start CmdAsSystem
sc delete CmdAsSystem
Wenn Sie jedoch versuchen, diese Funktion in Windows Vista von einer erhöhten Eingabeaufforderung aus auszuführen, erhalten Sie folgende Fehlermeldung, und die Eingabeaufforderung, die als „System“ ausgeführt wird, wird nicht angezeigt:
WARNUNG: Der Dienst "CmdAsSystem" ist als interaktiver Dienst konfiguriert, dessen Unterstützung abgelehnt wurde. Die einwandfreie Funktion des Dienstes ist nicht gewährleistet.
Das Problem besteht darin, dass dieses Skript versucht, einen interaktiven Dienst zu erstellen und zu starten. Interaktive Dienste funktionieren aufgrund der Sitzung 0-Isolierung in Windows Vista nicht richtig. (Eine Erläuterung der Sitzung 0-Isolierung finden Sie im Whitepaper „Dienste in Windows Vista “, das unter microsoft.com/whdc/system/vista/Vista_Services.mspx verfügbar ist.)
Zur Problemumgehung habe ich das von Sysinternals entwickelte Psexec-Tool verwendet (siehe technet.microsoft.com/sysinternals/bb897553.aspx). Mithilfe dieses Tools können Prozesse im Kontext „System“ gestartet werden. Leider enthalten die meisten Sysinternals-Tools kein Installationsprogramm. Daher habe ich eine INF-Datei (verfügbar im Codedownload) zum Installieren der gesamten Sysinternals-Suite (einschließlich Psexec) in Programme\Sysinternals Suite bereitgestellt. Als Zugabe erstellt diese INF-Datei Startmenüverknüpfungen für die grafischen Tools der Suite.
Zum Installieren der Suite laden Sie zuerst SysinternalsSuite.zip von technet.microsoft.com/sysinternals/bb842062.aspx herunter und entpacken die .zip-Datei in einem Ordner. Kopieren Sie die INF-Datei (Install_SysinternalsSuite.inf) in diesen Ordner, klicken Sie mit der rechten Maustaste auf Install_SysinternalsSuite. inf, und wählen Sie „Install“ aus. Da diese neuen PowerToys das Elevate Command PowerToy verwenden, installieren Sie es als Nächstes. Anschließend können Sie CmdHereAsSystem.inf und PowerShellHereAsSystem.inf installieren. Nach der Installation dieser PowerToys stehen Ihnen die Optionen „CMD Prompt Here as System“ und „PowerShell Prompt Here as System“ zur Verfügung, die über das Kontextmenü für Ordner und Laufwerke in Windows-Explorer zugänglich sind, wie in Abbildung 2 dargestellt.
Abbildung 2 Die Optionen „CMD Prompt Here as System“ und „PowerShell Prompt Here as System“
Abbildung 2 Die Optionen „CMD Prompt Here as System“ und „PowerShell Prompt Here as System“
Abbildung 3 zeigt eine CMD-Eingabeaufforderung, die als System ausgeführt wird. Ich habe die hellen Farben als Erinnerung daran ausgewählt, dass diese Eingabeaufforderung als „System“ ausgeführt wird und unerwartete (und gefährliche) Folgen im System nach sich ziehen kann, wenn die falschen Befehle eingegeben werden.
Abbildung 3 „CMD Prompt as System“ muss verantwortungsbewusst verwendet werden.
Abbildung 3 „CMD Prompt as System“ muss verantwortungsbewusst verwendet werden.
Schließlich fügen diese PowerToys dem System Befehle hinzu, sodass diese Eingabeaufforderungen im Dialogfeld „Ausführen“ oder als CMD-Eingabeaufforderung ausgeführt werden können. So startet beispielsweise das Ausführen des folgenden Befehls im Feld „Ausführen“ eine CMD-Eingabeaufforderung als „System“ im Windows-Ordner:
cmdassystem "c:\windows"
Der entsprechende Befehl für Windows PowerShellTM ist „psassystem“. Beachten Sie, dass auch die CMD- und PowerShell-„Prompt Here as Administrator“-PowerToys geändert wurden, um ähnliche Befehle zu installieren („cmdasadmin“ bzw. „psasadmin“).

Elevation-Gadget
Für die meisten der PowerToys ist das Klicken mit der rechten Maustaste erforderlich. Doch als Zugabe zu dieser Aktualisierung finden Sie hier etwas, das mehr Spaß macht. Es handelt sich dabei um ein Gadget in der Windows-Sidebar, das ich als Elevation-Gadget bezeichne (dargestellt in Abbildung 4). Es wird mit Drag & Drop ausgeführt. Ziehen Sie einfach eine ausführbare Datei oder ein Skript aus dem Windows-Explorer, bei dem eine runas-Aktion definiert ist, und es wird als erhöht gestartet.
Abbildung 4 Das Drag & Drop-Elevation-Gadget
Abbildung 4 Das Drag & Drop-Elevation-Gadget
Wenn Sie die vorherigen Elevation PowerToys installiert haben, funktioniert dies für Windows Script Host-Skripts, Windows PowerShell-Skripts, HTML-Anwendungen und Windows Installer-Pakete und -Patches (sowie für ausführbare Dateien und Befehlsshellskripts, für die standardmäßig eine runas-Aktion in Windows Vista definiert ist). Zudem können Sie gleichzeitig mehr als ein Element auf einmal ziehen. (Versuchen Sie einmal, einen Ordner auf das Gadget zu ziehen, um zu sehen, was geschieht.)
Zum Installieren des Gadget doppelklicken Sie auf Elevation.gadget (verfügbar im Codedownload). Wenn Sie sich den Code für das Gadget ansehen möchten, fügen Sie dem Dateinamen einfach die .cab-Erweiterung hinzu. Dann können Sie den Inhalt der Cab-Datei extrahieren.

Zusammenfassung
Der Download für diesen Artikel enthält sowohl die neuen PowerToys als auch die aus dem ursprünglichen Artikel. An den alten wurden kleine Änderungen vorgenommen. So installierten beispielsweise die ursprünglichen Versionen von Windows PowerShell-„Prompt Here as Administrator“ und „Elevate WSH Script“ beide ihre eigenen Kopien von elevate.cmd und elevate.vbs. Da diese Dateien auch für mehrere neue PowerToys erforderlich sind, wurden diese Tools so geändert, dass für sie das Elevate Command PowerToy installiert werden muss (beide verwenden dann diese Kopie). Um festzustellen, ob für ein PowerToy die Installation von Elevate Command PowerToy erforderlich ist, prüfen Sie den Header in der INF-Datei.
An einigen anderen ursprünglichen PowerToys wurden ebenfalls geringfügige, nicht funktionale Änderungen vorgenommen. Deinstallieren Sie immer die alte Version eines PowerToy, bevor Sie die aktuelle Version installieren. Da diese Sammlung nun auf 17 Tools angewachsen ist, sind Befehlsshellskripts zum Installieren und Deinstallieren der gesamten Sammlung beigefügt (InstallAllPowerToys.cmd bzw. UninstallAllPowerToys.cmd). Sie können angepasst werden, sodass nur die Tools, die Sie brauchen, installiert und deinstalliert werden.
Bedenken Sie, dass durch InstallAllPowerToys.cmd nicht standardmäßig die „Run as Administrator“-PowerToys für Skripterstellungstools von Drittanbietern installiert werden. Sie können dieses Skript so ändern, dass nur die PowerToys installiert werden, für die Sie die Software installiert haben. Wenn Sie eins der beiden Skripts ausführen, wird es als erhöht neu gestartet. Mit UninstallAllPowerToys.cmd werden alle alten Versionen dieser Tools ebenfalls entfernt.
Wie bei allen PowerToys gilt: Diese Tools werden nicht unterstützt, und ihre Verwendung erfolgt auf eigenes Risiko. Es handelt sich nicht um offizielle Microsoft-Produkte, sondern um meine eigenen persönlichen Entwürfe. Sie wurden nur von mir und einigen anderen Freiwilligen unter 32-Bit-Windows Vista mit US-Englisch als Standardsprache getestet. Es ist möglich, dass einige oder alle dieser PowerToys mit zukünftigen Windows-Updates, Service Packs oder Betriebssystemversionen nicht funktionieren.

Michael Murgolo ist leitender Infrastrukturberater für Microsoft Consulting Services. Er ist auf die Bereiche Betriebssysteme, Bereitstellung, Netzwerkdienste, Active Directory, Systemverwaltung, Automatisierung und Patchverwaltung spezialisiert. Zu seinen Fachgebieten zählen die Desktopbereitstellung und die Migration.


Sicherheit
Fortschritte bei der BitLocker-Laufwerkverschlüsselung
Byron Hynes
Auf einen Blick:
  • Verbesserungen bei BitLocker
  • Installieren von BitLocker
  • Verwenden von BitLocker auf einem Server
  • Überlegungen für vollständigen Datenschutz

In der letztjährigen Sicherheitsausgabe des TechNet Magazins habe ich Sie auf eine kurze Führung durch einige Features der Windows BitLocker-Laufwerkverschlüsselung mitgenommen, um Ihnen zu zeigen, wie sie in der ersten Version von Windows Vista implementiert wurde. Nach der Veröffentlichung von Service Pack 1 für
Windows Vista® und des neuen Betriebssystems Windows Server® 2008 ist es an der Zeit, BitLocker® erneut unter die Lupe zu nehmen.
In diesem Artikel werde ich einige Änderungen beleuchten, die in der aktuellen Version zu finden sind, einen Überblick über die Installation und Verwendung von BitLocker auf einem Server geben und einige der in den Medien erwähnten Überlegungen ansprechen. (Übrigens können Sie den Artikel aus dem vergangenen Jahr, „Schlüssel zum Schützen von Daten durch BitLocker-Laufwerkverschlüsselung“ unter technet.microsoft.com/magazine/cc138009.aspx nachlesen.)

Neuerungen
Die Änderungen, die mit dieser Version von BitLocker eingeführt werden, bringen neue Flexibilität ohne eine Änderung grundlegender Vorgänge. Die von mir dargelegten Änderungen sind folgende: Unterstützung für Datenvolumes; Ermöglichung von dreistufige Authentifizierung für Gerätezugriff; Unterstützung für UEFI (Unified Extensible Firmware Interface), die neue Branchenstandardfirmware für 64-Bit-Systeme; besserer Schutz vor kryptografischen Angriffen auf Volumemetadaten sowie gesteigerte Verwendung von TPM (Trusted Platform Module).

Datenvolumes
Als Windows Vista veröffentlicht wurde, konnte über die BitLocker-Systemsteuerung nur Verschlüsselung für das Windows®-Betriebssystemvolume aktiviert werden (meist das Laufwerk C:). Für viele Nutzer war das durchaus ausreichend, da Heimcomputer meist so konfiguriert sind, dass alle Daten und Programme des Benutzers auf demselben Volume gespeichert sind wie das Betriebssystem. In Unternehmen und vor allem auf Servern ist das oft nicht der Fall. Daher betraf eine der häufigsten Anfragen von Kunden die Möglichkeit, Datenvolumes zu verschlüsseln – andere Volumes als das Betriebssystemvolume, die auf dem Computer installiert sind. (Beachten Sie, dass BitLocker nicht für die Verschlüsselung von Wechselmedien entwickelt wurde.)
Wie Sie in Abbildung 1 sehen können, befinden sich auf diesem Computer drei verwendbare Volumes. (Tatsächlich gibt es vier, wenn man die kleine aktive Partition einrechnet, die für den Start verwendet wird.) Das Betriebssystem ist auf Laufwerk C: installiert (das wird durch das Windows-Zeichen auf dem Symbol angezeigt), und es sind auch zwei Datenvolumes vorhanden, E: und P:. Volume P: wurde bereits mit BitLocker verschlüsselt und ist gerade gesperrt. Volume E: ist nicht noch verschlüsselt. In Windows Vista SP1 und Windows Server 2008 können diese Datenvolumes über die BitLocker-Systemsteuerungsoption verschlüsselt und entsperrt werden.
Abbildung 1 Die BitLocker-Schnittstelle
Abbildung 1 Die BitLocker-Schnittstelle (Zum Vergrößern auf das Bild klicken)
Wenn Ihr Betriebssystemvolume mit BitLocker verschlüsselt ist, besteht das Standardverhalten darin, dass verschlüsselte Datenvolumes immer dann entsperrt werden, wenn das Betriebssystemvolume entsperrt wird. Wenn Sie die Systemsteuerung verwenden, um ein Datenvolume zu entsperren, ist diese Option als Kontrollkästchen verfügbar (siehe Abbildung 2).
Abbildung 2 Speichern von Schlüsseln für automatisches Entsperren
Abbildung 2 Speichern von Schlüsseln für automatisches Entsperren (Zum Vergrößern auf das Bild klicken)
Um das automatische Entsperren für ein Datenvolume zu aktivieren oder zu deaktivieren, können Sie das Befehlszeilentool manage-bde.wsf verwenden. Manage-bde.wsf ist ein in Windows enthaltenes leistungsfähiges Skript, das die zugrunde liegenden WM-Anbieter (Windows Management Instrumentation) verwendet, die mit BitLocker installiert sind.
Um beispielsweise das Datenvolume P: so zu markieren, dass es manuell entsperrt werden muss, können Sie folgenden Befehl verwenden:
manage-bde.wsf –autounlock –disable P:
Verwenden Sie zum Aktivieren des automatischen Entsperrens von P: folgenden Befehl:
manage-bde.wsf –autounlock –enable P:
Die BitLocker-Systemsteuerung zeigt nicht alle Optionen an, die für BitLocker verfügbar sind. Daher sollten Sie die Option „-?“ verwenden, um die manage-bde.wsf-Befehle zu erkunden. Die manage-bde.wsf-Syntax ist auch im Entwurfshandbuch zur Windows BitLocker-Laufwerkverschlüsselung und im Bereitstellungshandbuch für Windows BitLocker enthalten. Beide Dokumente sind über das Microsoft Download Center unter go.microsoft.com/fwlink/?LinkId=115215 verfügbar.

TPM+USB+PIN
Kunden wollen auch zusätzliche Authentifizierungsstufen mit BitLocker verwenden können. BitLocker verwendet den TPM-Chip in Ihrem Computer, um die Integrität der Plattform zu prüfen, d. h. um sicherzustellen, dass die frühen Startkomponenten, einschließlich des BIOS, nicht manipuliert oder beschädigt wurden. Seit der Veröffentlichung von Windows Vista kann jedoch auch eine PIN bzw. das Vorhandensein eines USB-Flashlaufwerks erforderlich sein, das den Schlüssel enthält, der bei der Aktivierung von BitLocker erstellt wurde.
Mit Windows Server 2008 und Windows Vista SP1 können jetzt alle drei kombiniert werden. Das TPM überprüft weiterhin die Plattformintegrität, der USB-Schlüssel ist etwas Vorhandenes, und die PIN ist etwas, das Sie wissen. Diese Konfiguration bietet zuverlässigen Schutz davor, dass nicht autorisierte Benutzer in der Lage sind, den Computer zu starten und die durch BitLocker geschützten Laufwerke zu entsperren.
Wie bei vielen Sicherheitsmaßnahmen wird jedoch auch hier ein Kompromiss geschlossen. Wenn BitLocker auf diese Weise konfiguriert ist, kann ein Computer nicht automatisch neu starten. Im Fall eines Servers müssen Sie z. B. entscheiden, was Ihnen wichtiger ist: ein automatischer Neustart oder besserer Schutz.

Unterstützung für UEFI
Seit Windows Server 2008 und Windows Vista SP1 gibt es auch Unterstützung für Computer, die mit UEFI (Unified Extensible Firmware Interface) ausgestattet sind. UEFI ist eine Spezifikation, die eine Modernisierung des herkömmlichen BIOS darstellt, das von den meisten Computern beim Start verwendet wird. Weitere Informationen zur UEFI-Spezifikation finden Sie unter www.uefi.org.

Erhöhter Schutz
Wenn BitLocker erkennt, dass das System geändert wurde, oder wenn eine erforderliche PIN oder ein USB-Schlüssel beim Start nicht verfügbar ist, geht BitLocker in den Wiederherstellungsmodus. Bei der Wiederherstellung bleiben BitLocker-aktivierte Volumes gesperrt, und ein Textmodusdialog namens „Wiederherstellungskonsole“ wird angezeigt.
Zum Entsperren des Laufwerks muss der Benutzer ein Wiederherstellungskennwort (eine 48-stellige Zahl) entweder über die Tastatur oder über ein USB-Flashlaufwerk eingeben. (Wenn das Kennwort auf einem USB-Flashlaufwerk gespeichert ist, wird es manchmal als Wiederherstellungsschlüssel bezeichnet, da es sich um eine Binärdatei und nicht um eine Datei im Textformat handelt.)
BitLocker verwendet zum Entschlüsseln des Laufwerks das Wiederherstellungskennwort, um die in den Volumemetadaten gespeicherten Schlüssel zu entschlüsseln, d. h. den Volumehauptschlüssel (Volume Master Key, VMK) und dann den Schlüssel für die vollständige Volumeverschlüsselung (Full Volume Encryption Key, FVEK). Damit die Wiederherstellung erfolgreich ist, wird eine Kopie des Wiederherstellungskennworts benötigt.
Deshalb empfehle ich zusätzlich zur Speicherung durch den Benutzer (beispielsweise auf einem USB-Flashlaufwerk) die zentrale Speicherung des Wiederherstellungskennworts. Das Betriebssystem umfasst eine Funktion für die Speicherung von Wiederherstellungskennwörtern in Active Directory®-Domänendiensten (ADDS).
Geheime Informationen, die in den Volumemetadaten gespeichert werden, wie z. B. der VMK, sind verschlüsselt, und die Integrität der gesamten Volumemetadaten ist kryptografisch geschützt. Wenn BitLocker erkennt, dass die Volumemetadaten manipuliert wurden, wird die Verwendung der Metadaten verweigert, und geschützte Volumes werden nicht entsperrt. Beachten Sie, dass das Wiederherstellungskennwort allein kein Laufwerk in diesem Zustand entsperrt.
Es sollte darauf hingewiesen werden, dass diese Situation nur dann eintritt, wenn ein absichtlicher Angriff auf den Computer stattgefunden hat. Wenn das geschieht, ist die Wahrscheinlichkeit hoch, dass sich Ihr Computer bereits in den Händen eines Angreifers befindet und außerhalb Ihrer Kontrolle ist. Dieser Zustand ergibt sich nicht aus einer einfachen ungeplanten Änderung an der Plattform oder daraus, dass Sie Ihre PIN vergessen haben.
Zum Entsperren des Volume benötigen Sie die folgenden drei Elemente:
  • Das Wiederherstellungskennwort (als einzugebender Text oder auf einem USB-Flashlaufwerk)
  • Das binäre Schlüsselpaket, das verschlüsselte Versionen des FVEK und des VMK enthält
  • Das BitLocker-Reparaturtool
Kurz gesagt, müssen Sie sicherstellen, dass Ihr Unternehmen immer Zugriff auf alle diese Informationen hat.
Es kann manuell oder automatisch eine Sicherungskopie des Wiederherstellungskennworts erstellt werden. Ich empfehle die Verwendung der Gruppenrichtlinieneinstellung, um automatisch eine Sicherungskopie des Wiederherstellungskennworts in den Active Directory-Domänendiensten zu erstellen.
Wenn Sie diese Einstellung wie in Abbildung 3 gezeigt konfigurieren, schließen Sie die Option zur Sicherung des binären Schlüsselpakets mit ein. Das binäre Schlüsselpaket enthält verschlüsselte Versionen des VMK und des FVEK. Somit können Sie wenn nötig das BitLocker-Reparaturtool verwenden.
Abbildung 3 Konfigurieren der Gruppenrichtlinie, sodass sie Schlüsselpakete in den Wiederherstellungsinformationen enthält
Abbildung 3 Konfigurieren der Gruppenrichtlinie, sodass sie Schlüsselpakete in den Wiederherstellungsinformationen enthält (Zum Vergrößern auf das Bild klicken)
Das BitLocker-Reparaturtool wurde entwickelt, um Daten von beschädigten Laufwerken, die BitLocker-aktiviert sind, wiederherstellen zu können. Beachten Sie, dass es sich um ein Tool für erfahrene Administratoren handelt. Weitere Informationen zum BitLocker-Reparaturtool finden Sie im Microsoft Knowledge Base-Artikel unter support.microsoft.com/kb/928201 oder in meinem Webcast „Microsoft BitLocker im Unternehmen: BitLocker-Tools, die Ihnen das Leben erleichtern“ (mit Livedemo) unter go.microsoft.com/fwlink/?LinkId=114985.
An dieser Stelle sollte darauf hingewiesen werden, dass BitLocker keinen Ersatz für das Erstellen von Sicherungskopien Ihrer Daten darstellt. Wenn Ihr Datenträger beschädigt oder vorsätzlich angegriffen wurde, gibt es keine Garantie, dass das BitLocker-Reparaturtool die Daten teilweise oder gar vollständig wiederherstellen kann.

Breitere TPM-Verwendung
Eigentlich handelt es sich hierbei nicht um eine BitLocker-Änderung, aber dieses Feature ist so toll, dass es erwähnt werden sollte. Vor SP1 war BitLocker der einzige Teil des Windows-Betriebssystems, der das TPM nutzte. Nun wird das TPM aber auch für andere Funktionen verwendet. Wenn Windows erkennt, dass ein TPM verfügbar ist, wird das TPM bei der Erzeugung von Zufallszahlen als Quelle erhöhter Entropie verwendet. Dadurch wird die Qualität aller möglichen Verschlüsselungen verbessert.
Das bedeutet aber auch, dass sich nicht alle TPM-Ereignisse, die in der Ereignisanzeige dargestellt werden, notwendigerweise auf BitLocker beziehen. Als IT-Experte sollten Sie wissen, dass andere Systemkomponenten – und möglicherweise Software anderer Anbieter – das TPM nutzen, sodass Ereignisse protokolliert werden.

BitLocker in Windows Server 2008
Aufgrund der gemeinsamen Codebasis zwischen Windows Vista und Windows Server 2008 sind die BitLocker-Änderungen in SP1 ein wesentlicher Bestandteil von Windows Server 2008. Aber warum ist BitLocker auf einem Server relevant? Letztendlich soll BitLocker einen Computer vor Offlineangriffen schützen. Anders gesagt, bietet BitLocker keinen Schutz für ein laufendes System, und Server sollen natürlich im Allgemeinen ständig laufen.
Es stellt sich heraus, dass es Gelegenheiten gibt, bei denen ein Server oder eine Festplatte eines Servers einem Onlineangriff ausgesetzt sein kann. Selbst wenn das nie geschieht, kann BitLocker, wie wir sehen werden, äußerst hilfreich sein, wenn ein Server oder eine Festplatte außer Betrieb genommen werden sollen. Sehen wir uns zunächst an, wie BitLocker auf einem Server installiert und ausgeführt wird.

Installieren von BitLocker
BitLocker ist in allen Editionen von Windows Server 2008 enthalten, aber es handelt sich um eine optionale Komponente, die entweder über den Server-Manager oder über die Befehlszeile installiert werden muss. BitLocker ist teilweise als NTFS-Filtertreiber implementiert. Für das Installieren dieses Filtertreibers ist ein Neustart des Computers erforderlich. Beachten Sie also, dass für die Aktivierung von BitLocker ein Neustart nötig ist. Außerdem benötigt BitLocker bei Windows Vista eine Split-Load-Konfiguration, wobei die aktive Partition zum Starten des Computers unverschlüsselt bleibt. Mit dem BitLocker-Laufwerkvorbereitungstool können Festplatten so konfiguriert werden, dass sie BitLocker unterstützen, falls der Server nicht bereits vom Hersteller konfiguriert wurde. Wenn Sie mit der Partitionierung von Festplatten vertraut sind, können Sie die Konfiguration sicher auch manuell vornehmen.
Zum Installieren von BitLocker in Windows Server 2008 können Sie die grafische Server-Manager-Schnittstelle verwenden, um BitLocker aus der Featureliste auszuwählen (siehe Abbildung 4), oder Sie verwenden die Befehlszeilenschnittstelle von Server-Manager, um folgenden Befehl einzugeben:
Abbildung 4 Auswählen von BitLocker in Server-Manager
Abbildung 4 Auswählen von BitLocker in Server-Manager (Zum Vergrößern auf das Bild klicken)
ServerManagerCmd –install BitLocker –restart
Bei der Verwendung von Server-Manager werden BitLocker und die Verwaltungstools für BitLocker installiert. Sie können auch die Verwaltungskomponenten ohne BitLocker installieren. Dann ist kein Neustart erforderlich, da der Filtertreiber nicht enthalten ist. Diese Komponente heißt „RSAT-BitLocker“.
BitLocker funktioniert gut auf Computern, die die Server Core-Installationsoption ausführen, aber Sie können den Server-Manager nicht verwenden, um BitLocker auf Server Core zu installieren, oder die grafische Benutzerschnittstelle nutzen, um BitLocker auf Server Core zu verwalten. Verwenden Sie stattdessen zum Installieren der Komponenten die Befehlszeilentools „pkgmgr“ oder „ocsetup“.
Nach dem Installieren der BitLocker-Binärdateien sowie dem Konfigurieren Ihrer Festplatten in der erforderlichen Split-Load-Konfiguration können Sie BitLocker auf dem Betriebssystemvolume aktivieren. Die BitLocker-Systemsteuerungsoption verfügt in Windows Server 2008 und in Windows Vista SP1 über die gleichen Symbole und Optionen. Um die erweiterten BitLocker-Modi zu aktivieren, müssen die Standardeinstellungen mithilfe des Editors für lokale Richtlinien oder mit einem Gruppenrichtlinienobjekt, das auf den Server angewendet wird, angepasst werden.
Auf Server Core oder wenn Sie die Systemsteuerung nicht verwenden möchten, können Sie BitLocker über manage-bde.wsf aktivieren. Geben Sie zum Aktivieren von BitLocker auf Laufwerk C: Folgendes ein:
manage-bde.wsf –on C: -RecoveryPassword –RecoveryKey F:\
wobei C: das zu verschlüsselnde Volume ist und F:\ ein USB-Schlüssel oder ein anderes Volume, auf dem eine Kopie des Wiederherstellungsschlüssels (im binären Format) gespeichert wird. Sie können auch einen UNC-Pfad verwenden, um den Wiederherstellungsschlüssel auf einem Netzwerklaufwerk zu speichern. Ein Wiederherstellungskennwort (im numerischen Textformat) wird ebenfalls generiert und angezeigt. Eventuell möchten Sie den Parameter „–skiphardwaretest“ hinzufügen, wenn Sie sich sicher sind, dass die Hardwareplattform allen BitLocker-Anforderungen entspricht. Dadurch ersparen Sie sich einen Neustart.

Serverszenarios
Betrachten wir nun einige spezielle Szenarios, bei denen BitLocker für Server nützlich ist. Beachten Sie, dass BitLocker, wie bereits erwähnt, zum Schutz vor Onlineangriffen entwickelt wurde, das heißt für Angriffe, die stattfinden, wenn Windows nicht ausgeführt wird.
Zweigstellen Eine der ersten und offensichtlichsten Anwendungen für BitLocker auf einem Server ist die Verwendung als Teil der Windows Server 2008-Zweigstellenstrategie. Zwischen einem Viertel und einem Drittel der Server sind in Zweigstellen installiert, also in Büros mit möglicherweise geringerer physischer Sicherheit, weniger Zugriff auf IT-Unterstützung und vielleicht weniger Konnektivität zu Datencentern. Zweigstellen sind auch ein attraktives Ziel für Angriffe. In Verbindung mit Features wie z. B. schreibgeschützten Domänencontrollern kann BitLocker dabei helfen, vertrauliche Daten zu schützen, die in einer Zweigstelle gespeichert werden müssen, sich aber nicht so leicht physisch sichern lassen wie vielleicht in einem Datencenter.
Dies ist eine gute Gelegenheit, über das richtige Maß an Schutz nachzudenken. Was ist wichtiger, die Verhinderung nicht autorisierter Datenzugriffe oder dass der Server sofort und ohne Intervention neu gestartet wird? Ich denke, dass es in vielen Zweigstellen akzeptabel ist, für das Neustarten eines Servers die Eingabe einer PIN obligatorisch zu machen, aber das ist eine Entscheidung, die jedes Unternehmen selbst treffen muss.
Lieferung von Datenträgern Es ist oft notwendig, Daten auf einer Festplatte zu einem entfernten Ort zu liefern. Das kann die Lieferung eines einzelnen Datenträgers oder das Vorkonfigurieren und Versenden eines gesamten Servers umfassen. Während der Lieferung sind die Daten auf den Datenträgern außerhalb Ihrer Kontrolle und könnten kopiert werden, verloren gehen oder gestohlen werden.
Um dieses Risiko zu verringern, können Sie vor der Lieferung BitLocker auf den Volumes im Computer aktivieren und anschließend alle Schlüsselschutzvorrichtungen außer einem Wiederherstellungsschlüssel oder -kennwort entfernen. Dieser Schlüssel bzw. dieses Kennwort kann dann getrennt vom Server oder sogar per Telefon oder verschlüsselter E-Mail an die Mitarbeiter übermittelt werden. Nach dem Empfang des Computers oder Datenträgers wird das Wiederherstellungskennwort zum Entsperren des Laufwerks verwendet. Das Laufwerk kann verschlüsselt bleiben (fügen Sie alle weiteren Schlüsselschutzvorrichtungen wieder hinzu), oder der Datenträger kann nach der Bereitstellung vollständig entschlüsselt werden.
Dies ist eine besonders wirksame Möglichkeit, Domänencontroller oder Servern für Zweigstellen vorzukonfigurieren.
Diebstahl eines Servers Wie im vorangegangenen Abschnitt bereits angemerkt, besteht die reale Gefahr, dass ein Server (und v. a. ein Domänencontroller) gestohlen wird. Diebe können sich eines Laptops einfach aus einer Gelegenheit heraus bemächtigen, aber ein Server kann ein sorgfältig ausgewähltes Ziel darstellen. Wenn BitLocker so konfiguriert ist, dass es nur TPM-Integritätsprüfung erfordert, könnte der gestohlene Server einfach eingeschaltet und gestartet werden. Wenn die Laufwerke in einem Server aber mit BitLocker geschützt sind und BitLocker in einem erweiterten Modus konfiguriert ist, der einen USB-Schlüssel, eine PIN oder beides erfordert, ist es für Diebe sehr schwierig, innerhalb angemessener Zeit nützliche Informationen zu erhalten.
Diebstahl eines Datenträgers Wird aber nur ein Datenträger gestohlen, bietet das TPM noch immer guten Schutz. Nur das TPM des ursprünglichen Servers kann verwendet werden, um das mit BitLocker geschützte Laufwerk zu entsperren. Der Datenträger kann also nicht einfach in einen anderen Computer eingelegt und gelesen werden.
Verringertes Gefahrenpotenzial Durch die Verwendung von Serverhardware, die einen TPM-Chip enthält, und mithilfe der BitLocker-Plattformintegritätsprüfung erhöhen Sie den Schutz vor einigen Formen von Malware. BitLocker erkennt insbesondere Änderungen, die vorgenommen werden, während Windows offline ist, oder Änderungen an den frühen Startkomponenten, vor allem wenn Malware, wie z. B. ein Rootkit, zum Installieren einen Neustart erfordert. Dies ist keine umfassende Lösung, aber kombiniert mit Features wie Windows-Codeintegrität und mit Produkten wie z. B. Microsoft® ForefrontTM Client Security stellt es eine weitere wirksame Tiefenverteidigungsschicht dar.
Sichere Außerbetriebsetzung Eines der nützlichsten Szenarios für BitLocker kommt am Ende des Lebenszyklus eines Servers oder Datenträgers zum Tragen. Wie oft haben Sie von Servern oder Datenträgern gehört, die entsorgt wurden, ohne ordnungsgemäß außer Betrieb genommen worden zu sein? Haben Sie gewusst, dass gebrauchte Festplatten manchmal auf Auktionswebsites teurer verkauft werden als neue, da skrupellose Käufer hoffen, durch die Datenträger nützliche Informationen zu erlangen?
Glücklicherweise bietet BitLocker einen anderen Ansatz als das zeitaufwändige Entfernen nützlicher Daten vom Datenträger. Im Grunde werden niemals Informationen in einem nützlichen Format auf den Datenträger geschrieben. Da die verschlüsselten Daten unbrauchbar sind, besteht eine schnelle, einfache Maßnahme im Entfernen aller Schlüsselinformationen. Danach ist es egal, was mit der Datenträgerhardware geschieht – sie kann verkauft, wiederverwertet oder einem neuen Zweck zugeführt werden, ohne dass Sie sich darüber Gedanken machen müssen, dass die Daten in die falschen Hände fallen könnten.
In Windows Vista und Windows Server 2008 wurde der Formatierungsbefehl so aktualisiert, dass die BitLocker-Schlüssel einschließlich mehrerer Überschreibungen entfernt werden. Jetzt haben Sie eine einfache und wirksame Möglichkeit, um ein Laufwerk außer Betrieb zu nehmen.

Aktuelle Neuigkeiten
Während ich dies schreibe, zugegebenermaßen mehrere Wochen, bevor Sie den Artikel lesen können, wurden in einigen neuen Artikeln, Beiträgen und Berichten interessante Hardwareeigenschaften und ihre Auswirkungen auf BitLocker, weitere Windows-Sicherheitsfeatures und andere Verschlüsselungsprodukte von verschiedenen Anbietern diskutiert. Einige dieser Ergebnisse möchte ich hier kurz ansprechen.
Ein solcher Artikel wurde von Forschern an der Princeton University veröffentlicht und führt (sehr wirksam!) eine Eigenschaft moderner Computerspeicher vor, die gelegentlich als „DRAM-Remanenz“ bezeichnet wird (verfügbar unter citp.princeton.edu/pub/coldboot.pdf). Einfach ausgedrückt, kann einige Zeit, nachdem die Stromzufuhr zum Speicher unterbrochen wurde, immer noch auf den Inhalt eines Computerspeichers zugegriffen werden. BitLocker verwahrt selbstverständlich Schlüssel zum Entschlüsseln von Daten in einem Speicher, während Windows ausgeführt wird, und die Bedenken gehen dahin, dass nicht autorisierte Benutzer auf die Schlüssel zugreifen könnten.
In einer anderen Vorführung (security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf) hat Adam Boileau gezeigt, wie IEEE 1394 (oft als FireWire bezeichnet) direkten Speicherzugriff ermöglicht, der verwendet werden kann, um geheime Informationen von Windows zu erlangen, wie z. B. Kennwörter oder Entschlüsselungsschlüssel. Interessant daran ist, dass direkter Speicherzugriff fast der Zweck von 1394 ist. Es handelt sich also nicht um eine Schwachstelle, sondern ist genau das, wofür Firewire entwickelt wurde.
Beide Angriffe erfordern aber physischen Zugriff auf einen laufenden (oder zumindest vor kurzem noch ausgeführten) Computer. BitLocker wurde nicht zum Schutz vor Onlineangriffen entwickelt und ersetzt nicht einen gewissen Grad an physischer Sicherheit. Richtige Tiefenverteidigung erfordert die Verwendung einer Reihe von Tools und Features, den Aufbau einer Umgebung physischer Sicherheit, die Erstellung grundlegender Unternehmensrichtlinien und die ständige Schulung der Benutzer.
Auch handelt es sich dabei nicht um neue Erkenntnisse. Dies ist seit einiger Zeit bekannt und wird auch im Microsoft® Data Encryption Toolkit (DET) besprochen. Die in DET bereitgestellte Risikoanalyse soll Kunden helfen, Sicherheit gegen Benutzerfreundlichkeit sowie die Kosten der Implementierung und der Verwaltung abzuwägen. Das ist sehr wichtig. Wir sind der Meinung, dass geschulte Kunden am besten in der Lage sind, Entscheidungen über die Kompromisse zwischen Sicherheit, Benutzerfreundlichkeit und Kosten zu treffen.
Neben dem DET haben einige meiner Kollegen hervorragende Kommentare und Leitfäden verfasst. Russ Humphries hat Sicherheitskompromisse im Kontext von DRAM-Remanenz in seinem Blogeintrag unter go.microsoft.com/fwlink/?LinkId=115217 erörtert. Darüber hinaus hat Douglas MacIver im Teamblog zur Systemintegrität unter go.microsoft.com/fwlink/?LinkId=115218 über zusätzliche spezielle Konfigurationsschritte und Gegenmaßnahmen geschrieben, die heutzutage ergriffen werden können. Ich empfehle Ihnen, sich die Zeit für die Lektüre dieser beiden sehr hilfreichen Blogeinträge zu nehmen. Sie sollten auch das DET lesen.
Wichtig bei diesen Empfehlungen ist, einen erweiterten Modus zu verwenden (also einen, der einen USB-Schlüssel oder eine PIN erfordert) und den Computer nicht unbeaufsichtigt im Energiesparmodus zu lassen (sondern stattdessen den Ruhezustand zu verwenden).

Schlussbemerkung
BitLocker bleibt eines der nützlichsten Features von Windows Vista. Mit der Veröffentlichung von SP1 wurde es in Reaktion auf Kundenfeedback verbessert und bietet nun mehr Szenarios und erfüllt breitere Anforderungen für den Datenschutz. Die Erweiterung dieses Schutzes ruhender Daten auf Windows Server 2008 bietet Ihnen weitere Möglichkeiten für den Datenschutz und die Einhaltung von Bestimmungen, unabhängig davon, ob diese Daten auf Servern oder Clientarbeitsstationen, im Datencenter, der Zweigstelle oder bei einem mobilen Benutzer gespeichert sind.

Byron Hynes ist Enterprise Technology Strategist bei der Microsoft Enterprise and Partner Group (EPG) und konzentriert sich auf Sicherheitsfeatures und Produkte. Vor seiner Arbeit für die EPG arbeitete er in der Windows Server-Abteilung und seit 2005 eng mit BitLocker (Systemintegrität). Er freut sich über ihre Kommentare und Fragen. Er ist auf der Tech•Ed 2008 anzutreffen oder per E-Mail unter bhynes@microsoft.com zu erreichen.


Sicherheit
Sperren von Anwendungen mit Softwareeinschränkungsrichtlinien
Chris Corio and Durga Prasad Sayana
Auf einen Blick:
  • Funktionsweise von Softwareeinschränkungsrichtlinien
  • Erfassen von Anwendungen in Ihrer Umgebung
  • Erstellen und Durchsetzen von Richtlinien

Wenn IT-Experten nach Möglichkeiten suchen, die Gesamtkosten ihrer Desktopcomputer zu verringern, greifen sie häufig auf zwei Hauptstrategien zurück. Die erste besteht darin, die Konten der Desktopbenutzer
aus der Administratorengruppe zu entfernen. Die zweite besteht im Begrenzen der Anwendungen, die von den Benutzern ausgeführt werden können. Die Lösung dieser Probleme kann in einer Unternehmensumgebung eine Herausforderung darstellen, Windows Vista® bietet aber einige Technologien, die Ihnen dabei helfen.
Windows Vista hat IT-Experten mit seinem Feature der Benutzerkontensteuerung einen großen Schritt vorangebracht, indem es ihnen ermöglicht, Unternehmensanwender als Mitglieder der Benutzergruppe (Standardbenutzer) auszuführen. Die Benutzerkontensteuerung änderte den Standardsicherheitskontext für alle Anwendungen in den eines Benutzers (statt eines Administrators). Diese Migration zur Benutzergruppe ist immer noch ein schwieriges Unterfangen, aber mit fortschreitender Umstellung der Branche auf dieses neue Paradigma wird diese Aufgabe im Lauf der Zeit einfacher.
Viele Administratoren katalogisieren nach (oder auch während) der Analyse der Aufgaben, die mit dem Verschieben der Benutzer in die Benutzergruppe verbunden sind, welche Anwendungen ihre Benutzer ausführen müssen, und überlegen, welche Schritte erforderlich sind, um nur diese Anwendungen zuzulassen. Das Feature der Softwareeinschränkungsrichtlinien wurde entworfen, um IT-Experten dabei zu helfen.
Sie geben einfach an, welche Anwendungen ausgeführt werden dürfen, und stellen dann die Richtlinie mithilfe der Gruppenrichtlinie bereit. Mit der Durchsetzung einer solchen Richtlinie im gesamten Unternehmen ist es möglich, die Gesamtkosten zu verringern, denn durch die Sperrung werden die Probleme in Verbindung mit nicht unterstützten Anwendungen begrenzt. (Für die Verwendung von Softwareeinschränkungsrichtlinien gibt es darüber hinaus einige interessante und extreme Möglichkeiten, die wir in der Randleiste „Die minimale Softwareeinschränkungsrichtlinie“ besprechen.)

Funktionsweise von Softwareeinschränkungsrichtlinien
Das Ziel der Softwareeinschränkungsrichtlinien besteht darin, genau zu kontrollieren, welchen Code ein Benutzer auf einem Windows Vista-Computer ausführen kann. Sie, der Administrator, erstellen eine Richtlinie, die definiert, was (oder was nicht) in Ihrer Umgebung ausgeführt werden darf. Diese Richtlinie wird immer dann herangezogen, wenn Code ausgeführt werden könnte. Dies gilt u. a. während der Prozesserstellung, bei einem Aufruf von ShellExecute und bei Ausführung eines Skripts. (Wir untersuchen dies sogleich ausführlicher.)
Wenn festgelegt wurde, dass eine Anwendung ausgeführt werden darf, wird die Anwendung gestartet. Wenn aber festgelegt wurde, dass eine Anwendung nicht ausgeführt werden darf, wird die Anwendung gesperrt, und der Benutzer wird benachrichtigt. Wenn Sie beispielsweise versucht haben, Solitär vom Startmenü aus auszuführen, und dies war nicht zulässig, wird ein Dialogfeld ähnlich dem in Abbildung 1 angezeigt.
Abbildung 1 Ein Dialogfeld wird angezeigt, wenn eine Anwendung gesperrt ist
Abbildung 1 Ein Dialogfeld wird angezeigt, wenn eine Anwendung gesperrt ist (Zum Vergrößern auf das Bild klicken)
Die Benutzeroberfläche zum Definieren einer Softwareeinschränkungsrichtlinie ist im Gruppenrichtlinienobjekt-Editor verfügbar. Hier wird die Sperrungsrichtlinie erstellt. Es gibt verschiedene Methoden, mit denen sich definieren lässt, welcher Code ausgeführt werden darf und welcher nicht. Wenn die Richtlinie fertig gestellt ist und getestet wurde, können Sie sie bereitstellen.

Definieren der Softwareeinschränkungsrichtlinie
Die erste wichtige Entscheidung, die Sie treffen müssen, wirkt sich grundlegend darauf aus, wie die Softwareeinschränkungsrichtlinie in Ihrer Umgebung funktioniert: Sie müssen einen Standardregeltyp auswählen. Für die Bereitstellung von Softwareeinschränkungsrichtlinien stehen zwei Modi zur Verfügung: eine Zulassungsliste und eine Verweigerungsliste. Im Grunde legen Sie fest, ob Sie eine Richtlinie erstellen möchten, die jede in Ihrer Umgebung zugelassene Anwendung beschreibt, oder eine Richtlinie, die jede Anwendung definiert, die nicht ausgeführt werden darf.
Im Zulassungslistenmodus ist die Standardregel in Ihrer Richtlinie „Eingeschränkt“. Es werden alle Anwendungen gesperrt, deren Ausführung Sie nicht explizit zulassen. Im Verweigerungslistenmodus ist die Standardregel „Nicht eingeschränkt“. Es werden nur die Anwendungen eingeschränkt, die Sie explizit aufgelistet haben.
Sicher haben Sie erkannt, dass der Verweigerungslistenmodus eine unrealistische Option ist, wenn Sie an einer deutlichen Verringerung der Gesamtkosten sowie den Sicherheitsvorteilen interessiert sind, die sich aus der Sperrung von Anwendungen ergeben. Das Erstellen und Führen einer umfangreichen Liste zur Sperrung sämtlicher Malware und anderer problematischer Anwendungen wäre so gut wie unmöglich. Daher empfehlen wir die Implementierung der Softwareeinschränkungsrichtlinie im Zulassungslistenmodus, das heißt mit der Standardregel „Eingeschränkt“.

Erfassen von Anwendungen in Ihrer Umgebung
Bei der Entwicklung einer Richtlinie, mit der festgelegt wird, welche Anwendungen ausgeführt werden dürfen, müssen Sie genau bestimmen, welche Anwendungen die Benutzer benötigen. Das Feature der Softwareeinschränkungsrichtlinien bietet ein Feature zur erweiterten Protokollierung mit einer sehr einfachen Richtlinie, die es ermöglicht, genau zu verstehen, welche Anwendungen in Ihrer Umgebung ausgeführt werden.
Stellen Sie die Softwareeinschränkungsrichtlinie für eine Beispielgruppe von Computern in Ihrer Umgebung bereit, wobei Sie für den Standardregelsatz „Nicht eingeschränkt“ festlegen. Entfernen Sie alle anderen Regeln. Die Absicht besteht darin, die Softwareeinschränkungsrichtlinie zu aktivieren, ihr aber nicht zu erlauben, Anwendungen einzuschränken. Stattdessen verwenden Sie sie lediglich zur Überwachung der ausgeführten Anwendungen.
Erstellen Sie als Nächstes den folgenden Registrierungswert, um das Feature zur erweiterten Protokollierung zu aktivieren, und geben Sie für den Pfad das Verzeichnis an, in das die Protokolldatei geschrieben werden soll:
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>
Wenn jetzt eine Anwendung ausgeführt und die Softwareeinschränkungsrichtlinie ausgewertet wird (die Auswertung erfolgt trotz der Tatsache, dass die Richtlinie allen Anwendungen die Ausführung erlaubt), wird ein Eintrag in die Protokolldatei geschrieben.
Jeder Protokolleintrag enthält den Aufrufer der Softwareeinschränkungsrichtlinie und die Prozess-ID (PID) des aufrufenden Prozesses, das Ziel, das ausgewertet wird, den angetroffenen Regeltyp der Softwareeinschränkungsrichtlinie sowie eine Kennung für die Regel. Hier ein Beispieleintrag, der geschrieben wird, wenn ein Benutzer auf notepad.exe doppelklickt:
explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}
In dieser Protokolldatei werden sämtliche Abschnitte ausführbaren Codes dargestellt, die von dieser Softwareeinschränkungsrichtlinie überprüft werden, wenn die Richtlinie aktiviert und für die Sperrung von Anwendungen eingerichtet wurde. Das bedeutet, dass Sie für jeden Eintrag in der Protokolldatei entscheiden müssen, ob er in Ihrer Zulassungsliste berücksichtigt werden soll oder nicht. Beachten Sie, dass mehrere Binärdateien überprüft werden, die Teil von Windows® sind und vom System benötigt werden.
Mithilfe des hier beschriebenen Protokollierungsverfahrens können Sie genau beurteilen, auf welche Anwendungen die Softwareeinschränkungsrichtlinie in Ihrer Umgebung stoßen wird. Dies ist aber nicht die einzige Möglichkeit, diese Aufgabe zu auszuführen.
Mit dem Inventory Collector, Teil des Microsoft® Anwendungskompatibilitäts-Toolkit 5.0, können Sie alle Anwendungen erfassen, die in Ihrer Umgebung verwendet werden. Dieses Tool bietet Ihnen verschiedene Möglichkeiten zum Ermitteln der Anwendungen, die in Ihrer Umgebung installiert sind, und konsolidiert die Ergebnisse in einer zentralen Datenbank.

Erstellen zusätzlicher Regeln
Sie verfügen jetzt über eine Liste der Anwendungen, die in Ihrer Umgebung ausgeführt werden dürfen. Nun können Sie die eigentlichen Regeln erstellen, von denen diese Anwendungen die Berechtigung zur Ausführung erhalten. Das Feature der Softwareeinschränkungsrichtlinien verwendet zwei Methoden zur Bestimmung von Richtlinien: Eine basiert auf den kryptografischen Eigenschaften einer Anwendung (z. B. dem Hash), und mit der anderen wird ein vertrauenswürdiger Pfad oder Ordner definiert, in dem sich vertrauenswürdige Anwendungen befinden sollten.
Abbildung 2 zeigt, wo Sie Regeln hinzufügen würden, um die Ausführung der Anwendungen im Knoten „Richtlinien für Softwareeinschränkung“ des Gruppenrichtlinienobjekt-Editors (gpedit.msc) zu erlauben. Die einfachste Möglichkeit zur Definition von Anwendungen in Ihrer Umgebung besteht darin, eine Hashregel für jede Binärdatei zu erstellen, auf die Sie in der Protokollierungsphase gestoßen sind.
Abbildung 2 Verwenden von gpedit.msc zum Erstellen von Softwareeinschränkungsrichtlinien
Abbildung 2 Verwenden von gpedit.msc zum Erstellen von Softwareeinschränkungsrichtlinien (Zum Vergrößern auf das Bild klicken)
Da der Hash ein eindeutiger Wert ist, der für einen bestimmten Bitsatz zurückgegeben wird, verfügt jede Binärdatei in Ihrer Richtlinie über einen anderen Hash. Dieser Ansatz bietet besonders viel Sicherheit, da nur den spezifischen Binärdateien in Ihrer Richtlinie die Ausführung erlaubt wird.
Selbstverständlich hat dieser Ansatz auch einige Nachteile. So könnte Ihre Umgebung beispielsweise ohne weiteres mehrere tausend Binärdateien enthalten. Es dürfte schwierig sein, alle diese Regeln in der Benutzeroberfläche für Softwareeinschränkungsrichtlinien zu erstellen. Bei einer besonders großen Zahl von Regeln kann außerdem die Leistung beeinträchtigt sein. Zudem muss bei jeder Anwendungsaktualisierung in Ihrer Umgebung mindestens eine neue Hashregel in der Umgebung bereitgestellt werden. Das Aktualisieren einer solch umfangreichen Richtlinie bei der Aktualisierung von Anwendungen kann eine äußerst aufwändige Aufgabe sein.
Dies lässt sich glücklicherweise vermeiden, da es zwei andere Methoden gibt, Regeln zu bestimmen, die Ihnen die Verwendung von Softwareeinschränkungsrichtlinien in Ihrer Umgebung erleichtern. Wenn Sie die Möglichkeiten nutzen, die kryptografische Sicherheit bietet, können Sie eine Regel erstellen, die die Ausführung aller Binärdateien zulässt, die von einem bestimmten Zertifikat signiert wurden.
Dies erleichtert die Wartung der Richtlinienliste, da bei der Aktualisierung einer Anwendung die neuen Binärdateien für gewöhnlich von demselben Zertifikat signiert werden wie die vorhergehenden. Wenn Sie aber nicht möchten, dass eine frühere Version der Binärdatei in Ihrer Umgebung ausgeführt wird, müssen Sie eine Hashregel „Eingeschränkt“ hinzufügen, um zu verhindern, dass die Datei ausgeführt werden kann.
Standardmäßig ist die Auswertung von Zertifikatregeln für Softwareeinschränkungsrichtlinien deaktiviert. Dafür gibt es zwei Gründe.
Erstens werden die Zertifikatregeln in den Softwareeinschränkungsrichtlinien vom Inhalt des Systemspeichers für vertrauenswürdige Herausgeber definiert. Da der Speicher für vertrauenswürdige Herausgeber noch anderen Zwecken dient als der Speicherung von Regeln für Softwareeinschränkungsrichtlinien, müssen zusätzliche Überlegungen angestellt werden, wenn er für das Feature der Softwareeinschränkungsrichtlinien genutzt wird.
Zweitens müssen Sie, um die Gültigkeit der Signatur einer Datei zu bestimmen, einen Hash der Datei mit den Signaturinformationen vergleichen. Das Hashing einer Datei ist ein sehr aufwändiger Vorgang: Die gesamte Datei muss vom Datenträger gelesen und dann verarbeitet werden, um diesen Hash zu berechnen.
Um Zertifikatregeln zur aktivieren, navigieren Sie zum Knoten „Richtlinien für Softwareeinschränkung“, und wählen Sie im Ergebnisbereich die Option für das Erzwingungsobjekt aus. Doppelklicken Sie darauf, um das Eigenschaftsdialogfeld zu öffnen, und wählen Sie die Optionsschaltfläche „Zertifikatregeln erzwingen“ aus.
Die zweite gebräuchliche Methode zur Identifizierung von Code besteht darin, den Pfad des Codes auf dem lokalen Computer zu verwenden. Dies ist eine wirksame und effiziente Methode, die aber einen Nachteil hat: Sie müssen darauf achten, die korrekten Sicherheitseinstellungen für den Ordner festzulegen.
Wenn Sie eine bestimmte Pfadregel hinzufügen und dieser Pfad Benutzern das Schreiben von Dateien an dieser Position (z. B. auf dem Desktop) ermöglicht, wäre eine unbeschränkte Ausführung aller Anwendungen möglich. Die ausführbaren Dateien müssten lediglich in diesem Ordner abgelegt werden. Wenn sich die Benutzer aber nicht in der Administratorengruppe befinden, fehlt ihnen in der Regel die Möglichkeit, Änderungen in den Verzeichnissen „Programme“ oder „Windows“ vorzunehmen. Wenn sich alle Ihre Anwendungen im Verzeichnis „Programme“ befinden und Ihre Benutzer keine Administratoren sind, sollten Sie den Einsatz von Pfadregeln erwägen, um eine einfache und effiziente Richtlinie zu erstellen.
Dank einiger ihrer Features sind Pfadregeln für bestimmte Umgebungen besser geeignet. Sie ermöglichen die Verwendung von Platzhaltern und Umgebungsvariablen und erleichtern damit die Definition von Regeln, die in Ihrer Umgebung übertragbar sind. Schließlich ist es möglich, dass nicht für alle Benutzer c:\ als %systemdrive% fungiert.
Im Hinblick auf Leistung und Wartung ist dies wahrscheinlich diejenige Methode zur Identifizierung von Code, die am wenigsten Probleme bereitet. Pfadregeln sind ganz sicher eine Möglichkeit, Sie müssen sich aber der zusätzlichen Sicherheitsaspekte bewusst sein.

Netzwerkzonenregeln
Die Softwareeinschränkungsrichtlinie umfasst einen Regeltyp namens „Netzwerkzonenregel“, obwohl dieser Regeltyp als veraltet angesehen wird. Die ursprüngliche Idee hinter diesen Regeln war, dass die Quelle von bestimmtem ausführbarem Code identifiziert und als vertrauenswürdig eingestuft werden konnte. Folglich konnte dem Code die Ausführung gestattet werden. Leider ist dies besonders schwierig zu erreichen und funktionierte daher nie besonders gut. Derzeit wird dieser Regeltyp an den meisten Einstiegspunkten der Softwareeinschränkungsrichtlinie nicht erzwungen.
In Fällen, in denen die Mehrheit der Anwendungen im Verzeichnis „%Programme%“ installiert ist, es aber weitere ausführbare Dateien an anderen Installationsorten gibt, die von einem bestimmten Zertifikat signiert sind, könnte es sinnvoll sein, Regeln anderer Typen zu verwenden. Ein paar Hashregeln, einige Pfadregeln, und schon haben Sie die richtige Richtlinie für Ihre Anforderungen gefunden.
Beachten Sie aber, dass die Regeln in einer bestimmten Reihenfolge verarbeitet werden (siehe Abbildung 3). Zertifikatregeln sind am spezifischsten, an zweiter Stelle stehen Hashregeln, dann folgen Pfadregeln und schließlich Pfadregeln mit Platzhaltern. Wenn also ein Codeabschnitt von einer Hashregel und einer Pfadregel identifiziert wird, erhält die Sicherheitsstufe der Hashregel Priorität.
Abbildung 3 Reihenfolge der Regelverarbeitung
Abbildung 3 Reihenfolge der Regelverarbeitung (Zum Vergrößern auf das Bild klicken)

Richtliniendurchsetzung
Das Feature der Softwareeinschränkungsrichtlinien lässt sich umfassend in dem zu sichernden System anwenden. Die Idee besteht darin, alle Speicherorte, an denen Code ausgeführt werden kann, in die Softwareeinschränkungsrichtlinie zu integrieren und dann wiederum die Richtlinie zu überprüfen, um zu sehen, ob dem ausführbaren Code die Ausführung ermöglicht wird.
Die Softwareeinschränkungsrichtlinie kann an zahlreichen Punkten überprüft werden, der einfachste Einstiegspunkt ist aber CreateProcess. Während CreateProcess wird die Richtlinie überprüft, um zu bestimmen, ob die Binärdatei, die die Anwendung repräsentiert, ausgeführt werden darf. Die Richtlinienüberprüfung wird von der API „SaferIdentifyLevel“ durchgeführt, die öffentlich dokumentiert ist. Der allgemeine Prozess ist in Abbildung 4 dargestellt. (Auf SaferIdentifyLevel kommen wir sogleich ausführlicher zurück.)
Abbildung 4 Verwenden von SaferIdentifyLevel, um zu bestimmen, ob eine Binärdatei ausgeführt werden darf
Abbildung 4 Verwenden von SaferIdentifyLevel, um zu bestimmen, ob eine Binärdatei ausgeführt werden darf (Zum Vergrößern auf das Bild klicken)
Die nach CreateProcess gebräuchlichste API bei der Durchsetzung der Softwareeinschränkungsrichtlinie ist ShellExecute. Dies ist die API, die aufgerufen wird, wenn der Benutzer im Startmenü auf eine Anwendung klickt oder auf ein Element auf dem Desktop doppelklickt.
ShellExecute kann für eine Vielzahl von Dateiformaten aufgerufen werden. Handelt es sich z. B. um eine .txt-Datei, führt der Aufruf der Datei durch ShellExecute nicht dazu, dass die Datei tatsächlich ausgeführt wird. Genau genommen wird die Datei natürlich geöffnet. Aus diesem Grund enthält die Softwareeinschränkungsrichtlinie eine Liste der Typen ausführbarer Dateien, damit kontrolliert werden kann, welche Dateitypen beim Aufruf von ShellExecute überprüft werden. Sie können diese Liste der Typen ausführbarer Dateien in der Benutzeroberfläche für Softwareeinschränkungsrichtlinien anpassen.
Außer CreateProcess und ShellExecute gibt es zwei weitere wichtige Integrationspunkte: LoadLibrary und Skripthosts. LoadLibrary ist offensichtlich ein wichtiger Ort, um ausführbaren Code zu überprüfen, bringt aber leider einige besondere Einschränkungen mit sich.
Für die meisten Anwendungen gibt es eine ausführbare Datei und mehrere DLLs, die geladen werden. In der Regel werden zahlreiche Anwendungen auf dem System ausgeführt. Dies bedeutet, dass für LoadLibrary die Überprüfung der Richtlinie in beträchtlichem Umfang erforderlich wäre. In Abhängigkeit von Ihrer Richtlinie für die Identifizierung von Code könnte die Durchsetzung an diesem Einstiegspunkt sehr aufwändig sein: Stellen Sie sich vor, Sie müssten den Hash jeder im System geladenen DLL überprüfen, was das Hashing der Binärdatei und den anschließenden Vergleich mit einer Liste vielleicht Tausender von Hashes einschließt.
Diese Funktion ist standardmäßig deaktiviert, kann aber manuell aktiviert werden. Navigieren Sie hierzu in gpedit.msc zum Knoten „Richtlinien für Softwareeinschränkung“, und doppelklicken Sie auf „Erzwingen“. Klicken Sie danach auf die Optionsschaltfläche „Alle Softwaredateien“.
Wie bereits erwähnt, ist die Softwareeinschränkungsrichtlinie in die meisten Skripthosts im System integriert. Dazu gehören cmd, VBScript, Cscript und JScript®. Diese Einstiegspunkte verwenden wie die anderen die primäre API zur Durchsetzung der Softwareeinschränkungsrichtlinie: SaferIdentifyLevel.
Die API „SaferIdentifyLevel“ bestimmt, ob eine angegebene ausführbare Datei ausgeführt werden darf, indem sie die Identifizierungsinformationen in den relevanten Softwareeinschränkungsrichtlinien abruft. Dies ist eine öffentlich dokumentierte API. Skripthosts von Drittanbietern und ausführbare Umgebungen können und sollten die API zur Integration in die Softwareeinschränkungsrichtlinie verwenden, damit die Richtlinie bestimmen kann, ob ein Abschnitt ausführbaren Codes ausgeführt werden darf.

Ausführung als Standardbenutzer
Ein weniger bekanntes Feature der Softwareeinschränkungsrichtlinien ist ihre Fähigkeit, die Berechtigungen bestimmter Anwendungen beim Anwendungsstart zu filtern. Diese Funktion wurde in Windows XP eingeführt, aber erst ab Windows Vista in der Benutzeroberfläche für Softwareeinschränkungsrichtlinien verfügbar gemacht.
Somit war sie ein Vorläufer der Benutzerkontensteuerung in Windows Vista, denn Sie konnten mit ihrer Hilfe eine Anwendung als Standardbenutzer ausführen, auch wenn der Benutzer Mitglied der Administratorengruppe war. Dies geschieht, wenn Sie eine Regel erstellen und als Sicherheitsebene in der Benutzeroberfläche unter „Zusätzliche Regeln“ die Option „Normal User“ (Normaler Benutzer) festlegen.
Sowohl die Funktion der Tokenfilterung der Benutzerkontensteuerung als auch die „Normal User“-Regeln der Softwareeinschränkungsrichtlinien nutzen eine zugrunde liegende API, die dasselbe Verhalten implementiert wie die API „CreateRestrictedToken“. Insgesamt gibt es aber bedeutende architektonische Unterschiede zwischen den Technologien. Die Benutzerkontensteuerung weicht in einigen wesentlichen Punkten von der Softwareeinschränkungsrichtlinie ab.
Erstens wird bei Aktivierung der Benutzerkontensteuerung in Windows Vista standardmäßig jede Anwendung mit einem Sicherheitstoken gestartet, das einem Mitglied der Benutzergruppe ähnelt. Dies gilt auch dann, wenn der Benutzer ein Administrator ist. Dies kann mit der Softwareeinschränkungsrichtlinie erreicht werden, aber es gibt keine Möglichkeit, eine Anwendung mit dem eigentlichen Administratortoken des Benutzers zu starten (z. B. wenn der Benutzer eine Anwendung installieren muss). Die wichtigsten Vorteile der Benutzerkontensteuerung sind die Änderung des Standardsicherheitskontexts und der einfache Zugriff auf das vollständige Administratortoken eines Benutzers.
Der zweite Unterschied besteht darin, dass der Code im Fall ausführbarer Dateien selbst ausdrückt, welche Berechtigungsstufe erforderlich ist, damit er funktionieren kann. Dies ist ein wichtiger Unterschied, weil unabhängige Softwarehersteller und Entwickler die Anforderungen ihres Codes verstehen. Wenn beispielsweise eine Systemsteuerungsanwendung ein Element bearbeiten muss, das Administratorberechtigungen erfordert, kann diese Anforderung in ihrer Manifestdatei festgelegt werden. Folglich kann der unabhängige Softwarehersteller die Berechtigungen beschreiben, die eine Anwendung benötigt, statt ihr eine bestimmte Berechtigungsstufe aufzuerlegen, ohne dass die Möglichkeit besteht, diese Stufe zu ändern.
Sofern Ihnen nicht hundertprozentig klar ist, wie die Regeln für normale Benutzer funktionieren, sollten Sie ihren Einsatz vorläufig vermeiden. Die Benutzerkontensteuerung ist eine hervorragende Möglichkeit, um die Desktopbenutzer aus der Administratorengruppe zu entfernen, und Sie sollten sie einfach in Ihrer Unternehmensumgebung belassen.

Heutige Verwendung der Softwareeinschränkungsrichtlinien
Beim Einsatz der Softwareeinschränkungsrichtlinie müssen Sie zusätzliche Aspekte berücksichtigen. Es ist aber einfacher, als Sie vielleicht denken. Möglicherweise verwenden Sie sogar schon Softwareeinschränkungsrichtlinien, ohne es zu wissen. Wenn Sie beispielsweise mit Jugendschutzeinstellungen auf einem Windows Vista-System arbeiten, verwenden Sie Softwareeinschränkungsrichtlinien, um die Ausführung der Anwendungen zu kontrollieren.
Bei ihrer Ersteinführung in Windows XP war die Softwareeinschränkungsrichtlinie eine wichtige technologische Entwicklung. Die Sperrung von Anwendungen rückt aber erst in letzter Zeit verstärkt in das Blickfeld von IT-Experten.
Das Feature der Softwareeinschränkungsrichtlinien in Windows Vista bedarf sicher noch der Optimierung. Schon heute ist aber klar, dass Administratoren diese verstärkte Kontrolle über die in ihrer Umgebung ausgeführten Anwendungen wünschen. Erfreulicherweise wird sich die Technologie weiterentwickeln und es IT-Experten erleichtern, ihre Systeme zu verwalten und die Kosten zu senken, die mit einer Microsoft Windows-Umgebung verbunden sind.
Die minimale Softwareeinschränkungsrichtlinie
Die Softwareeinschränkungsrichtlinie kann u. a. zum Erstellen einer Richtlinie genutzt werden, mit der Windows in einen Kioskmodus versetzt wird. Microsoft stellt sogar ein Toolkit namens SteadyState™ zum Erstellen dieses Kiosks her. Wenn Sie allerdings nur die Anwendungen sperren möchten, die ausgeführt werden können, gibt es eine einfachere Lösung.
Um dem Mindestsatz erforderlicher Anwendungen die Anmeldung bei Windows Vista zu ermöglichen, erstellen Sie eine Richtlinie, die logonui.exe und userinit.exe die Ausführung unter %windir%\system32 ermöglicht. Für die meisten Benutzer muss wahrscheinlich auch die Ausführung der folgenden Anwendungen erlaubt sein:
dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....
Wenn Sie die standardmäßige Windows-Shell wünschen, müssten Sie auch %windir%\explorer.exe hinzufügen.
Eine Alternative wäre es, direkt in eine Anwendung hinein zu starten, z. B. Internet Explorer®. In diesem Fall müssten Sie iexplore.exe statt explorer.exe auflisten.
Ein weiterer Aspekt dieser minimalen Richtlinie besteht darin, dass Ihre Benutzer sich nicht in der Administratorengruppe befinden dürfen. Dies ist wichtig, damit sie die Richtlinie nicht umgehen können. Da sie aber nur eine sehr beschränkte Gruppe von Anwendungen ausführen können und nicht über die Berechtigungen eines Administrators verfügen, fehlen den Benutzern die Berechtigungen zum Installieren von Anwendungen oder zur Wartung des Systems.
Sie müssen eine Möglichkeit einrichten, dies für die betreffenden Computer auszuführen. Wenn Sie vorhaben, diese Computer zu aktualisieren und zu warten, indem Sie sich lokal mit einem Administratorkonto anmelden, sollten Sie die Optionsschaltfläche auswählen, mit der die Softwareeinschränkungsrichtlinie auf alle Benutzer mit Ausnahme lokaler Administratoren angewendet wird. Die Richtlinie sollte außerdem consent.exe und cmd.exe einschließen. Dies ermöglicht es dem Administrator, beliebige Verwaltungsoptionen über eine Administrator-cmd-Eingabeaufforderung zu starten.
Beachten Sie, dass die Benutzerkontensteuerung die Berechtigungen des Sicherheitstokens des Benutzers standardmäßig beschränkt, damit der Anschein erweckt wird, das Token sei kein Mitglied der Administratorengruppe. Selbst wenn Sie die obige Einstellung so festlegen, dass sie die Richtlinie nicht auf Administratoren anwendet, wird die Richtlinie trotzdem auf die Benutzer angewendet. Nur wenn Sie die Berechtigungen der Benutzerkontensteuerung erweitern, erhält der Administrator tatsächlich die vollständigen Administratorrechte, und die Softwareeinschränkungsrichtlinie wird nicht angewendet.

Chris Corio Chris Corio gehörte mehr als fünf Jahre lang dem Windows Security-Team bei Microsoft an. Sein Arbeitsschwerpunkt bei Microsoft waren Anwendungssicherheitstechnologien und Verwaltungstechnologien zur Sicherung von Windows. Sie erreichen Chris Corio unter winsecurity@chriscorio.com.
Durga Prasad Sayana Durga Prasad Sayana ist als Software Design Engineer/Test im Windows Core Security-Team tätig. Seine Hauptinteressen liegen in den Bereichen Sicherheitstechnologien und Softwareprüfung. Sie erreichen Durga Prasad Sayana unter durgas@microsoft.com.


Sicherheit
Verwalten der Windows Vista-Firewall
Jesper M. Johansson
Auf einen Blick:
  • Regeltypen und Szenarios
  • Firewallprofile
  • Domänenisolationsregeln
  • Das Problem mit ausgehender Filterung

Vor einer Weile habe ich in meinem Blog einen Artikel über die Windows Vista-Firewall geschrieben. Dieser Beitrag wies nur auf einige der interessanten Features hin, bot aber nicht viele Hinweise für die Bereitstellung.
Im heutigen Artikel werden die Einzelheiten einiger Features der Windows Vista®-Firewall näher beleuchtet, die insbesondere die Unternehmensverwaltung erleichtern sollen. Weiterhin erhalten Sie Ratschläge, wie sich Ihre Arbeit durch Einsatz dieser Features erleichtern lässt und Sie für erhöhte Benutzersicherheit sorgen können.
Aufgrund der neuen Freigabe von SP1 für Windows Vista ist zu erwarten, dass die Unternehmensbereitstellung von Windows Vista jetzt anläuft. (Es ist für Unternehmen üblich, dass sie vor dem Wechsel zu einem neuen Betriebssystem auf die Veröffentlichung des ersten Service Packs warten.) Wenn Sie zu den IT-Experten gehören, die Windows Vista jetzt ernsthafter für ihre Unternehmensumgebung in Erwägung ziehen, sollten Sie sich die Firewall genauer anschauen. Wenn Ihnen die Vorteile der Windows Vista-Firewall erst einmal bewusst werden, entscheiden Sie sich vielleicht, den Vertrag über die Sicherheitssuite mit dem Drittanbieter neu auszuhandeln, um die Firewall aus dem Paket zu entfernen.

Windows-Firewalls damals und heute
Die Firewall in der ursprünglichen Veröffentlichung von Windows® XP ließ viel zu wünschen übrig. Zwar entsprach sie damals in angemessener Weise den Sicherheitsfunktionen in kommerziellen hostbasierten Firewalls, brachte aber nichts Neues oder Innovatives.
Die Firewall in Windows XP SP2 dagegen wurde vollständig verändert. Sie wurde speziell entworfen, um die Verwaltbarkeit in Unternehmen zu erleichtern. Die Windows XP SP2-Firewall ist sehr attraktiv, da sie einfach, zentral verwaltbar, effizient und nicht intrusiv ist. Am wichtigsten ist aber vielleicht, dass sie eine sehr entscheidende Funktion erfüllt: Die Windows XP SP2-Firewall schützt das System beim Startvorgang.
Dieser letzte Punkt ist entscheidend. Ich habe in der Vergangenheit viele Systeme gesehen, die während des Startvorgangs selbst bei eingeschalteter Firewall infiziert wurden. Auf dem Höhepunkt der Blasterepidemie stiegen die Angriffsraten auf einen Angriff in vier Minuten an. Anders gesagt, wenn Sie einen ungeschützten Computer ans Internet angeschlossen ließen, konnte er in durchschnittlich vier Minuten infiziert werden. Wenn Sie sich auf eine Firewall verließen, die das System nicht beim Startvorgang schützte, wurde eins von zwölf Systemen beim Neustart infiziert. Diese Zahlen veranlassten Microsoft, dafür zu sorgen, dass die Windows XP SP2-Firewall das System beim Startvorgang schützt.
In Windows Vista erhielt die Firewall eine weitere vollständige Überarbeitung. Im Hinblick auf die Verwaltung besteht die offensichtlichste Änderung darin, dass die Verwaltungsschnittstellen der Internetprotokollsicherheit (Internet Protocol Security, IPsec) und der Firewall zusammengeführt wurden. Dies ist eine sehr logische Änderung. Sowohl IPsec als auch die Firewall dienen dazu, alles nicht Zugelassene zu blockieren. Der Unterschied besteht darin, dass in der Firewall die Parameter für die Definition dessen, was zugelassen ist, nicht sehr präzise sind, während es in IPsec umständlich ist, umfangreiche Adressbereiche zu sperren oder zuzulassen.
Da sich nun beide Features in einer einzigen Verwaltungsschnittstelle befinden, können Administratoren beide Technologien nahtlos nutzen und sich dabei weniger Sorgen darum machen, ob eine IPsec-Regel oder eher ein Firewallfilter erforderlich ist. Im Wesentlichen erhalten Sie eine einzige Ansicht der Netzwerkangriffsfläche des Systems, und dies hilft, das Fehlerrisiko zu minimieren.
In SP1 für Windows Vista werden den Firewallfeatures einige Verbesserungen im Bereich Zuverlässigkeit hinzugefügt. SP1 enthält außerdem neue Algorithmen, insbesondere die Suite-B-Algorithmen für die Verwendung in IPsec. Dabei handelt es sich um einen Satz an Verschlüsselungsalgorithmen, zu denen der erweiterte Verschlüsselungsstandard (Advanced Encryption System, AES), die Verschlüsselung mittels elliptischer Kurven (Elliptic Curve Cryptography, ECC) und der sichere Hashalgorithmus (Secure Hash Algorithm, SHA) 256 und 384 gehören.
Am wichtigsten ist jedoch, dass in Service Pack 1 Support für den Netzwerkzugriffsschutz (Network Access Protection, NAP) hinzufügt wird. NAP ist ein Tool zur Durchsetzung von Richtlinien, mit dem sichergestellt wird, dass verwaltete und nicht beeinträchtigte Clients mit den aktuellen Sicherheitsrichtlinien, Updates und Antimalwaredefinitionen auf dem neuesten Stand sind, bevor sie eine Verbindung zum Netzwerk herstellen dürfen. NAP kann schädliche Hosts nicht daran hindern, eine Verbindung zum Netzwerk herzustellen, aber es wird gewährleistet, dass alle verwalteten Hosts vollständig konform sind, solange sie nicht aktiv beeinträchtigt sind.
Die Windows Vista-Firewall wird als Windows-Firewall mit erweiterter Sicherheit bezeichnet und ist auch in Windows Server® 2008 enthalten. Sämtliche Features lassen sich auch von einem Remotestandort aus verwalten und mithilfe der Gruppenrichtlinie über ein Netzwerk konfigurieren.

Regeltypen und Szenarios
Die Kombination von Firewall- und IPsec-Funktionen in der Verwaltungsschnittstelle bedeutet, dass es jetzt zwei verschiedene Regeltypen gibt: Richtungsregeln und Verbindungsregeln. Richtungsregeln sind Standardfirewallregeln, die definieren, welcher Datenverkehr in der entsprechenden Richtung zugelassen wird. Verbindungsregeln definieren die Schutzparameter für Verbindungen zwischen Computern. Vergleichsweise ähneln Richtungsregeln den Firewallregeln, die Sie aus früheren Firewalls kennen, während Verbindungsregeln mehr den IPsec-Regeln ähneln, die in Verbindung mit der Firewall in Windows XP SP2 verwendet werden.
Die Zusammenfassung von Firewall und IPsec in derselben Schnittstelle ermöglicht mehrere sehr interessante Szenarios. So besteht beispielsweise eines der wertvollsten heute verfügbaren Sicherheitskonzepte darin, Systeme im Netzwerk voneinander zu isolieren. Microsoft bezeichnet dies als „Server- und Domänenisolation“.
Die Server- und Domänenisolation verwendet sowohl IPsec- als auch Firewallfunktionen. Deshalb enthält die neue Firewallverwaltungsschnittstelle bestimmte Funktionen für Isolationsregeln. Diese sind geeignet, wenn Sie beispielsweise die Verbindung aufgrund von Attributen des Quell- oder Zielsystems, z. B. der Domänenmitgliedschaft, einschränken wollen.
Wie Sie in Abbildung 1 sehen können, beginnt der Assistent für neue Verbindungssicherheitsregeln mit der Frage, welchen Regeltyp Sie erstellen wollen. Wenn Sie Isolation auswählen, konfiguriert der Assistent bestimmte Einstellungen vor, die für eine Isolationsregel geeignet sind.
Abbildung 1 Erstellen einer Isolationsregel mithilfe des Assistenten für neue Verbindungssicherheitsregeln
Abbildung 1 Erstellen einer Isolationsregel mithilfe des Assistenten für neue Verbindungssicherheitsregeln (Zum Vergrößern auf das Bild klicken)
Möglicherweise bemerken Sie in Abbildung 1 auch, dass die Isolationsregel den Integritätsstatus erwähnt. Die für die Server- und Domänenisolation verwendeten Regeln sind eigentlich die gleichen wie die für NAP.
Sie können für einige Arten von Verkehr keine Authentifizierung erzwingen. Zum Beispiel soll wahrscheinlich für die DNS-Auflösung keine Authentifizierung erforderlich sein. Für die Endpunkte dieser Art von Verkehr benötigen Sie eine Regel für die Ausnahme von der Authentifizierung. Eine Regel für die Ausnahme von der Authentifizierung fungiert genauso, wie es der Name schon sagt: Datenverkehr wird von den IPsec-Anforderungen ausgenommen.
Eine Server-zu-Server-Regel ist eigentlich eine Fehlbenennung. Sie wird zwar häufiger für Server eingesetzt, kann aber auch für Clients verwendet werden. Mit einer Server-zu-Server-Regel wird eine Verbindung lediglich so konfiguriert, dass eine Authentifizierung erforderlich ist. Sie unterscheidet sich von einer Isolationsregel darin, dass eine Isolationsregel nicht nur Authentifizierung erfordert, sondern auch die Erfüllung einiger zusätzlicher Kriterien wie Domänenmitgliedschaft oder Integritätsstatus.
Eine Tunnelregel definiert im Wesentlichen ein Standort-zu-Standort-VPN (virtuelles privates Netzwerk) sowie den Tunnel zwischen den Gateways. Tunnelregeln werden in Windows Vista selten verwendet, da es unwahrscheinlich ist, dass Windows Vista als Gateway eingesetzt wird. Sie können vollständig benutzerdefinierte Regeln erstellen. Dadurch können Sie alle Parameter der Regel anpassen.

Reihenfolge der Regeln
Die Reihenfolge der Regeln ist auf den ersten Blick etwas kompliziert. Der Schlüssel zum Verständnis der Reihenfolge der Regeln besteht darin, zunächst die Frage nach der Reihenfolge außer Acht zu lassen. Es geht nicht so sehr um die Reihenfolge, sondern um die Auswahlregel. Betrachten wir als Beispiel den eingehenden Datenverkehr. Eingehender Datenverkehr, der keiner Regel entspricht, die ihn zulässt, wird standardmäßig blockiert. Sie betrachten dies vielleicht als eine Reihenfolge mit dem Inhalt „Zulassungsregeln werden zuerst berücksichtigt“, aber eine solche Annahme wäre falsch. Wenn ein bestimmtes Paket sowohl einer Zulassungsregel als auch einer Blockierungsregel entspricht, gewinnt die Blockierungsregel. Einfach ausgedrückt bedeutet dies folgende Trefferbedingung:
  1. Blockierungsregeln. Wenn ein Paket oder eine Verbindung einer Blockierungsregel entspricht, wird es verworfen.
  2. Zulassungsregeln. Wenn ein Paket oder eine Verbindung einer Zulassungsregel entspricht, wird es zugelassen.
  3. Standardverhalten des Richtungsprofils. Wenn keine Blockierungs- oder Zulassungsregeln passen, wird der Datenverkehr gemäß dem Verhalten behandelt, das als Standard für Datenverkehr in dieser Richtung und in diesem Profil angegeben ist. In der eingehenden Richtung in allen Profilen bedeutet dies das Blockieren des Datenverkehrs in einer Standardkonfiguration. In der ausgehenden Richtung bedeutet es standardmäßig, dass der Datenverkehr in der Standardkonfiguration zugelassen wird.
Die Regelprüfung wird durch Regeln zur authentifizierten Umgehung (IPsec) eingeschränkt. Mithilfe dieses Regeltyps wird der gesamte authentifizierte Datenverkehr, der den anderen Parametern der Regel entspricht, zugelassen, unabhängig davon, ob er irgendwelchen sonstigen Regeln entspricht. Regeln zur authentifizierten Umgehung sind Richtungsregeln, bei denen die Option „Regeln zum Blocken außer Kraft setzen“ aktiviert ist, wie in Abbildung 2 dargestellt. Diese werden zuerst berücksichtigt, damit authentifizierter Datenverkehr das System immer erreicht. Dies ist entscheidend, damit Sie Datenverkehr von authentifizierten Hosts problemlos zulassen, Datenverkehr von allen anderen jedoch blockieren können. Diese Regel können Sie als die Nummer 0 in der Reihenfolge betrachten. Dann sieht die vollständige Reihenfolgenliste der Regeln wie folgt aus:
Abbildung 2 Aktivieren der Option „Regeln zum Blocken außer Kraft setzen“, um eine Regel zur authentifizierten Umgehung zu konfigurieren
Abbildung 2 Aktivieren der Option „Regeln zum Blocken außer Kraft setzen“, um eine Regel zur authentifizierten Umgehung zu konfigurieren (Zum Vergrößern auf das Bild klicken)

0. Regel zur authentifizierten Umgehung
1. Blockierungsregeln
2. Zulassungsregeln
3. Standardverhalten des Richtungsprofils

Es ist unerheblich, ob es innerhalb der jeweiligen Klasse mehrere Regeln gibt, die dem Verkehrsmuster entsprechen. Sobald eine Regel dem Datenverkehr entspricht, wird die Regelverarbeitung beendet.

Öffentlich, privat und Domäne
Netzwerkressourcen
  • TechNet-Sicherheitscenter
  • Verwenden des Befehlszeilentools „Netsh Advfirewall“
  • Sicherheitsregeln für die Windows-Firewall und für IPsec-basierte Verbindungen in Windows Vista und Windows Server 2008
  • Sicherheit auf dem Prüfstand mithilfe des SCW unter Windows Server 2008

Die neue Firewall hat drei Profile: Öffentlich, privat und Domäne. Die Windows XP SP2-Firewall hatte hingegen zwei Netzwerkprofile: Standard und Domäne. Das Domänenprofil wird automatisch aufgerufen, wenn der Computer den Domänencontroller finden kann. In Windows XP wurde das Standardprofil anders verwendet. Dies bot leistungsfähige Funktionalität für einen Sicherheitsadministrator, der den Computer beim Roaming vollständig sperren und dennoch die gesamte Remoteverwaltungsfunktionalität zulassen konnte, die für den Zugriff auf das Netzwerk der Organisation erforderlich ist. Dieser Ansatz brachte jedoch für einige Benutzer gewisse Probleme mit sich, insbesondere für solche mit persönlichen Netzwerken zu Hause. Da immer das Standardprofil verwendet wurde, wenn das System den Domänencontroller nicht erreichen konnte, wurde das System von der Wohnung des Benutzers aus gesperrt.
Das neue private Profil in Windows Vista trägt zur Lösung dieses Problems bei. Wenn Sie jetzt das System mit einem neuen Netzwerk verbinden, werden Sie gefragt, ob dieses Netzwerk öffentlich (dies ist einfach der neue Name für das ehemalige Standardprofil) oder privat ist, und das System wird entsprechend konfiguriert. Daran erinnert sich das System jedes Mal, wenn eine Verbindung zu diesem bestimmten Netzwerk hergestellt wird, und zwar in Abhängigkeit von Netzwerkparametern, die dem System durch die Infrastrukturserver im Netzwerk anzeigt werden. Dies ist nicht absolut sicher, aber es hilft dadurch, dass sich mehr Netzwerke besser sperren lassen.
Die Logik für die Erkennung, ob das System in der Domäne ist, wurde ebenfalls verbessert. Dies führt zu einem schnelleren, zuverlässigeren Übergang und zu weniger Systemen, die das öffentliche oder private Profil verwenden, wenn sie sich in Wirklichkeit in der Domäne befinden.
Sie können die Regeln an einen bestimmten Netzwerktyp binden und so das System daran hindern, zu viele Informationen anzubieten und zu versuchen, eine Verbindung zu Systemen in nicht vertrauenswürdigen Netzwerken herzustellen. Dies ist einer der Bereiche, in denen sich die Integration von Firewall und IPsec auszuzahlen beginnt.
Mit diese neuen Regeln können Sie Einschränkungen vorsehen, die früher nicht möglich waren. Beispielsweise haben Angreifer viele Jahre lang mit Lockangriffen versucht, Benutzer dazu zu bewegen, SMB-Verbindungen (Server Message Block, SMB) für Windows-Netzwerke zu nicht vertrauenswürdigen Hosts herzustellen, wodurch eine Authentifizierungssequenz erzwungen wird, die ein Challenge-Response-Paar liefert, mit dem sich Kennwörter knacken lassen. Ältere Versionen dieses Angriffs wurden auch verwendet, um die Authentifizierung zu Klartext herabzustufen oder um das Challenge-Response-Paar des Benutzers an den Computer zurückzugeben, von dem es stammte. Die erste dieser Techniken wurde bereits vor Jahren ausgemerzt. Die letztere Technik wurde mit Windows XP SP2 bekämpft. Bedenken Sie aber, dass es dennoch unklug ist, Challenge-Response-Paare anzubieten.
Um dies zu verhindern, könnten Sie eine andere neue Funktion in der Windows Vista-Firewall verwenden: die ausgehende Filterung. Ein Administrator könnte zum Beispiel beschließen, alle ausgehenden SMB-Verbindungen (diejenigen, die an den Ports TCP 135, 139, 445 und UDP 137, 138, 445 enden) im öffentlichen Profil zu blockieren. Dann würde es schwieriger, ein System durch einen Lockangriff zur Gewinnung von Challenge-Response-Paaren zu verwenden, oder es würde daran gehindert, auf nicht vertrauenswürdige Windows-Dateifreigaben im Internet zuzugreifen.
Aber auch dies bietet keine absolute Sicherheit. Wenn zum Beispiel das System bereits beeinträchtigt wurde, würde diese Regel das System nicht an der Kommunikation nach außen hindern, da der Angreifer die Regel einfach deaktivieren könnte. Es kann jedoch als Maßnahme sehr nützlich sein, um Systeme zu schützen, die sich korrekt verhalten, aber möglicherweise Angriffen ausgesetzt sind.
In diesem Kontext muss erwähnt werden, dass ebenso wie in Windows XP SP2 in Windows Vista und Windows Server 2008 jeweils nur ein Profil aktiv sein kann. Wenn es zwei aktive Netzwerkschnittstellen im System gibt, von denen eine in der Domäne ist, während sich die andere in einem öffentlichen Netzwerk befindet, wird das öffentliche Firewallprofil auf beide angewendet. Es wird immer das Profil mit den größten Einschränkungen angewendet. Sie können sich vielleicht denken, dass das öffentliche Profil mit stärkeren Einschränkungen verbunden ist als das private Profil, und das private Profil mit stärkeren Einschränkungen als das Domänenprofil. Bedenken Sie, dass die Blockierungsregel für ausgehende SMB viel Datenverkehr über VPN-Verbindungen unterbrechen kann.
Um Datenverkehr über eine VPN-Verbindung zu ermöglichen, wenn der Computer in ein öffentliches oder privates Netzwerk eingebunden ist, erstellen Sie Richtungsregeln, die nur für VPN-Schnittstellen gelten. Damit dies funktioniert, müssen die VPN-Schnittstellen als solche von Windows erkannt werden. Wenn Sie nicht den VPN-Server für Microsoft® Routing- und RAS-Dienste verwenden, testen Sie diese Funktionalität vor der allgemeinen Bereitstellung. Ein Problem besteht hauptsächlich mit eingehendem Datenverkehr zum Client und etwaigen benutzerdefinierten Regeln für ausgehenden Datenverkehr, die Sie erstellen.

Erstellen von Firewallregeln
Eine Firewallregel zu erstellen, ist in der neuen Firewall viel einfacher. Mit dem Assistenten für neue Regeln, der in Abbildung 3 dargestellt ist, können Sie alle üblichen Regeltypen definieren. Er enthält auch vordefinierte Regeln für bestimmte Dienste.
Abbildung 3 Vordefinierte Regeln im Assistenten für neue Regeln
Abbildung 3 Vordefinierte Regeln im Assistenten für neue Regeln (Zum Vergrößern auf das Bild klicken)
Die vordefinierten Regeln sind besonders wichtig. Bei Serverisolation geht es im Wesentlichen darum, Dienste so einzuschränken, dass sie nur für diejenigen Systeme verfügbar sind, die sie wirklich benötigen. Auf Serverprodukten wird dies durch den Windows Sicherheitskonfigurations-Assistenten (Security Configuration Wizard, SCW) erleichtert, ist aber immer noch nicht ganz mühelos. (Auf den SCW wurde in der Ausgabe des TechNet Magazins vom März 2008 näher eingegangen.)
Die Clientversionen von Windows hatten bisher jedoch keine ähnlichen Funktionen. Wenn Sie den vordefinierten Regeltyp verwenden, ist ein großer Teil der Arbeit bereits erledigt, nämlich die Aufgabe zu ermitteln, welche Endpunkte ein Dienst verwendet. Die Firewall ist nicht nur in dem Sinne anwendungsorientiert, dass sie weiß, welches Programm der „iSCSI-Dienst“ repräsentiert, sondern sie enthält auch vordefinierte Regeln, die bestimmte Funktionen beschreiben. Dadurch können Sie sich auf die Frage konzentrieren, welche Computer in einer Regel abgedeckt werden müssen. Das ist immer noch eine schwierige und zeitaufwändige Aufgabe, aber wenigstens eine für Ihre Umgebung spezifische.
Es gibt auch eine benutzerdefinierte (im Dropdown in Abbildung 3 verschlüsselte) Regel, die Ihnen die gesamte Flexibilität gewährt, die Sie von einer authentifizierenden Firewall erwarten können. Wenn Sie zum Beispiel eine Regel wünschen, die nur IPsec-verschlüsselten Datenverkehr zulässt, so wählen Sie die Option aus, bei der nur sichere Verbindungen auf der Seite „Aktion“ des in Abbildung 2 gezeigten Assistenten zugelassen werden.
Bei dieser Auswahl haben Sie auch die Option, die Verschlüsselung einzuschalten. Wenn Sie diese Option leer lassen, verwendet der Datenverkehr ESP-NULL (Encapsulating Security Payload mit einem NULL-Schlüssel). Dies ist die empfohlene Möglichkeit, IPsec zur Authentifizierung zu verwenden. Die meisten Netzwerkverwaltungstools funktionieren dadurch weiterhin, da der Datenverkehr das Netzwerk im Klartext durchläuft, und wenn Sie je eine Verschlüsselung wünschen, können Sie einfach das Feld markieren.
In vielen Situationen ist die Verschlüsselung des Netzwerkverkehrs nicht annähernd so wichtig wie die Nichtannahme etwaigen Datenverkehrs von schädlichen Hosts. Die Verschlüsselung des Datenverkehrs im Netzwerk hindert einen Angreifer, der sich Zugang zum Netzwerk verschafft hat, den Inhalt des Pakets zu sehen. Wenn Authentifizierung erfordert wird, werden Sie möglicherweise daran gehindert, das Paket überhaupt zu senden und angegriffen zu werden. In vielen Situationen ist die Verschlüsselung auf Netzwerkebene natürlich wichtig, aber es gibt auch viele andere Situationen, in denen nur Authentifizierung erforderlich ist.

Erstellen von Domänenisolationsregeln
In den meisten Umgebungen wird verlangt, dass lediglich eine begrenzte Anzahl von Computern Datenverkehr an eine Arbeitsstation senden kann. Zumindest sollten alle Arbeitsstationen mit Domänenisolationsregeln konfiguriert werden. Dies war in Windows XP kompliziert, ist aber in Windows Vista einfach.
Öffnen Sie zunächst das Verwaltungstool Ihrer Wahl, und wählen Sie den Knoten „Verbindungssicherheitsregeln“ aus. Klicken Sie dann mit der rechten Maustaste auf den Knoten, und wählen Sie „Neue Regel“ aus. Der in Abbildung 1 dargestellte Dialog wird angezeigt. Wählen Sie „Isolationsregel“ aus, und klicken Sie auf „Weiter“. Jetzt müssen Sie auswählen, ob die Regel erzwungen werden soll oder nicht. In den meisten Fällen soll auf Arbeitsstationen wahrscheinlich eine Authentifizierung für eingehenden Datenverkehr erfolgen. Dies hindert jeden nicht mit der Domäne verbundenen Computer, Datenverkehr an die Arbeitsstation zu senden. Um jedoch Dienste von Infrastrukturdiensten anzufordern, muss das System gewissen ausgehenden Datenverkehr im Klartext zulassen. Die beste Option besteht deshalb darin, für eingehende Verbindungen Authentifizierung zu erfordern und für ausgehende Verbindungen Authentifizierung anzufordern.
Wählen Sie als Nächstes die Authentifizierungsmethode aus. Die Standardauswahl wird „Standard“ genannt, was nicht gerade eine besonders hilfreiche Bezeichnung ist. Sie können die Standardauthentifizierungsmethode auf Computerbasis in den IPsec-Eigenschaften konfigurieren (klicken Sie mit der rechten Maustaste auf den Knoten „Windows-Firewall mit erweiterter Sicherheit“, und wählen Sie dann „Eigenschaften“ aus). Die Standardauthentifizierungsmethode ist immer Kerberos, die einfachste und sicherste Methode. Aus Gründen der Verständlichkeit empfehle ich jedoch, dass Sie sie beim Erstellen der Regeln tatsächlich auswählen. Normalerweise ist erforderlich, dass sich nur der Computer authentifiziert, nicht auch der Benutzer. Wenn Sie von beiden eine Authentifizierung erfordern, können unter Umständen bestimmte Arten von Verwaltungsdatenverkehr, z. B. anonym übertragener SNMP-Datenverkehr, nicht entgegengenommen werden.
Nach Auswahl der Authentifizierungsmethode brauchen Sie nur noch auszuwählen, in welchen Profilen diese Regel verfügbar sein soll. Da diese Regel für mit der Domäne verbundene Computer gilt, die ein Kerberos-Ticket vorlegen können, ist es nicht sinnvoll, dies für private oder öffentliche Profile auszuwählen. Speichern Sie die Regel, und Sie sind fertig.
Grundlegende Isolationsregeln sind nicht mehr kompliziert. Um jedoch die Isolationsfähigkeit von IPsec zu nutzen, müssen Sie auch auf Ihren Arbeitsstationen die Serverisolation implementieren. Dadurch können Sie Ihre Arbeitsstationen hindern, andere Clients abzuhören. Sie antworten stattdessen nur den entsprechenden Verwaltungsstationen. Stellen Sie sich vor, wie viel weniger Auswirkungen manche Malwareangriffe gehabt hätten, wenn Clientsysteme abgelehnt hätten, andere Clients abzuhören.

Skripterstellung für die Firewall
Die neue Firewall bietet eine umfassende API, mit der Sie Skripts sowohl für die Bereitstellung als auch für die Bewertung erstellen können. Im Idealfall sollten für die Bereitstellung die Gruppenrichtlinien verwendet werden, aber da Gruppenrichtlinien nicht immer verfügbar sind, ist ein richtiger API-Satz zum Konfigurieren der Firewall wichtig. Die APIs sind unter dem INetFWPolicy2-Satz von APIs zusammengefasst. Im Software Development Kit und in der MSDN®-Bibliothek finden Sie vollständigere Angaben zur Verwendung dieser APIs, aber anhand einiger Beispiele lassen sich die wesentlichen Punkte gut erläutern.
Ein häufiges Beispiel ist das Feststellen, ob eine Gruppe von Regeln eingeschaltet ist. So muss beispielsweise eine Anwendung oder ein Administrator feststellen, ob die Datei- und Druckerfreigabe von einem System zugelassen ist. Dies kann durch die INetFWPolicy2::IsRuleGroupCurrentlyEnabled-API erreicht werden. Abbildung 4 liefert ein Beispiel für ein VBScript, das diese Funktion veranschaulicht.
Figure 4 Verwenden von INetFWPolicy2::IsRuleGroupCurrentlyEnabled
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if
Falls nun die Datei- und Druckerfreigabe ausgeschaltet ist und Sie diese einschalten müssen, so müssen Sie zuerst sicherstellen, dass dies möglich ist und nicht durch Gruppenrichtlinien außer Kraft gesetzt wird. Dies erfolgt mit der INetFWPolicy2::LocalPolicyModifyState-API. Nachfolgend sehen Sie ein Grundgerüst, das mit Code ausgefüllt werden kann:
Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Befehlszeile und Schnittstellentypen
Keine Firewall wäre ohne eine richtige Befehlszeile für die Verwaltung vollständig. Es gibt unter Netsh einen Unterkontext mit der Bezeichnung „advfirewall“. Der „advfirewall“-Kontext gibt Ihnen Befehlszeilenzugriff auf alle Funktionen, die in der grafischen Benutzeroberfläche ausgeführt werden können. Wenn Sie zum Beispiel auf Port 445 die Blockierung des ausgehenden Datenverkehrs implementieren wollen, können Sie von einer Eingabeaufforderung mit erweiterter Berechtigung den folgenden Befehl ausführen:
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
Anschließend müssen Sie den gleichen Befehl ausführen und dabei TCP durch UDP ersetzen, um die Sperre fertigzustellen. Dann ist die Implementierung der Regel abgeschlossen.
Ein interessantes Feature in der Firewall ist die Möglichkeit, Regeln basierend auf dem Netzwerkschnittstellentyp zu konfigurieren. Beachten Sie, dass einige Regeln sich auf VPN-Verbindungen auswirken können. Solange Windows die Schnittstelle als eine VPN-Schnittstelle erkennt, können Sie diesen Regeltyp verwenden, um Datenverkehr über diese Schnittstelle auszuschließen:
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
Dies ist auch in der grafischen Benutzeroberfläche möglich, allerdings erst nach Erstellen der Regel. Sie müssen dann mit der rechten Maustaste auf die Regel klicken, „Eigenschaften“ auswählen und auf die Registerkarte „Erweitert“ klicken. Dort finden Sie einen Abschnitt „Schnittstelltypen“, in dem Sie die richtigen Schnittstellentypen auswählen können.

Ausgehende Filterung
Das Fehlen der ausgehenden Filterung in der Windows XP SP2-Firewall wurde als wichtigster Beweis dafür vorgebracht, dass die integrierte Firewall für die Sicherheit nicht ausreicht. Es sind wohl Tausende von Artikeln darüber geschrieben worden, wie unsicher die Windows XP SP2-Firewall aufgrund der fehlenden ausgehenden Filterung sei, und zwar trotz der Tatsache, das keine Firewall unter Windows XP eine sichere ausgehende Filterung bieten konnte.
Die grundlegende Funktionalität, die die ausgehende Filterung von einer bloßen Bremsfunktion – oder einem Tool zur Durchsetzung von Richtlinien, wie ich es früher verwendete – in ein nützliches Sicherheitsfeature verwandelt, existiert in Windows XP einfach nicht. Sie ist aber in Windows Vista vorhanden. Es ist daher nur logisch, dass die neue Firewall dieses Feature nutzt. Standardmäßig wird der meiste eingehende Datenverkehr blockiert und der meiste ausgehende Datenverkehr zugelassen.
Standardmäßig blockiert die ausgehende Filterung in der neuen Windows Vista-Firewall nur unnötigen Datenverkehr von Diensten. Mehr kann im Prinzip nicht erfolgen, um auf dem Host, der die ausgehenden Filter bereitstellt, Schutz vor Angriffen zu bieten. Unter Windows XP wäre dies unsinnig gewesen.
Dienste in Windows Vista können mit einem sehr eingeschränkten Token ausgeführt werden. Im Wesentlichen verfügt jeder Dienst über eine eigene und eindeutige Sicherheits-ID (SID). Diese Dienst-SID kann verwendet werden, um den Zugriff auf Ressourcen wie Netzwerkports einzuschränken. Es handelt sich dabei um die gleiche Funktionalität wie bei der Einschränkung des Datenverkehrs an Benutzer. Obwohl daher möglicherweise zwei Dienste als NetworkService ausgeführt werden, können sie nicht die Prozesse des jeweils anderen Diensts verwalten, und die Firewall kann so konfiguriert werden, dass nur einer von ihnen nach außen kommunizieren kann. Wenn der blockierte Dienst beeinträchtigt wird, kann er nicht die Kontrolle über den zugelassenen Dienst übernehmen und dessen zugelassenen Port verwenden, um nach außen zu kommunizieren, weil der Port durch die Dienst-SID eingeschränkt ist.
Diese Funktion ist ein weiteres der sehr interessanten Sicherheitsfeatures in Windows Vista, das von der neuen Firewall verwendet wird, um durch die ausgehende Filterung der Firewall wirkliche Sicherheit zu bieten.
Die Firewallfilterung auf Basis von Dienst-SIDs ist in der neuen Firewall standardmäßig aktiviert. Es gibt jedoch keine grafische Benutzeroberfläche, um sie zu konfigurieren. Die Regeln sind im Registrierungsschlüssel „HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices“ vordefiniert. Sie müssen aber mit manuellen Änderungen an diesem Schlüssel sehr vorsichtig sein, da diese nicht unterstützt werden.

Wie viel Sicherheit kann ausgehende Filterung bieten?
Was in der Sicherheitscommunity zu erheblichen Missverständnissen führt, ist die Frage, wie viel Sicherheitswert durch ausgehende Filterung tatsächlich geboten wird. Bisher wurden zwei Szenarios erwähnt, die Sicherheit durch ausgehende Filterung bieten, aber beide beruhen auf neuen Funktionen in Windows Vista, die vorher nicht verfügbar waren. Trotzdem wird allgemein anerkannt, dass ausgehende Filterung grundsätzlich gut ist und bei Kaufentscheidungen für eine Firewall ein entscheidender Faktor sein sollte.
Paradoxerweise standen in vielen Organisationen bei der Kaufentscheidung die Funktionen der ausgehenden Filterung im Vordergrund, aber nach der Implementierung der Firewall wurde die ausgehende Filterung dann gar nicht verwendet. Dies ist bedenklich und führt zu Geld- und Zeitverschwendung bei der Informationssicherheitsgruppe. Es scheint mehr durch den Wunsch getrieben zu sein, ein gutes Gefühl zu haben, weil man ja im Bereich Sicherheit etwas tut, als durch die tatsächliche Analyse wirklicher Bedrohungen. Viel zu oft beeinflusst der Wunsch nach einer Art von „Sicherheitsvorführung“ Entscheidungen, die stattdessen auf Fakten beruhen sollten.
Es gibt eine sehr einfache Tatsache über ausgehende Filterung, die von Befürwortern oft nicht berücksichtigt wird. Das übliche Argument von Anbietern hostbasierter Firewalls besteht darin, dass bei Beeinträchtigung eines Systems, ob durch einen Wurm oder einen interaktiven Angreifer, der Wurm durch die ausgehende Filterung daran gehindert wird, andere Systeme zu infizieren, bzw. der Angreifer daran gehindert wird, weiterhin nach außen zu kommunizieren. Das ist jedoch nicht der Fall.
Wahr ist nur, dass bei sonst völlig gleicher Konstellation die ausgehende Filterung in der Vergangenheit bestimmte Arten von Malware ausgebremst hätte. Wäre Windows XP jedoch mit der ausgehenden Filterung ausgestattet gewesen, so wären die bisher aufgetretenen Würmer mit allergrößter Wahrscheinlichkeit so geschrieben worden, dass sie die Filterung ausgeschaltet oder auf andere Weise umgangen hätten.
Unter Windows XP (und früheren Versionen von Windows) wäre dies mit jedem als Dienst ausgeführten Wurm möglich gewesen – und alle gängigen Würmer wurden als Dienst ausgeführt. Dies geschah nur darum nicht, weil es praktisch keine Umgebungen mit ausgehender Filterung gab und es deshalb unnötig war, diese zu deaktivieren. Bei einem interaktiven Angriff kann der Angreifer ausgehende Filter nach Belieben umgehen. Wenn der Angreifer die Möglichkeit hat, beliebigen Code auszuführen, ist dies ganz einfach. Falls erforderlich, kann der Angreifer den Benutzer aber auch zum Umgehen der Filter verführen.
Ausgehende Filter in hostbasierten Firewalls können je nach Angriffsszenario auf verschiedene Weise umgangen werden. Die einfachste Möglichkeit besteht darin, einen überprivilegierten Benutzer darum zu „bitten“. In zu vielen Umgebungen werden Benutzer immer noch als Administratoren geführt. Diese Benutzer haben das Recht, Sicherheitsrichtlinien nach Belieben zu umgehen. Der Angreifer muss den Benutzer lediglich vor die Wahl zwischen einem immateriellen, nicht unmittelbaren Sicherheitsvorteil und etwas für den Benutzer Erstrebenswerterem stellen.
In vielen Fällen werden Benutzer mit derartigen Dialogen so sehr überschwemmt, dass sie schnell mal auf etwas klicken, ohne die Folgen wirklich zu verstehen. Dies ist das Hauptproblem bei ausgehender Filterung. Bei der Wahl zwischen Sicherheit und hinreichend verlockenden Belohnungen lässt sich der Benutzer immer verführen, denn die meisten Dialoge, in denen Benutzer zu Sicherheitsentscheidungen aufgefordert werden, enthalten keinerlei Informationen, die sie zu solchen Entscheidung tatsächlich befähigen.
Dialoge für Sicherheitsentscheidungen anzuzeigen, die hinreichende Informationen als Grundlage für solche Entscheidungen bieten, ist viel schwieriger als es scheint. Dazu ist es nämlich erforderlich, dass das Sicherheitsprodukt, z. B. die Firewall, nicht nur Ports, Protokolle und die Anwendung versteht, die die Anforderung ausführt, sondern dass es auch versteht, was die Anforderung wirklich erreichen will und was dies für den Benutzer bedeutet. Diese Informationen lassen sich programmgesteuert nur sehr schwer erzielen. So ist zum Beispiel die Tatsache, dass Microsoft Word gerade eine ausgehende Verbindung herzustellen versucht, längst nicht so interessant wie das, was Word mit dieser Verbindung eigentlich erreichen will.
Die Anzahl nutzloser Dialoge muss verringert, nicht erhöht werden, und Firewalls mit ausgehender Filterung tragen nicht dazu bei. Um ein Gefühl für den Entwicklungsstand bei der Versorgung von Benutzern mit wertvollen Informationen zu bekommen, habe ich mir die Vertriebsdokumentation für einen führenden Anbieter hostbasierter Firewalls angeschaut. Die Hochglanzbroschüren loben die Fähigkeiten der ausgehenden Filter und die Beratungsfunktion der Firewall. Die Beratungsfunktion erkennt, was der Benutzer zu tun versucht, und stellt entsprechende Hinweise zur Verfügung. Ungefähr so sieht die Theorie aus. Der Text in der Broschüre war von einem Screenshot folgenden Inhalts begleitet: „Hinweise sind für dieses Programm noch nicht verfügbar. Wählen Sie weiter unten, oder klicken Sie auf „Weitere Information“, um Hilfe zu erhalten.“ Anscheinend können Anbieter nicht einmal im Marketingmaterial informative Dialoge bereitstellen.
Da Benutzer keine ausreichenden Informationen besitzen, um die richtigen Sicherheitsentscheidungen zu treffen, obliegt es dem Administrator, alle ausgehenden Filter zu konfigurieren, da der Endbenutzer dazu nicht in der Lage ist. Dadurch erhöht sich der Verwaltungsaufwand des Administrators erheblich.
Selbst wenn der Benutzer auf „Nein, jetzt nicht“ klickt, wenn die Firewall ihn fragt, kann die Malware die Firewall meist ungehindert umgehen. Solange der Benutzer, in dessen Namen der schädliche Code ausgeführt wird, auf irgendeinem Port ausgehende Verbindungen öffnen kann, kann der schädliche Code einfach diesen Port verwenden. So kann sich jeder Prozess an einen vorhandenen Prozess anhängen. Dies wird auf älteren Betriebssystemen zugelassen. Seit Windows Vista können die Prozesse entsprechend eingeschränkt werden. Deshalb werden Dienste, die standardmäßig eingeschränkt sind, standardmäßig mithilfe der ausgehenden Filter blockiert.
Leider glauben die meisten Leute, dass ausgehende Filterung in hostbasierten Firewalls eine beeinträchtigte Ressource daran hindert, andere Ressourcen anzugreifen. Das ist unmöglich. Es ist schlicht sinnlos, eine beeinträchtigte Ressource mit Schutzmaßnahmen zu belegen und zu erwarten, dass andere Ressourcen dadurch nicht beeinträchtigt werden. Der Schutz gehört zu der Ressource, die geschützt werden soll, nicht zu derjenigen, vor der geschützt werden soll! Einbrecher nach dem Eindringen in Ihr Haus zu bitten, nichts zu stehlen, ist höchstwahrscheinlich weniger effektiv, als sie schon vorher am Einbruch ins Haus zu hindern.

Jesper M. Johansson ist Softwarearchitekt mit dem Schwerpunkt Sicherheitssoftware und schreibt redaktionelle Beiträge für das TechNet Magazin. Er hat seine Doktorarbeit zum Thema Management Information Systems geschrieben, verfügt über mehr als 20 Jahre Erfahrung auf dem Gebiet der Sicherheit und ist Microsoft MVP im Bereich Unternehmenssicherheit. Sein aktuelles Buch heißt Windows Server 2008 Security Resource Kit.


Sicherheit
Sichern von E-Mails mithilfe digitaler Zertifikate
Matt Clapham and Blake Hutchinson
Auf einen Blick:
  • Erstellen einer überprüfbaren Identität
  • Aktualisierung des Zertifikatstatus
  • Abrufen und Austauschen von Zertifikaten
  • Problembehandlung für Ihr S/MIME-System

Seit Jahrtausenden verwenden Menschen unterschiedliche Methoden zum Verbergen von Informationen während der Weitergabe, zum Überprüfen des Absenders und zum Authentifizieren der Nachricht. Heute gibt es eine Methode für alle drei Aufgaben, die sich immer mehr verbreitet. Secure Multi-Purpose Internet Mail Extensions (S/MIME)
ist ein System für das sichere Senden von E-Mails mithilfe von Verschlüsselung und digitalen Signaturen.
Es gibt derzeit zwei Haupttypen von Technologien zum Verschlüsseln (und Verbergen): Algorithmen mit symmetrischen (geheimen) Schlüsseln, wie z. B. den Datenverschlüsselungsstandard (Data Encryption Standard, DES) oder den erweiterten Verschlüsselungsstandard (Advanced Encryption Standard, AES), sowie Algorithmen mit asymmetrischen (öffentlichen/privaten) Schlüsseln, wie z. B. RSA oder ECC (Elliptical Curve Cryptography). Die heutigen Absenderprüfungstools sind mathematische unidirektionale Funktionen, Hashes genannt, die eindeutige Signaturen erstellen. Zwei gebräuchliche Hashmethoden sind der Message Digest 5-Algorithmus (MD5) und der Secure-Hash-Algorithmus (SHA). Computer können diese zum Generieren eines eindeutigen Hash oder einer Zahl verwenden, der bzw. die dem jeweiligen Quelltext entspricht (identische Quelltexte ergeben denselben Hashwert). Diese einfachen Tools werden genutzt und kombiniert, um ein PKI-System (Public Key-Infrastruktur) zu erstellen.

Eine überprüfbare Identität
Zertifizierungsstellenressourcen
  • Verwenden einer Zertifizierungsstelle für das verschlüsselnde Dateisystem
  • Zertifizierungsstellenserver können nicht umbenannt oder aus dem Netzwerk entfernt werden
  • Entfernen einer vertrauenswürdigen Zertifizierungsstelle von Computern in der Domäne
  • Außerbetriebsetzung einer Windows-Unternehmenszertifizierungsstelle und Entfernen aller verwandten Objekte aus Windows Server 2003 und Windows 2000 Server
  • Verschieben einer Zertifizierungsstelle auf einen neuen, auf einem Domänencontroller ausgeführten Computer

Identitäten innerhalb eines PKI-Systems werden mithilfe digitaler Zertifikate verwaltet, die sich nicht wesentlich von dem Identifikationsdokument unterscheiden, das die meisten Menschen für Grenzübertritte bei sich tragen, – dem Reisepass. Der Reisepassstandard der digitalen Zertifikatwelt ist das X.509-Format, und es wird allgemein sowohl für das Signieren als auch für das Verschlüsseln in Technologien wie S/MIME, Internetprotokollsicherheit (IPSec), Secure Shell (SSH), Drahtlosnetzwerksicherheit, virtuellen privaten Netzwerken (VPN) und sogar sicheren Serverkommunikationen (z. B. SSL-Websites) verwendet.
Zertifikate bauen auf asymmetrischer Kryptografie und Hashes auf. Zum Erstellen eines Zertifikats generiert der Anforderer (die Entität, die einen Schlüssel wünscht, der von einer höheren Autorität signiert wurde) einen privaten Schlüssel. Der Schlüssel wird weggeschlossen, sodass seine Echtheit nie in Frage gestellt wird. Zusammen mit dem privaten Schlüssel wird auch ein entsprechender öffentlicher Schlüssel generiert. Wie der Name andeutet, ist der öffentliche Teil des Paars nicht geheim und wird frei verteilt, obwohl selbst das auf eine gewisse Weise seine Echtheit sicherstellt.
Dieses Schlüsselpaar ermöglicht zwei grundlegende Vorgänge. Zunächst kann jeder den öffentlichen Schlüssel verwenden, um etwas zu verschlüsseln, das nur der private Schlüssel entschlüsseln kann. Darüber hinaus kann der öffentliche Schlüssel verwendet werden, um etwas zu entschlüsseln, das mit dem privaten Schlüssel verschlüsselt wurde. Das ist wichtig zum Überprüfen einer Signatur, die nur von einem privaten Schlüssel erstellt worden sein kann.
Die Anforderung an die Zertifizierungsstelle umfasst Details wie z. B. die Identität der Person oder des Computers, für die bzw. den der Schlüssel vorgesehen ist, den Algorithmustyp und die Stärke sowie den öffentlichen Teil des Schlüsselpaars. Die Zertifizierungsstelle empfängt und überprüft die Informationen in der Anforderung und erstellt mithilfe eines Hashalgorithmus einen eindeutigen Bezeichner, der den Informationen entspricht.
Mithilfe des privaten Schlüssels verschlüsselt die Zertifizierungsstelle den Hash der Informationen und assembliert ihn in ein Standardformat (wie z. B. X.509), wobei ein Zertifikat erstellt wird, das der ursprünglichen Anforderung entspricht. Das X.509-Zertifikat enthält eine Liste der Ansprüche einschließlich der Identität des Zertifikats, eines Gültigkeitszeitraums, des öffentlichen Schlüssels sowie der Vorgänge, für die das Zertifikat verwendet werden kann. Das Zertifikat wird dann an den Anforderer zurückgegeben. Es ist ein Beweis der eigentlich besagt: „Ich, die Zertifizierungsstelle, verbürge mich für diesen öffentlichen Schlüssel und den zugehörigen privaten Teil für alle hierin beschriebenen Verwendungen.“
Bei Stammzertifizierungsstellen (jene auf der höchsten Ebene der Vertrauenskette) sind Zertifikate selbstsigniert. Die akzeptabelsten Stammzertifizierungsstellen sind im grundlegenden Betriebssystem oder in der Anwendung vorinstalliert, können aber über Pakete oder die Unternehmenskonfiguration aktualisiert oder verändert werden. Zwischen der Stammzertifizierungsstelle und einem untergeordneten Knoten (der in der Regel eine einzelne Person oder ein System beschreibt) kann es eine oder mehrere Zwischenzertifizierungsstellen geben.
Die Kette besteht aus allen Knoten und allen vorhergehenden Zertifikaten, die darin eingebettet sind, signiert von der Zertifizierungsstelle auf dieser Ebene. Ein Dritter, der versucht, das Zertifikat zu validieren, kann den lokal berechneten Hash prüfen und mit jenem vergleichen, der vom Zertifikat verschlüsselt wurde. Dazu wird der entsprechende öffentliche Schlüssel für diese spezielle Zertifizierungsstelle oder Person verwendet. Das ist es – eine vollständig validierte Vertrauenskette – vorausgesetzt natürlich, die Stammzertifizierungsstelle ist vertrauenswürdig.

Aktualisieren des Zertifikatstatus
Jede gute Zertifizierungsstelle verfügt über ein Mittel zum Verteilen einer Liste mit Zertifikaten, die nicht mehr vertrauenswürdig sind. Diese Zertifikatsperrliste (Certificate Revocation List, CRL) beschreibt, welche ausgegebenen Elemente von der Zertifizierungsstelle explizit abgewiesen wurden. Praktischerweise ist der Speicherort der CRL in der Regel eine Eigenschaft des Zertifizierungsstellenzertifikats.
Zertifizierungsstellen geben CRLs routinemäßig auf zwei Grundlagen aus: einem Zeitplan (möglicherweise alle zwei Wochen) oder einem Ereignis (eines, das anzeigt, dass einem ausgestellten Zertifikat nicht mehr vertraut werden sollte). Eine Zertifizierungsstelle signiert ihre ausgestellten CRLs bei Veröffentlichung. Wenn ein Empfangssystem die Gültigkeit einer Kette evaluiert, versucht es in der Regel, die CRL für jede ausstellende Zertifizierungsstelle in der Kette zu erlangen (über die Details, die in die Zertifikate selbst eingebettet sind, oder durch einen vordefinierte vertrauenswürdige Verteilungsmethode). Wenn eine CRL nicht verfügbar ist, darf der Client auf eine neue, erfolgreich zwischengespeicherte Kopie zurückgreifen, solange sie nicht älter ist als der festgelegte CRL-Aktualisierungszeitraum. Schlägt das jedoch fehl, zeigen die Clientsysteme in der Regel Fehler an, die besagen, dass das Zertifikat gültig erscheint, aber der Sperrstatus nicht bestimmt werden kann.
Viele Anwendungen brauchen bedeutend länger, um ein Zertifikat zu laden, wenn sie die Kette oder die CRL nicht für jeden Knoten in der Kette überprüfen können. In Abhängigkeit davon, was das Zertifikat schützen sollte, kann der Benutzer ihm vertrauen oder nicht. Ein regelmäßig aktualisierter, allgemein verfügbarer CRL-Verteilungspunkt ist für jede Zertifizierungsstelle zwingend notwendig, vor allem für die öffentlichen Stammzertifizierungsstellen.
Stammzertifizierungsstellen sind die Grundlage der Zertifikatkette, und Verkettung ist die Grundlage aller Zertifikathierarchien. Die meisten Clientsysteme oder Anwendungen werden nur annehmen, dass ein untergeordnetes Zertifikat gültig ist, wenn die Kette zurück zu einer vertrauenswürdigen Stammzertifizierungsstelle führt. Das kann eine Unternehmenszertifizierungsstelle sein, die dem Unternehmen gehört und von ihm betrieben wird, oder eine öffentliche Stammzertifizierungsstelle (wie z. B. VeriSign).
Von öffentlichen Stammzertifizierungsstellen wird höchste Zuverlässigkeit erwartet, sodass die Integrität gesichert ist. Unternehmen sollten um die gleiche Zuverlässigkeit für ihre innerbetrieblichen Vorgänge bemüht sein, da die absolute Vertrauenswürdigkeit einer Stammzertifizierungsstelle in diesem Zusammenhang ebenso wichtig ist. Für optimalen Schutz sollten Stammzertifizierungsstellen offline sein und nur zum Ausstellen von Zertifikaten und zum Aktualisieren von CRLs verwendet werden. Weitere Informationen zu bewährten Methoden des Zertifizierungsstellenbetriebs finden Sie in den Artikeln, die in der Randleiste „Zertifizierungsstellenressourcen“ aufgeführt sind.
Ein wichtiger Aspekt, der bedacht werden sollte, betrifft die Schlüsselwiederherstellung. Um Untersuchungen zu vereinfachen und sicherzustellen, dass Daten von einem Benutzer nicht unwiederbringlich weggeschlossen werden, sollte das Unternehmen Sicherungskopien von allen vom Benutzer veröffentlichten Schlüsseln anfertigen. Außerdem sollten diese Sicherungskopien in einem sicheren Repository gespeichert werden. Geht der Schlüssel eines Benutzers verloren, z. B. wenn eine Smartcard in einem Taxi zurückgelassen wird, kann trotzdem auf den Inhalt zugegriffen werden, der durch den Schlüssel geschützt ist.
Letztendlich gibt es in jedem guten kryptografischen System das Konzept der Lebenszyklusverwaltung. Je schneller Computer werden, desto schwächer werden Algorithmen. Jedes gute kryptografische System benötigt die Fähigkeit, sich zu erneuern und mit der Zeit zu neuen Algorithmen und Schlüsselgrößen überzugehen. Zertifizierungsstellen sollten angemessen aktualisiert werden, wenn kryptografische Schwächen identifiziert werden und bestimmte Funktionen eingeführt werden oder auslaufen.

Implementieren von S/MIME
Es gibt mehrere Phasen für das Starten, Verfassen, Senden und Empfangen signierter oder verschlüsselter E-Mails mithilfe von S/MIME. Die Details, Probleme und potenziellen Lösungen werden im Folgenden anhand eines typischen S/MIME-Szenarios erläutert: zwei Benutzer, die einander mithilfe von Microsoft® Office Outlook® 2007 signierte und/oder verschlüsselte E-Mails senden, und zwar von zwei verschiedenen Active Directory®-Strukturen und unterschiedlichen Zertifizierungsstellenketten (also von betrieblich getrennten Entitäten, entweder im selben Unternehmen oder nicht).
Nehmen wir an, dass die notwendige Infrastruktur bereits eingerichtet ist, um die Vorgänge zu ermöglichen, die beschrieben werden sollen. In unserem Fall verwenden wir einen in Active Directory integrierten Unternehmenszertifikatserver.

Abrufen von Zertifikaten
Die erste Aufgabe besteht darin, die geeigneten Zertifikate abzurufen. Öffnen Sie dafür die Zertifikatverwaltungs-MMC (certmgr.msc), klicken Sie mit der rechten Maustaste auf den persönlichen Ordner, und wählen Sie „Alle Aufgaben“ aus der Popupliste und anschließend „Neues Zertifikat anfordern“ aus der Liste aus.
Dadurch wird der Assistent für die Zertifikatregistrierung gestartet (siehe Abbildung 1). Standardmäßig werden mehrere unternehmensbezogene Optionen angezeigt, aber das Benutzerzertifikat ist das wichtige. Es wird verwendet, um später die Signatur- und Verschlüsselungsprozesse zu aktivieren. Das Zertifikat muss für Folgendes verwendet werden können:
Abbildung 1 Anfordern eines Zertifikats
Abbildung 1 Anfordern eines Zertifikats (Zum Vergrößern auf das Bild klicken)
  • Digitale Signaturen (Erstellen einer Nachricht mit einem Echtheitssiegel des Erstellers)
  • Schlüsselverschlüsselung (Schützen eines Schlüssels mit einem anderen für Technologien wie das verschlüsselnde Dateisystem)
  • Sichere E-Mail (verschlüsseltes Messaging, das nur vom gewünschten Empfänger gelesen werden kann, der in Besitz des entsprechenden privaten Schlüssels ist)
Zum Senden einer mit S/MIME signierten E-Mail ist die Schlüsselverschlüsselungseigenschaft nicht erforderlich. Um jedoch eine verschlüsselte E-Mail senden oder empfangen zu können, wird diese Eigenschaft benötigt, nicht aber die Signatureigenschaft. Standardmäßig ermöglichen die Vorlagen in den Windows®-Zertifikatdiensten diese drei Eigenschaften. Wenn der Benutzer keine neuen Zertifikate anfordern darf, werden beim Start des Assistenten keine angezeigt. Wenn keine Unternehmenszertifizierungsstelle verfügbar ist, wird dem Benutzer ein „Registrierungsfehler“ angezeigt, der besagt, dass die Domäne oder die Zertifizierungsstelle nicht kontaktiert werden konnte. Für diese exemplarische Vorgehensweise nehmen wir an, dass ein einziges Zertifikat sowohl Signatur als auch Verschlüsselung ermöglicht.

Austauschen von Zertifikaten
Die einfachste Möglichkeit für zwei Benutzer, mit dem Senden verschlüsselter E-Mails zu beginnen, besteht einfach im Senden signierter Nachrichten. Nach dem Verfassen einer Nachricht klickt der Benutzer auf die Schaltfläche „Signieren“. (Möglicherweise ist die Schaltfläche in Outlook standardmäßig ausgeblendet, bis sie mindestens einmal verwendet wurde. Klicken Sie dazu im Fenster einer neuen Nachricht auf „Optionen“ und anschließend auf die Schaltfläche „Sicherheitseinstellungen...“, und aktivieren Sie im Dialogfeld „Sicherheitseigenschaften“ das Kontrollkästchen „Diese Nachricht digital signieren“.) Die Schaltfläche „Signieren“ (ein kleiner gelber Umschlag mit einem roten Band) fügt der Nachricht eine digitale Signatur hinzu, um die Echtheit der Quelle zu gewährleisten.
Nach dem Klicken auf die Schaltfläche „Senden“ wird der Benutzer u. U. aufgefordert, zusätzliche Beweise für den Schlüsselbesitz bereitzustellen, z. B. durch Einlegen einer Smartcard oder Eingeben einer PIN. Dies ist abhängig von den jeweiligen Methoden des Schlüsselschutzes, die im Unternehmen eingerichtet sind.
Der Benutzer, der die mit S/MIME signierte Nachricht empfängt, muss den Namen des Absenders anzeigen und mit der rechten Maustaste auf diesen klicken (hinter „Von:“) und aus dem Kontextmenü „Zu Outlook-Kontakten hinzufügen“ auswählen. Dadurch wird der neue Kontakteintrag entweder hinzugefügt, oder ein vorhandener Kontakt wird aktualisiert. Das Zertifikat ist dann diesem bestimmten Kontakteintrag zugeordnet. Beachten Sie, dass innerhalb einer normalen Active Directory-Umgebung (zwei Benutzer in der gleichen Stammstruktur oder demselben Unternehmen) die Verteilung öffentlicher Benutzerzertifikate automatisch über Attribute im Active Directory-Objekt des Benutzers erfolgt.
Eine andere Möglichkeit, Zertifikate auszutauschen, besteht darin, dass jeder Benutzer seine S/MIME-Zertifikate als Anlage sendet. Dafür müssen beide Teilnehmer Ihre Zertifikate in eine CER-Datei exportieren. Die Benutzer müssen das Zertifikat anzeigen und den Exportvorgang ausführen, der nachfolgend erläutert wird, wobei sie darauf achten müssen, dass der private Schlüssel nicht exportiert wird (siehe Abbildung 2).
Abbildung 2 Exportieren Sie beim Austausch von Zertifikaten nicht den privaten Schlüssel
Abbildung 2 Exportieren Sie beim Austausch von Zertifikaten nicht den privaten Schlüssel (Zum Vergrößern auf das Bild klicken)
Jeder Empfänger erstellt dann manuell einen Kontakteintrag in Outlook und fügt das Zertifikat dem Eintrag des Senders hinzu. Nachdem die beiden Benutzer Zertifikate ausgetauscht haben, können sie einander verschlüsselte E-Mails senden.

Problembehandlung
Manchmal hat der Empfänger Schwierigkeiten beim Öffnen der verschlüsselten Nachricht. Die drei wahrscheinlichsten Ursachen für Probleme, die wir in diesem Bereich beobachtet haben, sind Stammzertifizierungsstellen, die nicht vertrauenswürdig sind, Zwischenzertifizierungsstellen, die nicht überprüft werden können, sowie CRLs, die nicht verfügbar sind.
Eine nicht vertrauenswürdige Stammzertifizierungsstelle führt in Outlook in der Regel zu einer Fehlermeldung in Verbindung mit der Signatur: „Probleme mit der Signatur. Klicken Sie auf die Signaturschaltfläche, um Details anzuzeigen.“ Öffnen Sie zum Lösen des Problems das Zertifikat in Outlook, und klicken Sie im Popupdialog auf die Schaltfläche „Zertifizierungsstelle anzeigen“. Sehen Sie sich die Nachricht auf der Registerkarte „Allgemein“ des Dialogfelds „Zertifikateigenschaften“ an. Wird angezeigt, dass das Stammzertifikat der Zertifizierungsstelle nicht vertrauenswürdig ist und installiert werden muss, wechseln Sie zur Registerkarte „Details“. Klicken Sie auf die Schaltfläche „In Datei kopieren...“, und folgen Sie dem Assistenten, wobei Sie alle Standardeinstellungen annehmen und bei entsprechender Aufforderung einen Dateinamen und einen Ordner eingeben.
Öffnen Sie nun eine neue MMC (Microsoft Management Console) als Computeradministrator. Wählen Sie „Datei“|„Snap-In hinzufügen/entfernen“ (Strg+M), wählen Sie „Zertifikate“, und fügen Sie es für das Computerkonto hinzu, indem Sie bei Aufforderung „Lokaler Computer“ wählen. Erweitern Sie als Nächstes in der linken Struktur den Knoten „Zertifikate“, und verfahren Sie gleichermaßen mit den vertrauenswürdigen Stammzertifizierungsstellen. Klicken Sie mit der rechten Maustaste, und wählen Sie „Alle Aufgaben“|„Importieren“ aus dem Popupmenü aus. Importieren Sie die zuvor erwähnte exportierte Zertifikatdatei zu den vertrauenswürdigen Stammzertifizierungsstellen, und klicken Sie auf „Fertig stellen“. Anschließend muss der betroffene Benutzer Outlook neu starten.
Diese Vorgehensweise sollte nur verwendet werden, um eine Stammzertifizierungsstelle hinzuzufügen, von der Sie wissen, dass sie vertrauenswürdig ist. Nicht alle Stammzertifizierungsstellen sind gleich. Achten Sie darauf, wer im Besitz der Stammzertifizierungsstelle ist und diese betreibt, bevor Sie diese Methode zum Hinzufügen einer Stammzertifizierungsstelle zum Speicher des gesamten Systems verwenden. Wenn Ihr Unternehmen die Liste vertrauenswürdiger Stammzertifizierungsstellen über die Gruppenrichtlinie kontrolliert, wird die Konfiguration auf Clientsysteme übertragen. In diesem Fall funktionieren die Anweisungen möglicherweise nicht. Sollte dies der Fall sein, müssen Sie eventuell nach Alternativen suchen, wie z. B. sicheren Websites oder Servern zum Austauschen von Daten, da E-Mails hier nicht problemlos verwendbar und ausreichend geschützt sind.
Das zweite bereits erwähnte Problem, dass Zwischenzertifizierungsstellen nicht überprüft werden können, tritt in der Regel in zwei Situationen auf: Ein Client, der das Zertifikat überprüfen möchte, kann den im Zertifikat festgelegten Speicherort für AIA (Authority Information Access, Zugriff auf Stelleninformationen) nicht abrufen, oder der Client verfügt über eine Version des Zertifikats der Zwischenzertifizierungsstelle, die nicht mit dem übereinstimmt, was die Zertifizierungsstelle ausstellt (der Client ist oft ein oder zwei Versionen hinterher). Diese Bedingungen erscheinen in der Outlook-Benutzeroberfläche sehr ähnlich. Wir haben dies nur in einer ganz bestimmten Situation gesehen, als eine Zertifizierungsstelle in der Mitte der Kette abgelaufen ist und erneut ausgestellt wurde, bevor andere, von ihr ausgestellte untergeordnete Zertifikate abgelaufen waren.
Im Grunde tritt dieses Problem auf, wenn die Kette Lücken aufweist. Einige übergeordnete Zertifikate sind möglicherweise nicht detailliert genug oder nicht richtig in die untergeordneten Knoten eingebettet, wodurch die Situation weiter erschwert wird.
Um dieses Problem zu lösen, muss der Sender eine neue Nachricht öffnen und auf „Optionen“ und dann auf die Schaltfläche „Sicherheitseinstellungen“ und auf die Schaltfläche „Einstellungen ändern“ klicken. Klicken Sie anschließend für das Signaturzertifikat auf die Schaltfläche „Auswählen“ und dann im Popupdialog „Zertifikat auswählen“ auf die Schaltfläche „Zertifikat anzeigen“. Wechseln Sie zur Registerkarte „Zertifizierungspfad“, wählen Sie den Aussteller des untergeordneten Knotens (in der Kette eine Stufe höher), und klicken Sie auf die Schaltfläche „Zertifikat anzeigen“. Klicken Sie auf die Registerkarte „Details“ und dann auf die Schaltfläche „In Datei kopieren...“. Beenden Sie anschließend den Exportassistenten, indem Sie „PKCS #7 (.P7B)“ auswählen. Vergewissern Sie sich, dass die Option „Alle Zertifikate im Zertifizierungspfad einbeziehen“ aktiviert ist (siehe Abbildung 3). Senden Sie nun dem gewünschten Empfänger die exportierte Kettendatei.
Abbildung 3 Schließen der Lücken in einer Zertifikatkette
Abbildung 3 Schließen der Lücken in einer Zertifikatkette (Zum Vergrößern auf das Bild klicken)
Nach dem Abrufen der exportierten Zertifikatkette muss der Empfänger die Kette ähnlich wie beim zuvor beschriebenen Importieren einer Stammzertifizierungsstelle öffnen und importieren. Der einzige Unterschied besteht darin, dass die Speicherung in den Zwischenzertifizierungsstellen erfolgen sollte. Wenn die Nachricht geöffnet und das Zertifikat in Outlook als gültig angezeigt wird, funktioniert alles einwandfrei.
Auch für das dritte Problem, dass keine CRLs verfügbar sind, ist die Problembehebung vergleichsweise einfach. Zunächst wird die Antwort von Outlook ähnlich wie beim vorangegangenen Problem aussehen. Allerdings wird der Fehler auch dann angezeigt, wenn die Stamm- oder Zwischenzertifizierungsstellen vertrauenswürdig sind. Öffnen Sie für jede Stufe der Zertifikatkette über der untergeordneten Stelle die Zertifikateigenschaften, dann die Registerkarte „Details“, und sehen Sie sich das Feld namens „CRL-Verteilungspunkte“ an.
Prüfen Sie für jeden aufgeführten CRL-Verteilungspunkt (besonders jene, auf die vom Internet aus zugegriffen werden kann), ob die URL der CRL-Datei geöffnet werden kann. Bewegen Sie sich in der Kette nach erfolgreicher Überprüfung um eine Stufe nach oben. Ist eine CRL nicht verfügbar, so ist dies wahrscheinlich die Ursache des Problems. Um das Problem zu lösen, sollten Sie sicherstellen, dass Ihre lokale Netzwerkrichtlinie Ihren Zugriff nicht blockiert. Versuchen Sie andernfalls, das Unternehmen zu kontaktieren, das in Besitz der Zertifizierungsstelle ist, oder warten Sie, bis der CRL-Verteilungspunkt der Zertifizierungsstelle in den Betriebsstatus zurückgekehrt ist.

Verteilen von Zertifikaten
Die Verteilung ist einfach. Im Grunde wird die signierte Nachricht an einen E-Mail-Server übertragen, der sie dann über eine erprobte und bewährte Methode, SMTP, von einem Speicherort an einen anderen überträgt. Das einzige Problem, das wir mit signierten oder verschlüsselten E-Mails bei der Übertragung feststellen konnten, besteht darin, dass einige E-Mail-Systeme signierte oder verschlüsselte Nachrichten zurückweisen oder beschädigen. Die Problembehebung besteht darin, mit dem IT-Manager des Systems zusammenzuarbeiten, sodass diese Nachrichtentypen zugelassen werden. Wahrscheinlich werden Sie jedoch mit der Tatsache leben müssen, dass einige Nachrichtentypen blockiert werden. Der Empfänger wird sicher gute Gründe haben, verschlüsselte Nachrichten in einer bestimmten Betriebsumgebung nicht zuzulassen.

Verschlüsseln von Antworten
Zum Erstellen einer verschlüsselten Antwort (vorausgesetzt der Bootstrappingprozess wurde bereits abgeschlossen) muss der Absender lediglich eine Nachricht verfassen und dann im Nachrichtenerstellungsfenster auf die Schaltfläche „Verschlüsseln“ klicken (den kleinen gelben Umschlag mit dem blauen Schloss). Sollte die Schaltfläche „Verschlüsseln“ nicht zur Verfügung stehen, führen Sie die Schritte für das Senden einer signierten Nachricht bis auf den letzten Schritt aus, und aktivieren Sie stattdessen das Kontrollkästchen „Nachrichteninhalte und Anlagen verschlüsseln“.
Die S/MIME-Signatur ist für das Senden einer verschlüsselten Nachricht an einen Empfänger nicht erforderlich, aber beides passt gut zusammen, da der Leser durch das Signieren den Sender prüfen kann (die Verschlüsselungsfunktion ermöglicht keine Aussagen über den Sender). Beim Verschlüsselungsprozess wird versucht, die Nachricht mit den bekannten öffentlichen Schlüsseln aller Empfänger zu verschlüsseln. Wenn das System für einige gewünschte Empfänger keine Zertifikate finden kann, werden sie in einem Popupdialog gekennzeichnet. Dort besteht die Möglichkeit, die Nachricht unverschlüsselt zu senden (siehe Abbildung 4).
Abbildung 4 Sie können sich entscheiden, eine unverschlüsselte Nachricht zu senden, wenn ein Problem mit einem Zertifikat auftritt.
Abbildung 4 Sie können sich entscheiden, eine unverschlüsselte Nachricht zu senden, wenn ein Problem mit einem Zertifikat auftritt. (Zum Vergrößern auf das Bild klicken)
Standardmäßig sollte das Signieren und Verschlüsseln mit anderen vergleichbar konfigurierten Clientsystemen funktionieren, aber gelegentlich treten beim Senden von Nachrichten, die mit unterschiedlichen Versionen verschlüsselt oder signiert wurden, Probleme auf, wenn der Hash- oder Verschlüsselungsalgorithmus nicht für untere Stufen unterstützt wird. Ein solches Problem trat auf, als wir eine signierte E-Mail (mithilfe von SHA-512 als Hashalgorithmus) an einen Benutzer sendeten, der mit Windows XP SP2 arbeitete. Weil das Empfangssystem den Hash nicht unterstützte, konnte der Benutzer die Signatur nicht validieren und die Nachricht nicht lesen. Es ist aber unwahrscheinlich, dass an diesem Punkt viele Probleme auftreten, wenn die Standardeinstellungen in Outlook nicht geändert wurden.
Nach dem Empfang der Nachricht sollte der gewünschte Empfänger sie öffnen können, vorausgesetzt, der private Schlüssel, der mit dem öffentlichen Zertifikat verbunden ist, steht zur Verfügung. Auch hier muss der Benutzer möglicherweise einen weiteren Beweis für den Besitz des privaten Schlüssels liefern, je nachdem, wie er bereitgestellt wurde. Andere Benutzer, die einen ähnlichen Bootstrappingprozess durchgeführt haben, dürfen an ähnlich signierten und verschlüsselten Kommunikationen mit dem Absender teilnehmen. Wenn ein Benutzer seinen privaten Schlüssel irgendwann ändert (möglicherweise, weil sein Computer verloren ging), muss er Zertifikate erneut anfordern und eine signierte Nachricht oder Zertifikatdatei an andere Benutzer senden, mit denen er verschlüsselte E-Mails austauschen möchte.

Schlussbemerkung
Die Einrichtung von verschlüsseltem und signiertem S/MIME zwischen zwei Benutzern in zwei unterschiedlichen Verzeichnissen oder Organisationen ist in der Regel nicht komplizierter als hier dargelegt. Das Signieren ist sehr praktisch, wenn es richtig eingesetzt wird, da es die Echtheit einer Nachricht belegt. Für vertrauliche Informationen bieten verschlüsselte Nachrichten eine zusätzliche Stufe der Geheimhaltung bei der Übertragung von Daten. Gemeinsam ermöglichen beide die Echtheitsprüfung der Quelle und die Geheimhaltung von Daten. Mit der hier beschriebenen Vorgehensweise wird es für die meisten Benutzer leicht sein, die Vorteile dieser Möglichkeiten zu nutzen.

Matt Clapham, CISSP, ist Security Engineer bei Microsoft IT. Er führt tagsüber Sicherheitsprüfungen für Branchenanwendungen durch und beschäftigt sich in seiner Freizeit mit Technologie, Spielen, Computermusik und Sicherheit. Er spricht gelegentlich vor der Puget Sound-IT-Sicherheitscommunity. Sie erreichen Ihn unter matt.clapham@microsoft.com
Blake Hutchinson ist Support Analyst in der Business Online Services Group (BOSG) bei Microsoft. Zu seinen Aufgaben zählen betrieblicher Support und Projektprüfung für firmenintern erstellte Branchentools für die Unternehmenskunden von BOSB. Zu seinen Hobbys zählen Fotografie, Skifahren und Computerspiele. Sie erreichen ihn unter blakeh@microsoft.com.


Mitteilung der Redaktion Die große Debatte
Joshua Hoffman

Ich finde große Debatten toll. Ich rede nicht von langweiligen Streitereien, wo unterschiedliche Meinungen und starke Persönlichkeiten zu sinnlosen Konflikten führen. Das ist reine Zeitverschwendung. Aber eine wirklich große Debatte, bei der intelligente Personen mit entgegengesetzten Standpunkten aufeinandertreffen und ihre Argumente leidenschaftlich vortragen – das ist etwas Großartiges. Denken Sie an Aufklärung. Denken Sie an Sokrates.
Diesen Monat präsentieren wir Ihnen eine der wahrhaft großen Debatten in der IT-Branche: Sicherheit durch Verschleierung. Ich würde das Konzept hier gern erklären, aber ich habe den Verdacht, dass Sie sich, bis Sie die drei Wörter gelesen haben, schon längst Ihre Meinung zu diesem Thema gebildet haben. Ich gehe auch jede Wette ein, dass die meisten von Ihnen einem von zwei Lagern angehören: Entweder „Sicherheit durch Verschleierung ist vollständig nutzlos“ oder „Wenn es um die Sicherheit geht, hilft jedes kleine Bisschen“.
Diesen Monat bringen wir die berühmten Sicherheitsfachleute Jesper Johansson und Roger Grimes zusammen, die beide Seiten dieser Debatte beleuchten. Jede Seite erhält außerdem besondere Unterstützung durch die Koryphäen Aaron Margosis und Steve Riley. Ich bin sicher stolz auf jede einzelne Seite, die wir veröffentlichen, aber ich muss zugeben, dass dieser Artikel hier seit langem einmal wieder den Sprung in die Liste meiner persönlichen Lieblingsartikel geschafft hat. Ich hoffe, dass Sie diesen Artikel unvoreingenommen lesen können, egal zu welcher Seite Sie in dieser großen Debatte neigen. Ich bin mir sicher, dass Sie es genießen werden.
Da die vorliegende Ausgabe unsere jährliche Sicherheitsausgabe ist, gibt es natürlich noch viel mehr. Wir betrachten noch einmal einige der Themen, die wir in der Ausgabe des letzten Jahrs behandelt haben. Einer der beliebtesten Artikel im letzten Jahr befasste sich mit einer Reihe von PowerToys für die Skripterhöhung von Michael Murgolo, die die Ausführung von VBScript- oder Windows PowerShell-Skripts mit erhöhten Berechtigungen in Verbindung mit dem Windows Vista-Feature zur Benutzerkontensteuerung unterstützen. Michael Murgolo hat sehr viele positive Rückmeldungen zu diesem Artikel erhalten, weshalb er in diesem Jahr mit einer ganzen Reihe neuer Dienstprogramme zurückkehrt, die seinen ursprünglichen Code noch erweitern. Ich empfehle Ihnen dringend, diese sehr leistungsfähigen Tools einmal auszuprobieren.
Auch Byron Hynes war letztes Jahr bei uns, als er eine Einführung in die BitLocker-Laufwerkverschlüsselung in Windows Vista gab. Byron Hynes nimmt seine Rolle wieder auf und wirft einen Blick auf die Veränderungen bei BitLocker seit der Veröffentlichung von Windows Vista SP1 und Windows Server 2008. Außerdem bieten wir Artikel über Softwareeinschränkungsrichtlinien, über die Verwaltung der Windows Vista-Firewall und über die Fehlerbehebung bei S/MIME. Wir veröffentlichen die zweite Ausgabe unserer neuen Rubrik „Einblicke in SharePoint“, präsentieren Geschäftsideen für die Förderung von nachhaltigem Computing und vieles mehr. Viel Spaß! – Joshua Hoffman

Unser Dank gilt folgenden technischen Experten von Microsoft: Troy Funk, Aaron Margosis, Michael Murgolo, Steve Peschka, Steve Riley, Mark Russinovich, Jon Schwartz und Jim Truher.


Briefe Leser sagen ihre Meinung

Windows-Sicherung
Ich habe Ihren Artikel über Windows Server® 2008 (TechNet Magazin, März 2008, technet.microsoft.com/magazine/cc268370) mit großem Interesse gelesen. Ich bin zur Einführungsveranstaltung gegangen und habe mir eine Kopie für mein Heimnetzwerk beschafft. Die Installation lief glatt. Aber bei der Sicherung war ich mit meiner Weisheit am Ende.
NT Backup gibt es nicht mehr, und die neue Windows Server-Sicherung unterstützt im Unterschied zum Betriebssystem keine Bandlaufwerke. (Ich sichere meine persönlichen Daten, einschließlich Active Directory® und Exchange Server 2007, auf einem Bandlaufwerk.)
Ich habe versucht, Microsoft® Data Protection Manager (DPM) gemäß den Anweisungen im Web herunterzuladen, auch wenn DPM wohl ein bisschen zu viel für meine Installation sein dürfte. Aber DPM lässt sich nicht unter Windows Server 2008 installieren, und die Anweisungen für die manuelle Installation haben auch nichts gebracht. Was bringen kleinen Installationen für die Sicherung?
– Ravi S.

DPM ist tatsächlich die Lösung für Bandsicherungen, weil die neue Lösung in Windows Server 2008 für den festplattenbasierten Speicher optimiert ist. DPM wird Windows Server 2008 offiziell in einigen Monaten unterstützen.
– Karandeep Anand, Senior Program Manager Lead, Microsoft

Umfrageworkflows
Im Artikel „Erstellen einer leistungsfähigen Umfrageinfrastruktur“ (technet.microsoft.com/magazine/cc194407) vom Februar 2008 steht die folgende Aussage im Abschnitt „Eigenständiges Verwenden von WSS“: „Sie haben auch die Möglichkeit, der Umfrage einen Workflow zuzuweisen.“
Soweit ich weiß, unterstützen Windows® SharePoint® Services 3.0 (WSS) und Microsoft Office SharePoint Server 2007 (MOSS) keine Workflows, die mit Umfrageantworten zusammenhängen. Ich habe versucht, einen Workflow einer Umfrageantwort zuzuordnen. SharePoint Designer hat die Zuordnung zugelassen, aber der Workflow weist immer auf einen Fehler beim Start hin. In einem Knowledge Base-Artikel (support.microsoft.com/kb/926370) wird deutlich erklärt, dass Workflows, die Umfrageantworten zugeordnet sind, nicht unterstützt werden.
Ich weiß, dass es möglich ist, einen Ereignisempfänger mit einer Umfrage zu verknüpfen und dann einen anderen Prozess zu initiieren, aber das ist kein Workflow gemäß der Definition in SharePoint. War diese Aussage nur ein Versehen, oder verstehe ich hier etwas nicht richtig?
– Matt B.

Im genannten Abschnitt wird erläutert, dass WSS einen Assistenten für die schrittweise Erstellung von Umfragen enthält. Auch die verschiedenen Optionen (Verzweigungslogik, offene/abgeschlossene Fragen usw.) werden vorgestellt.
Eine der Optionen, die der Assistent wirklich bietet, ist das Zuweisen eines Workflows. Darum ist es nicht ganz falsch zu schreiben: „Sie haben auch die Möglichkeit, der Umfrage einen Workflow zuzuweisen.“ Diese Zuweisung ist möglich. Aber wie Sie ganz richtig darlegen, funktionieren Workflows in Umfragen einfach nicht, obwohl diese Option aus unerfindlichen Gründen zur Verfügung steht. Ich möchte das näher erläutern.
Wenn Sie einen Workflow einer Umfrage zugeordnet haben und dann versuchen, die Umfrage zu starten, erhalten Sie einen Startfehler. Die Protokolle für diese Aktivitäten zeigen Folgendes:
RunWorkflow: System.ArgumentException: Invalid field name.
{<<< GUID>>>} at ...
Diese GUID steht für die Workflowinstanz. Das ist anscheinend eine großartige Möglichkeit, dafür zu sorgen, dass der richtige Workflow ausgelöst wird, mit dem kleinen Makel, dass der Umfragelistentyp das Workflowattribut nicht unterstützt. Das Attribut ist schlichtweg nicht codiert. Wenn also der Workflow versucht, mit der MakeActivation-Methode eine Aktivierung durchzuführen, und dann etwa wie folgt vorgeht:
internal static void MakeActivation(SPWorkflow workflow, SPWorkflowEvent e)
{e.EventData = new object[ ] { workflow.InstanceId, new SPWorkflowActivation
Properties(workflow, e.RunAsUserId, associationData, initiationData) };
...
}
wird SPWorkflowActivationProperties aufgerufen, was dann in etwa so aussieht:
internal SPWorkflowActivationProperties(SPWorkflow workflow,
int runAsUserId, string associationData, string initiationData)
{
...
this.m_itemGuid = new Guid((string)
this.Item[SPBuiltInFieldId.GUID]);
...
}
Wenn also die GUID-Zeichenfolge als Attribut in der Umfrage erwartet wird (das ja integriert sein soll) und die Umfrage kein Attribut für die Workflow-GUID enthält, funktioniert es nicht.
Es gibt eine Problemumgehung, und deshalb sind Sie im Prinzip durchaus auf der richtigen Spur. Bei der Problemumgehung erstellen Sie eine benutzerdefinierte Liste, die einen Workflow auslöst und einen Ereignisempfänger per ItemEventReceiver mit der Umfrage verknüpft. Dieser Ereignisempfänger erstellt wiederum ein Element in der benutzerdefinierten Liste, wodurch dann ein Workflow ausgelöst wird. Aber es stimmt schon, das ist nicht ganz dasselbe. Kurz gesagt: Ja, Sie haben gut aufgepasst. Es funktioniert nicht.
– Pav Cherny, Autor, Einblicke in SharePoint, TechNet Magazin


Toolbox Neue Produkte für IT-Experten
Greg Steen

Senden von Ankündigungen über das Netzwerk
NetSupport Notify
www.netsupportnotify.com
Die computergestützte Arbeitsumgebung ist im Büro schon längst zum Alltag geworden. Die meisten Benutzer sitzen tagsüber vor ihrem Bildschirm und sind mit einem Netzwerk verbunden, bei dessen Verwaltung Sie mithelfen. Das Netzwerk Ihres Unternehmens kann nicht nur ein Transportmittel für freigegebene Ressourcen, Anwendungen und das Internet bieten, sondern auch als Teil der Strategie Ihrer Organisation für die Übermittlung wichtiger Nachrichten an Benutzer fungieren. Ein Tool, mit dem Sie Nachrichten über das LAN und das WAN (Wide Area Network) an die Benutzer senden können, ist NetSupport Notify von NetSupport Limited.
Dieser einfache Anwendungsserver bietet Ihnen schnelle und zuverlässige Unterstützung für die Übertragung von Nachrichten. So könnten Sie beispielsweise problemlos den Benutzern rechtzeitig einen unerwarteten Dienstausfall einer freigegebenen Ressource mitteilen, die Benutzer darüber informieren, dass der soeben ausgelöste Sicherheitsalarm auf einem Versehen beruht, oder die Mitarbeiter über einen drohenden Notfall in Kenntnis setzen.
Einige einfache Nachrichtenübermittlungstools sind auf das LAN begrenzt, auf dem sie installiert sind. NetSupport Notify ist dagegen agentbasiert, und mit seiner Komponente eines Benachrichtigungsgateways kann es problemlos die Netzwerktopologie durchqueren und sowohl Windows®- als auch Mac-Clients erreichen, unabhängig davon, ob sie direkt, über eine Drahtlosverbindung oder über ein virtuelles privates Netzwerk verbunden sind.
Der Benachrichtigungsdienst wird als Windows-Dienst ausgeführt, und Sie stellen eine Verbindung zum Dienst über die administrative Benachrichtigungskonsole her, die auf demselben oder auf einem anderen Computer installiert werden kann. Benachrichtigungen vom Dienst sind in drei Schweregrade unterteilt: Meldungen, Warnungen und kritische Benachrichtigungen. Sobald eine Nachricht vom Client eingeht, wird ein Ereignisprotokolleintrag erstellt, und der Server wird benachrichtigt, dass die Nachricht empfangen wurde. Weitere Nachrichtenoptionen sind das Ausgeben eines Pieptons zusätzlich zum Anzeigen des Fensters, das Einblenden der Benachrichtigung im Vordergrund sowie das Festlegen eines automatischen Timeouts, nach dem die Nachricht sich selbst schließt.
Sie können auch auf ganz bestimmte Benachrichtigungsgruppen abzielen. Die Benachrichtigungskonsole kann eine Verbindung zu mehreren Benachrichtigungsservern herstellen. Eine Konsole kann somit den Mittelpunkt der Nachrichtenübertragung bilden.
Neben dem Server und der Konsole enthält NetSupport Notify auch ein Bereitstellungstool, mit dem Sie von einem Remotestandort aus den Agent für Ihre Endbenutzer bereitstellen können, was Ihnen das Aufsuchen des Desktops erspart. Sie können die Zielcomputer über den IP-Adressbereich oder über Windows-Netzwerkdomänen und Arbeitsgruppenermittlung angeben.
Die Bereitstellungskonsole bietet Ihnen außerdem eine schnelle Übersicht über Ihr Netzwerk mit der installierten Version des Agent zusammen mit weiteren wichtigen Angaben, z. B. DNS-Name, MAC-Adresse, IP-Adresse, Plattform, möglicher Zugriff von der Konsole auf den Remotecomputer. Wenn Sie Active Directory® verwenden, können Sie die Konfiguration und die Bereitstellung über eine Gruppenrichtlinie verwalten.
Als Schutz vor nicht autorisierten Übertragungen („He, in meinem Büro steigt um 16:00 Uhr eine Party!“) setzen die Agents und die Konsolen einen Sicherheitscode ein, der mit einer Zeichenfolge der Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) vergleichbar ist. Außerdem können Sie die Möglichkeit zum Senden von Warnungen über eine Active Directory-Richtlinie steuern.
Preis: Ab 180 $ für eine 75-Benutzer-Lizenz.
Senden von Ankündigungen an Ihre Mitarbeiter mit NetSupport Notify
Senden von Ankündigungen an Ihre Mitarbeiter mit NetSupport Notify (Zum Vergrößern auf das Bild klicken)

Überwachen Ihres Netzwerks
NetOptics: Teeny Tap
www.netoptics.com
In Kombination mit einer guten Überwachungsanwendung können passive Netzwerktaps äußerst hilfreich für die Fehlerbehebung bei unzuverlässigen Netzwerken, für die Reparatur fehlerhafter Anwendungen und für das Verringern potenzieller Bedrohungen Ihrer Infrastruktur sein. Teeny Tap von NetOptics ist ein fantastischer, tragbarer Tap für 10/100-Netzwerke.
Dieses „winzige“, etwa 7,9 cm × 3,8 cm kleine Gerät ermöglicht die Vollduplexüberwachung des Datenverkehrs ab Schicht 1 aufwärts, sodass Sie problemlos stichprobenweise oder kontinuierlich den Datenverkehr in Ihrem 10/100-Netzwerk überwachen können. Das Gerät erreicht die Vollduplexüberwachung mit den beiden RJ45-Ports für die Überwachung, die Ihnen einen eingehenden Einblick in den fließenden Datenverkehr auf beiden Seiten der beiden Netzwerkports bieten, wenn beide mit der Netzwerküberwachung, der Protokollanalyse, mit IDS/IPS oder mit einer anderen Überwachungseinrichtung verbunden sind.
Teeny Tap erfordert keine IP-Adresse. Sie isolieren sich selbst vom Netzwerk und können damit unsichtbar für alle bleiben, die ihre Manipulationen am Netzwerk unterbrechen, sobald sie Ihre Anwesenheit bemerken. In der Zwischenzeit stellt das Zero-Delay-Feature sicher, dass ein Stromausfall beim Tap den Fluss des Datenverkehrs durch den Tap nicht beeinträchtigt. Es soll keine Verzögerung geben, und es sollen keine Pakete verloren gehen.
Der Tap kann per USB oder mit der zugehörigen Stromversorgung betrieben werden. Aus Redundanzgründen können Sie auch beide Optionen verwenden, was eine beachtenswerte Funktion für ein so kleines Gerät ist. Teeny Tap ist auch mit Power-over-Ethernet-basierten Diensten kompatibel, z. B. Netzwerkkameras und IP-Telefonen. Folglich könnten Sie auch den Datenverkehr dort überwachen, um zu gewährleisten, dass Ihre gesamte Kommunikation sicher ist.
Das Teeny Tap-Kit enthält den Tap, eine universelle Stromversorgung, zwei RJ45-Kreuzkabel und zwei RJ45-Durchgangskabel sowie eine Tragetasche. Wenn Sie etwas mehr Leistung in Ihrer Umgebung benötigen, werfen Sie einen Blick auf die anderen Netzwerktaps von NetOptics. Die Produktpalette deckt die gesamte Skala ab, von kleinen Büronetzwerken bis hin zu großen Unternehmensumgebungen für Kupfer- und Glasfasernetzwerke von 10 MB/s bis 10 GB/s.
Preis: 325 $ (im Direktversand).
Überwachen Ihres Netzwerks mit Teeny Tap
Überwachen Ihres Netzwerks mit Teeny Tap (Zum Vergrößern auf das Bild klicken)

Optimieren des Computers
DTweak Pro
www.daoisoft.com
Als IT-Experte (und als Technologiefan) haben Sie zweifellos den Wunsch, so viel Leistung wie möglich aus Ihrem System herauszuholen und eine möglichst individuelle Anpassung an Ihre täglichen Aufgaben zu erreichen. Es gibt einige Tools, mit denen Sie die Benutzerfunktionalität auf Ihrem Computer, auf dem Windows Vista® ausgeführt wird, optimieren und anpassen können. Eine preiswerte Möglichkeit ist DTweak Pro von Daoisoft. (Es ist auch eine Version für Windows® XP und Windows Server® 2003 verfügbar.)
Die Anwendung bietet einige Schnellansichten für verschiedenen Tools sowie Anpassungen für Windows Vista. Im Abschnitt „Daily Tools“ können Sie beispielsweise ein Tool für die Bereinigung der Registrierungsdatenbank, ein Dienstprogramm für die Dateibereinigung, Tools für die Defragmentierung der Registrierungsdatenbank und der Datenträger sowie einen Festplattenleistungsmonitor ausführen.
Mit DTweak können Sie auch problemlos die Startelemente anzeigen und anpassen, CPU-Daten abrufen (z. B. CPU-ID, Busgeschwindigkeit, Taktfrequenz) und Computerinformationen sammeln, z. B. Anbieter, Startzustand, Speicherkonfiguration und Systemtyp. Sie können sogar Ihren E/A-Cache anpassen und auch die Wartezeit, bis abgestürzte Programme und Dienste beendet werden.
Der Abschnitt „Tools“ in der grafischen Benutzeroberfläche enthält Links zu integrierten Windows Vista-Tools (z. B. „diskpart“ und „system restore) sowie Links zu nützlichen Netzwerktools (z. B. „finger“, „ping“, „netstat“ und „nslookup“). Weitere Netzwerkoptimierungen ermöglichen das Anpassen der Einstellungen für die maximale Übertragungseinheit, TCP/IP-TTL und DNS-Timeout sowie das Beschränken der Bandbreite mit dem QoS-Paketplanerdienst.
Preis: 29,95 $ (direktes Herunterladen).
Anpassen und Optimieren des Systems mit DTweak
Anpassen und Optimieren des Systems mit DTweak (Zum Vergrößern auf das Bild klicken)

Buchbesprechung
Microsoft Exchange Server 2007 Administrator's Companion
www.microsoft.com/mspress
E-Mails können richtig heikel sein. Sie haben beispielsweise keine richtige Kontrolle über den Strom eingehender Nachrichten. Wenn Sie versuchen, die eingehende Flut durch Anhalten Ihres SMTP-Servers abzuwehren, bis seine Warteschlangen wieder kleiner sind, riskieren Sie, dass der Absender einen Hinweis auf Nichtzustellbarkeit erhält. Die Analogie eines Wasserrohrsystems passt hier sehr genau: Das Wasser fließt immer, und wenn Sie ein Ventil in einem Teil schließen, riskieren Sie an anderer Stelle einen Rohrbruch. Eine gut geplante, gut abgestimmte und flexible E-Mail-Infrastruktur ist von entscheidender Bedeutung, wenn Ihr Geschäft im Großen und Ganzen reibungslos laufen soll.
Microsoft Exchange Server® 2007 ist dafür ausgelegt, enorme Mengen an E-Mails zu verarbeiten und Ihre Infrastruktur an die heutigen und künftigen Anforderungen Ihrer Organisation anzupassen. Aber in einer Bereitstellung von Exchange 2007 gibt es eine Vielzahl an Optionen und Entscheidungsmöglichkeiten. Exchange deckt viel mehr ab als nur E-Mail-Verkehr, was die Aufgabe weiter erschwert.
Sie brauchen wirklich eine oder zwei gute Referenzressourcen, damit Sie die richtigen Entscheidungen für die Architektur und die Verwaltung treffen können. Eine unerlässliche Ressource ist das Buch „Microsoft Exchange Server 2007 Administrator's Companion“.
Dieses Buch deckt den gesamten Lebenszyklus der Produktbereitstellung ab, von der Planung und Bereitstellung bis hin zur Wartung und Sicherheit. Auch die verschiedenen Clients und die verfügbaren Clientkonnektivitätsoptionen für Exchange 2007 werden erörtert. Das Buch beginnt mit einem Überblick über die Unterschiede zwischen den verschiedenen Versionen und beleuchtet die Neuerungen in Exchange 2007. Außerdem erhalten Sie einen vollständigen Überblick über die verschiedenen Architekturkomponenten von Exchange Server 2007.
Im folgenden Abschnitt wird erklärt, wie Sie die Bereitstellung von Exchange planen sollten und wie Sie die Speicher-, Server- und Prozessoranforderungen berechnen und Fehlertoleranz hinzufügen können. Anschließend wird die eigentliche Installation und Bereitstellung erläutert. Hier sehen Sie, wie Sie Ihren Server für Exchange vorbereiten und die verschiedenen Komponenten der Software installieren können. Sie erhalten sogar detaillierte Tipps zum Gruppieren von Exchange-Diensten, um so eine höhere Stufe der Verfügbarkeit zu erreichen.
Im Anschluss daran werden die zahlreichen Verwaltungstools vorgestellt, z. B. die Exchange-MMC und die neue, auf Windows PowerShell™ basierende Exchange-Verwaltungsshell. Hier erfahren Sie auch alles Wichtige vom Anlegen von Postfächern über das Erstellen von Speichergruppen bis hin zu Sicherungs- und Wiederherstellungsvorgängen. Das ist aber noch nicht alles: In diesem Abschnitt sehen Sie auch, wie Sie alle diese Aufgaben mit der Verwaltungs-GUI und über die Befehlszeile mittels Windows PowerShell erledigen können.
Exchange 2007 bietet eine Reihe von Unified Messaging-Features, mit denen Sie sowohl die Datenkommunikation als auch die Sprachkommunikation mit einem einzigen System verwalten können. Darüber hinaus wird im Buch gezeigt, wie Sie Sprachnachrichten, Faxnachrichten und den sprachbasierten Zugriff auf den Posteingang einrichten und nutzen können, um nur einige Punkte zu nennen.
In Bezug auf das Thema Wartung werden grundlegende Verfahren und Tools für die Fehlerbehebung, die Wiederherstellung bei Beschädigungen und Notfällen sowie die Leistungsoptimierung beschrieben. Sicherheit muss selbstverständlich den Schwerpunkt bei einem Unified Messaging-System bilden. Im Buch finden Sie detaillierte Informationen zum Sichern Ihrer Bereitstellung. Sie erfahren einiges über Sicherheitsrichtlinien, über Antivirus- und Antispamfeatures und über die Public Key-Infrastruktur.
Abschließend werden Exchange-Clients sowie die Unterstützung anderer POP3- und IMAP-Clients (Internet Message Access Protocol) in Ihrer Organisation besprochen. Alles in allem ist dies ein gutes allgemeines Referenzhandbuch für alle Administratoren, unabhängig davon, ob sie für die Planung oder die Wartung der Unified Messaging-Plattform von Exchange Server 2007 Server verantwortlich sind oder sich einfach nur dafür interessieren.
Preis: 49,99 $ (Listenpreis).
(Zum Vergrößern auf das Bild klicken)

Greg Steen ist Technologieexperte, Unternehmer und Enthusiast. Er ist immer auf der Suche nach neuen Tools, um IT-Experten Betriebs-, Qualitätssicherungs- und Entwicklungsprozesse zu erleichtern.


SQL – Fragen und Antworten E/A-Fehler, Datenbankspiegelung und mehr
Paul S. Randal

F: Ich führe seit kurzem regelmäßige Konsistenzprüfungen für meine verwalteten Datenbanken durch und habe sogar ein paar SQL Agent-Warnungen hinzugefügt, mit denen E/A-Fehler aus den Benutzerabfragen abgefangen werden. Ich weiß nicht, ob die Logik wirklich funktioniert, die ich um die Überprüfungen und die Warnungen herum implementiert habe, weil keine meiner Datenbanken eine Beschädigung aufweist. Wie kann ich Beschädigungen in einer Testdatenbank erzeugen, damit ich sicher sein kann, dass ich alles richtig eingerichtet habe? Gibt es noch mehr, woran ich E/A-Fehler erkennen kann?
A: Der alte Trick bei SQL Server® 2000, mit dem eine fehlerhafte Datenbank zu Testzwecken erstellt werden konnte, bestand darin, manuell eine Zeile aus der sysindexes-Tabelle in einer Testdatenbank zu löschen. Aber bei SQL Server 2005 ist die Beschädigung einer Systemtabelle auf diese Weise sehr schwierig. Die beste Möglichkeit, eine Testdatenbank zu beschädigen, ist ein Hex-Editor, mit dem Sie eine Datei bearbeiten können, während die Datenbank heruntergefahren ist. Gehen Sie wie folgt vor:
  • Fahren Sie die Datenbank herunter, damit die Dateien nicht gesperrt sind. (Achten Sie aber darauf, die Datenbank nicht zu trennen, denn wenn Sie die falsche Seite beschädigen, können Sie sie u. U. nicht wieder anhängen.)
  • Wählen Sie einen Offset aus, der mindestens 100 Seiten (mindestens 819.200 Byte) weit in der Datei auftritt, aber achten Sie darauf, dass der Offset an einer 8192-Byte-Begrenzung (einer Seitenbegrenzung) ausgerichtet ist. Damit gehen Sie kritischen Metadatenseiten und Zuordnungsbitmustern aus dem Weg, sodass Sie die Datenbank starten und DBCC CHECKDB ausführen können.
  • Schreiben Sie am ausgewählten Offset einige leere Bytes (Nullen) in die Datei. Dieses Verfahren ist fast schon eine Garantie für einige Seitenheader-Beschädigungsfehler.
Nichtsdestoweniger gilt: Die schnellste Möglichkeit, eine fehlerhafte Testdatenbank zu erstellen, besteht in der Verwendung einer fehlerhaften Datenbank, die ein anderer Benutzer bereits erstellt hat. Beispiele für fehlerhafte SQL Server 2000- und SQL Server 2005-Datenbanken (mit Erklärungen) finden Sie in meinem Blog (unter go.microsoft.com/fwlink/?LinkId=115151).
Was Ihre zweite Frage angeht, wie Sie E/A-Fehler erkennen: Aktivieren Sie Seitenprüfsummen. Dieses Feature stand erstmals bei SQL Server 2005 zur Verfügung und sollte eine gesamte Datenbankseite vor Fehlern schützen, die vom E/A-Subsystem eingeführt wurden.
Wenn eine Seite auf einen Datenträger geschrieben wird, berechnet SQL Server abschließend eine Prüfsumme für die gesamte 8-KB-Seite, und die Prüfsumme wird auf der Seite eingetragen. Wird eine Seite vom Datenträger gelesen, die eine Seitenprüfsumme besitzt, wird die Prüfsumme neu berechnet und mit der auf der Seite gespeicherten Prüfsumme verglichen. Stimmen diese Werte nicht überein, wurde die Seite durch eine Ursache außerhalb von SQL Server beschädigt, und der Fehler 824 wird ausgelöst. Der Fehler wird für die Verbindung angezeigt, die das Lesen der Seite ausgelöst hat, und im SQL Server-Fehlerprotokoll und im Windows®-Anwendungsereignisprotokoll festgehalten.
Seitenprüfsummen sind standardmäßig für alle Datenbanken aktiviert, die unter SQL Server 2005 und SQL Server 2008 erstellt werden. Bei Datenbanken, die von früheren Versionen von SQL Server auf eine neuere Version aktualisiert wurden, müssen sie jedoch manuell aktiviert werden. Mit diesem Code aktivieren Sie die Seitenprüfsummen:
ALTER DATABASE mydb SET PAGE_VERIFY CHECKSUM;

Tipp: Ändern des SQL Server-Standardports
Standardmäßig ist Port 1433 der konfigurierte Port für SQL Server-Instanzen. Sobald dieser Port von einer Instanz verwendet wird, kann er nicht mehr von einer anderen Instanz genutzt werden. Wenn Sie also eine zweite (benannte) Instanz installieren, die das Netz mithilfe von tcp abhört, benötigt diese Instanz einen anderen Port. In einigen Fällen möchte der Administrator den Port aus Verschleierungsgründen ändern (obwohl die Verschleierung dabei eher gering ist und problemlos von einem Portscanner überwunden werden kann). In diesem Fall müssen Sie dann den Client natürlich so konfigurieren, dass er einen anderen Port verwendet. Hierzu gibt es drei übliche Verfahren.
Erstens: Angenommen, der Administrator hat den Port einer Instanz in 5555 geändert. Dann können Sie einfach die Portnummer der Instanz innerhalb des Namens des Computers angeben, zu dem eine Verbindung hergestellt werden soll, und zwar mit der Syntax „MeinServername,5555“. Ändert sich der Port erneut, müssen die Clients ihre connectionStrings ebenfalls ändern.
Eine andere Option besteht in der Verwendung von SQL Server-Aliasnamen, die auf dem Client konfiguriert werden. Neben dem Aliasnamen müssen auch der Servername, der Portname und das Protokoll angegeben werden. Ein einmal konfigurierter Alias kann wie ein Servername verwendet werden, um eine Verbindung zur Datenbankinstanz herzustellen. Der Vorteil bei dieser Option besteht darin, dass Änderungen der Serverkonfiguration von einem Domänenadministrator bereitgestellt werden können, weil die Einstellungen in der Registrierung gespeichert sind.
Die dritte Option für benannte Instanzen, in denen der Benutzer nur den Instanznamen kennt und den Namen mit der Syntax „Computername\Instanzname im ConnectionString“ angibt, ist der SQL Server-Browserdienst. Dieser Dienst ist bereits in SQL Server 2000 als Teil eines ausführenden Diensts implementiert. Bei SQL Server 2005 wurde der SQL Server-Browserdienst als separater Dienst implementiert. Neben der Instanzermittlung für den Computer beantwortet dieser Dienst auch eingehende UDP-Anforderungen (User Datagram-Protokoll) auf Port 1434 mit der entsprechenden Portnummer für die angeforderte Instanz, was eine Umleitung für den Client und die Unterstützung einer transparenten Verbindung ermöglicht.
– Jens K. Süßmeyer, Datenbankberater bei Microsoft

F: Um die Fragmentierung in meiner Datenbank zu beseitigen, habe ich einen nächtlichen Wartungsplan eingerichtet, mit dem sämtliche Indizes in der Produktionsdatenbank neu erstellt werden. Die Produktionsdatenbank wird unter SQL Server 2005 Enterprise Edition mit SP2 ausgeführt. Ich habe bemerkt, dass die Datenbank hierdurch übermäßig stark anwächst. Deshalb habe ich einen weiteren Schritt eingefügt, mit dem diese zusätzlichen Leerräume verkleinert werden, weil es nicht viel Platz auf dem Datenträger gibt. Jetzt scheint der Neuerstellungsschritt nicht mehr zu funktionieren. Woran liegt das?
A: Sie sind auf ein Problem gestoßen, das beim Einrichten eines Wartungsplans häufig auftritt. Sie sind in einem Zyklus mit Jo-Jo-Effekt gefangen.
Beim Neuerstellen eines Index wird zuerst eine neue Kopie des Index erstellt, bevor der vorhandene Index gelöscht wird. Dieses Verfahren erfordert zusätzlichen Platz in den Datenbankdateien – meist ebenso viel Platz wie der eigentliche Index. In SQL Server 2000 war auch zusätzlicher Platz zum Sortieren der Indexzeilen erforderlich (etwa 20 Prozent der Indexgröße), aber diese Anforderung wurde durch eine einfache Indexneuerstellung in SQL Server 2005 ersetzt.
In einigen Fällen möchten die Administratoren den zusätzlichen Platz beseitigen, der durch die Neuerstellung des Index entstanden ist. Darum fügen sie in den Wartungsplan nach dem Neuerstellungsschritt einen Verkleinerungsvorgang ein. Leider ist nicht allgemein bekannt, dass dieser Verkleinerungsvorgang aufgrund der Art des Algorithmus zu einer Indexfragmentierung führt. Dies bedeutet, dass der neu erstellte und defragmentierte Index sofort wieder fragmentiert wird, was die positive Wirkung der Neuerstellung zunichte macht.
In Anbetracht der Tatsache, dass die Datenbankdatei bei der nächsten Indexneuerstellung weiter wachsen wird, ist es besser, den zusätzlichen Platz in der Datenbank zu belassen und ganz auf den Verkleinerungsvorgang zu verzichten. (Darüber hinaus führt das dauernde Vergrößern und Verkleinern der Datenbankdateien zu Dateifragmentierung auf der Betriebssystemebene, was auf dieselbe Weise wie die Indexfragmentierung zu Leistungseinbußen führen kann.)
Eine weitere Möglichkeit ist die Verlängerung der Intervalle, in denen Sie die Indizes neu erstellen. Oder probieren Sie einmal eine alternative Methode aus, z. B. das alte DBCC INDEXDEFRAG, das ich für SQL Server 2000 geschrieben hatte, oder die neuere ALTER INDEX REORGANIZE-Syntax in SQL Server 2005 und SQL Server 2008.
Es gibt ein nützliches Whitepaper, in dem die Indexfragmentierung erläutert wird und das Anhaltspunkte für den richtigen Zeitpunkt liefert, zu dem die Fragmentierung beseitigt werden sollte (unter go.microsoft.com/fwlink/?LinkId=115154). Dieser Artikel wurde für SQL Server 2000 geschrieben, aber die Konzepte sind immer noch gültig.

F: Wir haben die Strategie zur Notfallwiederherstellung in meinem Unternehmen evaluiert, und ich denke, dass die Datenbankspiegelung der richtige Weg für unsere Situation sein könnte. Auf dem Server, den ich zu schützen versuche, befinden sich viele nicht zusammenhängende Datenbanken (das Ergebnis eines früheren Serverkonsolidierungsprojekts), und ich möchte die Datenbankspiegelung für alle diese Datenbanken verwenden. Ich beschäftige mich nun mit der Frage, wie viele Datenbanken ich spiegeln kann, bevor die Leistung zurückgeht.
A: Die Antwort auf diese Frage ist eine, die ich immer wieder gebe: Das kommt ganz darauf an. Laut den veröffentlichten Richtlinien sollten nicht mehr als 10 Datenbanken pro Instanz gespiegelt werden, aber diese Zahl ist nur eine grobe Schätzung des Maximalwerts für die meisten Benutzer. Berücksichtigen Sie die folgenden Faktoren beim Hardwaresetup:
  • Wie viel Speicher benötigen die Prinzipal- und die Spiegelinstanz? (Im Idealfall sollte dieser Wert identisch sein.)
  • Wie viel Verarbeitungsleistung benötigen die Prinzipal- und die Spiegelinstanz? (Auch dieser Wert sollte gleich sein.)
  • Wie viel Bandbreite besitzt das E/A-Subsystem auf der Spiegelinstanz? (Dieser Wert sollte identisch mit dem Wert auf der Prinzipalinstanz sein.)
  • Wie viele Transaktionsprotokolleinträge werden jeweils durch die Arbeitsauslastung der Datenbanken erzeugt?
  • Wie viel Netzwerkbandbreite ist zwischen der Prinzipalinstanz und der Spiegelinstanz verfügbar?
Die letzten beiden Faktoren sind am wichtigsten. Wenn die verfügbare Netzwerkbandbreite zwischen den beiden Instanzen nicht ausreicht, um die kombinierte Anzahl der erzeugten Transaktionsprotokolleinträge pro Sekunde für alle zu spiegelnden Datenbanken zu bewältigen, fällt die Leistung der Prinzipaldatenbanken ab. SQL Server 2008 trägt dazu bei, diese Belastung mithilfe der Protokolldatenstromkomprimierung zu verringern.
Der zweitwichtigste Aspekt sind die Speicher- und Threadanforderungen für das Spiegeln. Jede gespiegelte Datenbank benötigt einen Thread und dazu eine gewisse Speichermenge. Bei Servern mit geringerer Leistung führt eine große Anzahl gespiegelter Datenbanken zusammen mit der normalen Arbeitsauslastung eventuell zu einer zu starken Auslastung des Servers.
Überlegen Sie auch, wie die Datenbankspiegelung durchgeführt werden soll. Im synchronen Modus können Transaktionen auf der Prinzipaldatenbank erst dann einsetzen, wenn alle Transaktionsprotokolldatensätze in das Transaktionsprotokoll der gespiegelten Datenbank kopiert wurden. Deshalb könnten jegliche Verzögerungen durch ein überlastetes Netzwerk bei der Prinzipaldatenbank ein Leistungsproblem bezüglich der Arbeitsauslastung verursachen.
Im asynchronen Modus können Transaktionen auf der Prinzipaldatenbank ohne Wartezeit einsetzen, aber eine Netzwerkverzögerung könnte die Menge der Transaktionsprotokolleinträge, die an die Spiegelung gesendet werden sollen, anwachsen lassen. Dies kann Probleme mit der Transaktionsprotokollgröße verursachen. Aber es kommt noch schlimmer: Bei einem Ausfall oder einem Fehler können nicht gesendete Transaktionsprotokolle verloren gehen. Je mehr Transaktionsprotokolleinträge also noch nicht gesendet wurden, desto größer ist das Risiko von Datenverlusten bei einer Wiederherstellungssituation.
Die Szenarios können sich beträchtlich voneinander unterscheiden, und ich habe einige interessante Beispiele in realen Produktionsumgebungen gesehen. Beispielsweise habe ich eine Umgebung mit 150 Datenbanken gesehen, die alle nur äußerst geringe Aktivitäten aufwiesen, die zudem nicht alle gleichzeitig auftraten. Alle 150 Datenbanken wurden problemlos gespiegelt.
Als Gegenbeispiel sei ein Setup genannt, in dem nur drei stark ausgelastete Datenbanken arbeiteten, das jedoch ohne gute Netzwerkverbindung. In diesem Szenario konnte gerade mal eine einzige Datenbank gespiegelt werden, bevor der Mangel der Netzwerkbandbreite zu einem Rückgang der Arbeitsauslastung führte.
Der Schlüssel zum Erfolg besteht darin, zuerst den Umfang der erzeugten Protokolle zu berechnen. Wenn es scheint, dass die verfügbare Netzwerkbandbreite die Anzahl der zu spiegelnden Datenbanken unterstützen wird, dürfte alles gut gehen. Testen Sie Ihre Konfiguration, bevor Sie sie in der Produktionsumgebung einführen, und achten Sie darauf, alle Vorgänge aufzunehmen, bei denen Einträge für das Transaktionsprotokoll erzeugt werden könnten. Dies gilt insbesondere für sämtliche Arbeiten im Rahmen der Datenbankwartung.

Paul S. Randal ist der leitende Direktor von SQLskills.com und ein SQL Server-MVP. Paul Randal war von 1999 bis 2007 im SQL Server-Speichermodulteam von Microsoft tätig. Er schrieb DBCC CHECKDB/repair für SQL Server 2005 und war bei der Entwicklung von SQL Server 2008 für das Kernspeichermodul zuständig. Als Experte für Notfallwiederherstellung, hohe Verfügbarkeit und Datenbankwartung ist Paul Randal ein regelmäßiger Referent bei Konferenzen. Sein Blog befindet sich unter SQLskills.com/blogs/paul.


Schwerpunkt Dienstprogramme Windows Vista Upgrade Advisor
Lance Whitney

Es ist an der Zeit, das Upgrade Ihrer Organisation auf Windows Vista® zu planen. Wie bei jedem Upgrade gibt es einige Fragen. Erfüllen Ihre Netzwerkclients die Hardware- und Softwareanforderungen? Mit welchen Kompatibilitätsproblemen werden Sie konfrontiert? Um diese und andere Fragen zu beantworten, stellt Microsoft den kostenlosen Windows Vista Upgrade Advisor bereit. Dieses Dienstprogramm durchsucht die gesamte installierte Hardware und Software auf einem PC, um festzustellen, ob ein Upgrade durchführbar ist. Wenn dies möglich ist, empfiehlt der Advisor die optimale Windows Vista-Version und zeigt Probleme auf, die vor einem Upgrade gelöst werden sollten.
Der Upgrade Advisor-Scan nimmt in der Regel mehrere Minuten in Anspruch. Während seiner Ausführung werden die verschiedenen Versionen von Windows Vista in einem Diagramm aufgeführt und die jeweiligen Features miteinander verglichen. Sie können auch eine bestimmte Edition (Ultimate, Home Premium, Business oder Home Basic) auswählen, um sich eine Kurzbeschreibung und eine Liste wichtiger Features anzeigen zu lassen. Nach Abschluss der Überprüfung teilt der Bildschirm „Report Details“ (Berichtdetails) Ihnen mit, ob Ihr PC für Windows Vista tauglich ist und welche Version sich empfiehlt. Die Einzelheiten umfassen Folgendes:
Systemanforderungen Hier erfahren Sie, ob Ihre Hardware (CPU, RAM, Videospeicher und CD/DVD-Laufwerk) ausreichen. Wenn dies nicht der Fall ist, werden Einzelheiten dazu angezeigt, was zum Aktualisieren Ihres PC erforderlich ist (wie viel Speicher beispielsweise hinzugefügt werden muss).
Geräte Hier werden alle externen Geräte und Treiber einschließlich Modem, Drucker, Scanner, Soundkarte, Monitor und Videokarte überprüft. Wenn ein Gerät den Kompatibilitätstest nicht besteht, wird erläutert, welche Aktionen erforderlich sind, beispielsweise das Herunterladen der aktuellen Treiber von der Website des Herstellers. Ein Link zur jeweiligen Website wird ebenfalls bereitgestellt.
Upgrade Advisor meldet bekannte Kompatibilitätsprobleme und empfiehlt Möglichkeiten für ihre Lösung.
Upgrade Advisor meldet bekannte Kompatibilitätsprobleme und empfiehlt Möglichkeiten für ihre Lösung. (Zum Vergrößern auf das Bild klicken)
Programme Hier wird die installierte Software analysiert. Sie erfahren, welche Anwendungen ohne Änderungen unter Windows Vista ausgeführt werden können und welche inkompatibel sind oder aktualisiert werden müssen.
Wenn Komponenten den Kompatibilitätstest unter einer leistungsfähigeren Version von Windows Vista, z. B. Ultimate, nicht bestehen, können Sie wieder zum Einführungsbildschirm wechseln und eine andere Version, beispielsweise Business, auswählen. So können Sie feststellen, ob Ihr PC alle Anforderungen dieser Version erfüllt.
Schließlich werden in einer Aufgabenliste die Hardwarekonfiguration Ihres PC sowie die Aufgaben aufgeführt, die vor und nach dem Installieren von Windows Vista abgeschlossen werden müssen. Die Elemente aus den vorhergehenden Bildschirmen werden hier zusammengefasst und zusätzliche Empfehlungen bereitgestellt (siehe Screenshot). Die Aufgabenliste kann ausgedruckt oder als HTML-Datei gespeichert werden.
Upgrade Advisor wird unter 32-Bit-Windows Vista oder Windows® XP Service Pack 2 ausgeführt. Außerdem sind Microsoft® .NET Framework 2.0 und MSXML 6.0 erforderlich. Unter microsoft.com/windows/products/windowsvista/buyorupgrade/upgradeadvisor.mspx erhalten Sie weitere Informationen und können das Tool herunterladen.

Lance Whitney ist IT-Berater, Schulungsleiter und Autor technischer Artikel. Er hat sich intensiv mit dem Optimieren von Windows-Arbeitsstationen und -Servern beschäftigt. Er ist von Haus aus Journalist und hat vor etwa 15 Jahren den Sprung in das kalte Wasser der IT-Welt getan.


Einblicke in SharePoint Dezentralisieren der Websiteverwaltung
Pav Cherny

Laden Sie den Code für diesen Artikel herunter: SharePoint2008_06.exe (1160KB)

Microsoft Windows SharePoint Services (WSS) 3.0 und Microsoft Office SharePoint Server (MOSS) 2007 unterstützen ein flexibles Verwaltungs- und Sicherheitsmodell, mit dem IT-Organisationen in der Lage sind, die Kontrolle der Infrastrukturkomponenten (z. B. Webserver und Datenbankserver) zu zentralisieren und gleichzeitig die Kontrolle gehosteter
Websitesammlungen und Websites zu dezentralisieren. Die Zentralisierung der SharePoint®-Infrastruktur trägt dazu bei, den Wartungsaufwand zu verringern, die Geschäftslogik zu konsolidieren, einen einzigen Zugriffspunkt für SharePoint-Ressourcen zu bieten und unnötige Investitionen in Technologien zu vermeiden.
Gleichzeitig können Sie mit der Dezentralisierung der Websiteverwaltung sicherstellen, dass einzelne Abteilungen die autonome Kontrolle über ihre abteilungsspezifischen SharePoint-Websitesammlungen, Websites, Dokumentbibliotheken, Listen, Workflowlösungen sowie über andere SharePoint-Ressourcen behalten. Ein Nebeneffekt beim Delegieren der Websiteverwaltung an einzelne Abteilungen besteht allerdings darin, dass die Wartungskomplexität für die IT-Abteilung erhöht wird. Wie verfolgen Sie beispielsweise den Verlauf der Ressourcenverwendung, abgelaufene SharePoint-Websites und veraltete Inhalte in einer zentralisierten Infrastruktur, wenn Sie keinen Zugriff auf die Websitesammlungen und Websites innerhalb Ihrer Umgebung besitzen?
In diesem Artikel erläutere ich das Sicherheitsmodell von WSS 3.0 mit seinen Vorteilen und Auswirkungen, wenn die administrative Kontrolle der SharePoint-Websites an einzelne Abteilungen delegiert wird, während die administrative Kontrolle der SharePoint-Infrastruktur zentralisiert bleibt. Ich zeige Ihnen, wie die delegierte Websiteverwaltung funktioniert, wie Zugriffsberechtigungen und Sicherheitsanpassungen auf Website-, Listen- und Elementebene für eine sichere und benutzerfreundliche Arbeitsumgebung sorgen und wie Webfarmadministratoren Zugang zu den notwendigen Websitestatistiken ohne erhöhte SharePoint-Berechtigungen erhalten können.
Wenn Sie meinen Erklärungen in einer Testumgebung folgen möchten, laden Sie das Begleitmaterial für diesen Artikel unter technetmagazine.com herunter. Das Material enthält ausführliche Bereitstellungsanweisungen für eine auf Windows Server® 2008 basierende Webfarm, die eine Produktionsumgebung für ein Unternehmen mit mehreren Abteilungen angemessen widerspiegelt.

SharePoint-Infrastruktur und Administration der Websitesammlungen
Sie können eine SharePoint-Infrastruktur wahlweise auf Grundlage einer Einzelserverbereitstellung oder einer Webfarmbereitstellung erstellen. In den meisten Unternehmen gibt es beides. Die Einzelserverbereitstellung eignet sich für einzelne Abteilungen, die eine schnelle und einfache Lösung für die Zusammenarbeit benötigen. Die Leistungs- und Zuverlässigkeitsanforderungen sind minimal. Benutzer verstehen haben meist Verständnis, wenn in einer Abteilung ein SharePoint-Server, der oft auf Arbeitsstationshardware bereitgestellt wurde, nicht verfügbar ist, weil die Systemwartung in den Verantwortungsbereich der Abteilung fällt und die Benutzer in dieser Abteilung schließlich keine IT-Administratoren sind.
Das Bild ändert sich vollständig für Serverressourcen, die von der IT-Abteilung betreut werden. Leistung und Zuverlässigkeit werden zu kritischen Faktoren, die oft die Bereitstellung von Hochverfügbarkeitslösungen erfordern, um die Einhaltung der Vereinbarung zum Servicelevel (Service Level Agreement, SLA) zu gewährleisten. Webfarmbereitstellungen mit Lastenausgleich, SQL Server®-Failovercluster sowie Datenbanken, die in SANs (Storage Area Network) gespeichert sind, können dazu beitragen, die Anforderungen Ihres Unternehmens an Leistung und Verfügbarkeit zu erfüllen. In Abbildung 1 ist diese Architektur dargestellt.
Abbildung 1 SharePoint-Infrastruktur mit SQL Server-Failovercluster und SAN
Abbildung 1 SharePoint-Infrastruktur mit SQL Server-Failovercluster und SAN (Zum Vergrößern auf das Bild klicken)
Wie aus Abbildung 1 ersichtlich ist, müssen mehrere Arten von Administratoren zusammenarbeiten, um die Ressourcen in einer zentralisierten SharePoint-Infrastruktur zu pflegen, und doch betrachtet jeder dieser Administratoren die Umgebung aus einer anderen Perspektive. Beispielsweise sind die Server in der Infrastruktur für Websitesammlungsadministratoren transparent. Websitesammlungsadministratoren arbeiten mit der standardmäßigen SharePoint-Benutzeroberfläche. Diese Benutzeroberfläche bleibt immer gleich, unabhängig davon, ob Sie die Websites auf einer Arbeitsstation mit WSS 3.0 in Ihrem Büro oder auf einer Webfarm in einem Rechenzentrum hosten.
Die SharePoint-Infrastruktur ist auch für Datenbankadministratoren und SAN-Speichertechniker transparent. Für diese Administratoren unterscheiden sich SharePoint-Datenbanken nicht von anderem SQL Server-Datenbanken, und die logischen Gerätenummern (logical unit numbers, LUNs) für den SQL Server-Failovercluster unterscheiden sich nicht von anderem LUNs. Der Administrator, der unmittelbar mit der SharePoint-Infrastruktur zu tun hat, ist der Webfarmadministrator. Dennoch hat diese Person keine Kontrolle über die Websitesammlungen, Datenbanken oder LUNs.
Man kann durchaus sagen, dass sich diese Websitesammlungsadministratoren in den Abteilungen meist nicht mit Infrastrukturdetails auskennen. Diese Details sind letztendlich auch nicht notwendig, um Websites bereitzustellen und Zugriffsberechtigungen an Teams und Gruppen in einer Abteilung zu delegieren. Es geht ganz einfach, eine neue Website zu erstellen und die Zusammenarbeit zu beginnen. Probleme wie die hohen Speicherkosten, die sich aus der SAN-Technologie ergeben, werden nur selten bedacht.
Mit jedem Projekt und mit jeder neuen Initiative läuft das Schema von vorn ab: Neue Teamwebsites erscheinen, ausgediente Websites bestehen fort, veraltete Inhalte werden nicht gelöscht, und die SharePoint-Umgebung wuchert in einer atemberaubenden Geschwindigkeit, bis sie eine Größenordnung erreicht, die die Systemadministratoren nicht mehr ignorieren können. Beispielsweise bestand die interne SharePoint-Umgebung bei Microsoft einmal aus mehr als 180.000 Websites, bis Microsoft IT im Jahr 2006 eine Vereinfachungsinitiative startete.
Die Weiterbildung von Websitesammlungsadministratoren kann dabei helfen, die Angelegenheiten in einer zentralisierten SharePoint-Infrastruktur unter Kontrolle zu halten. Auch Kontingente und Sperren für Websitesammlungen sind sinnvoll, aber diese Methoden sind nicht sehr wirksam, wenn es um veraltete Teamwebsites und Inhalte geht, die nur kostbaren Speicher und Sicherungsressourcen verschwenden.
Veraltete Inhalte bringen eine Websitesammlung nicht unbedingt über das Kontingent. Natürlich können Sie SharePoint so konfigurieren, dass die Besitzer der Websitesammlungen eine E-Mail-Benachrichtigung erhalten und dass unbenutzte Websitesammlungen nach einem bestimmten Zeitraum mithilfe des Features „Bestätigung der Websitenutzung und Löschung“ auf der Website der SharePoint 3.0-Zentraladministration automatisch gelöscht werden, aber dieses Feature funktioniert nicht auf der Ebene einzelner Websites. Eine Websitesammlung kann aktuelle und veraltete Websites enthalten, aber das Feature „Bestätigung der Websitenutzung und Löschung“ greift auf dieser Detailebene nicht mehr.
Später werde ich Ihnen zeigen, wie Sie unbenutzte Websites und veraltete Inhalte durch Prüfen des letzten Änderungsdatums von Dokumenten und Listenelementen erkennen, und das sogar ohne Zugriffsberechtigungen für die Websitesammlung zu besitzen. Dieses Berichterstattungsfeature ist nicht standardmäßig verfügbar, lässt sich aber relativ einfach implementieren.

Dezentralisierte SharePoint-Websiteverwaltung
Berechtigungen für die SharePoint-Websiteverwaltung lassen sich auf sehr einfache Weise delegieren. Mit der Website der SharePoint 3.0-Zentraladministration, mit dem Befehlszeilentool „Stsadm.exe“ oder mit einem benutzerdefinierten Bereitstellungstool können Sie Webanwendungen, verwaltete Pfade und Websitesammlungen in der Infrastruktur erstellen. Als Webfarmadministrator können Sie primäre und sekundäre Websitesammlungsadministratoren beim Erstellen einer Websitesammlung angeben. Diese Websitesammlungsadministratoren können normale Domänenbenutzer sein. Diese Benutzer erfordern keine Verwaltungsberechtigungen für die Webfarm oder für andere Infrastrukturserver. Stattdessen führen sie die Aufgaben im Rahmen der Websiteverwaltung über ihren Webbrowser direkt in der SharePoint-Benutzeroberfläche aus.
Abbildung 2 zeigt die delegierte Websiteverwaltung gemäß den Schritt-für-Schritt-Anweisungen, die Sie in den Arbeitsblättern im Begleitmaterial finden. In diesem Beispiel hat der Webfarmadministrator separate Websitesammlungen für die Personalabteilung (http://sharepoint/hr) und die IT-Abteilung (http://sharepoint/it) bereitgestellt.
Abbildung 2 Delegierte SharePoint-Websiteverwaltung
Abbildung 2 Delegierte SharePoint-Websiteverwaltung (Zum Vergrößern auf das Bild klicken)
Die Personalverwaltungs- und IT-Administratoren können dann mithilfe des Features „Websites und Arbeitsbereiche“ im Menü „Websiteaktionen“ in der SharePoint-Benutzeroberfläche untergeordnete Websites erstellen und dabei entweder die Berechtigungen aus der übergeordneten Website übernehmen oder neue Verwaltungs- und Benutzerberechtigungen für die untergeordneten Websites definieren. Sofern nicht explizit anderweitig konfiguriert, kann der Webfarmadministrator auf keine Websites höherer oder untergeordneter Ebene zugreifen, der Personalverwaltungsadministrator erhält keinen Zugriff auf die IT-Websites, und der IT-Administrator kann nicht auf die Websites der Personalverwaltung zugreifen, obwohl alle Websites in der gleichen SharePoint-Umgebung gehostet sind.
Das Design der Websitesammlungen und der Websitehierarchien hängt von den Anforderungen der Organisation ab. Im Beispiel in Abbildung 2 habe ich keine Masterwebsite oberhalb von http://sharepoint/hr und http://sharepoint/it angelegt. Es gibt also keine Websitesammlung im Pfad http://sharepoint. Aber Sie können problemlos eine Websitesammlung an diesem Pfad erstellen oder andere verwaltete Pfade, z. B. http://sharepoint/sites/hr und http://sharepoint/sites/it verwenden.
Außerdem können Sie separate Webanwendungen für die Personalverwaltung und die IT-Abteilung erstellen, um so intuitivere Basis-URLs zu erzielen (z. B. http://hr und http://it), allgemeine Portalwebsites für die Abteilungen bereitzustellen und dann Informationen aus untergeordneten Websites mithilfe zusammenfassender Webparts auf diesen Masterwebsites aufzulisten. Separate Websitesammlungen vereinfachen die autonome Verwaltung und tragen dazu bei, den Zugriff auf Abteilungsinformationen zu beschränken. Sie bieten Funktionen für die individuelle Anpassung von Masterseiten, Seitenlayouts, Vorlagen, Webparts und Navigationssteuerelementen. Sie ermöglichen das Speichern vertraulicher Daten in speziellen Inhaltsdatenbanken getrennt von anderen Websitesammlungen und Inhaltsdatenbanken.

Rollen, Websiteberechtigungen und Sicherheitsanpassungen
Sobald die Websitesammlungen vorhanden sind und die Verwaltungsberechtigungen delegiert wurden, kann ein Websitesammlungsadministrator eine Website oberster Ebene öffnen und mit dem Feature „Websiteeinstellungen“ im Menü „Websiteaktionen“ die Websitesammlung verwalten. Hierzu gehört das Hinzufügen (oder Entfernen) anderer Websitesammlungsadministratoren mit vollen Berechtigungen für alle Websites in der Websitesammlung, das Erstellen von Gruppen, das Zuordnen dieser Gruppen zu Rollen sowie das Hinzufügen von Benutzern zu diesen Gruppen, um Lese- und Teilnahmeberechtigungen zu gewähren. Auch die Bereitstellung von untergeordneten Gruppenwebsites und Teamwebsites gehört dazu.
Sie können zwar den Benutzern die SharePoint-Berechtigungen einzeln gewähren, aber es ist besser, die SharePoint-Gruppen in Übereinstimmung mit bestimmten Rollen zu erstellen. SharePoint enthält z. B. drei Standardgruppen für die Rollen von Besuchern, Teilnehmern und Eigentümern. Besucher haben schreibgeschützten Zugriff. Teilnehmer können Elemente zu Listen und Dokumentbibliotheken hinzufügen und Webseiten personalisieren, und Eigentümer haben vollständige Kontrolle.
Ein wichtiges Feature besteht darin, dass SharePoint Sicherheitsanpassungen gemäß der Benutzerrolle durchführt. Dies bedeutet, dass die Benutzer nur die Links und Elemente in der Benutzeroberfläche sehen, für die sie tatsächlich die entsprechenden Zugriffsberechtigungen besitzen. Wenn Sie einem Benutzer den Zugriff auf eine Ressource nicht gestatten, z. B. auf eine Liste (durch Konfigurieren expliziter Berechtigungen unter „Listeneinstellungen“) oder auf ein bestimmtes Listenelement (mit dem Befehl „Berechtigungen verwalten“ im Kontextmenü des Elements), wird die Liste oder das Element für diesen Benutzer ausgeblendet. Wenn der Benutzer die URL des Elements direkt im Browser eingibt, erhält der Benutzer die Meldung „Fehler: Zugriff verweigert“.
Abbildung 3 zeigt die Sicherheitsanpassungen in Aktion. Der Personaladministrator besitzt volle Berechtigungen und kann das Menü „Websiteaktionen“ öffnen und Verwaltungsaufgaben erledigen. Personalverwaltungsbesucher erhalten dagegen nur schreibgeschützte Berechtigungen für die Websitesammlung und sehen dieses Menü also nicht.
Abbildung 3 Sicherheitsanpassungen auf Grundlage der Benutzerrollen in der SharePoint-Benutzeroberfläche
Abbildung 3 Sicherheitsanpassungen auf Grundlage der Benutzerrollen in der SharePoint-Benutzeroberfläche (Zum Vergrößern auf das Bild klicken)
Sicherheitsanpassungen sind nützlich, weil damit unzugängliche Features, Links und Elemente ausgeblendet werden, was aber auch impliziert, dass die Webfarmadministratoren nicht in der Lage sind, die Websites und Websiteressourcen über die SharePoint-Benutzeroberfläche aufzulisten, wenn sie nicht die entsprechenden Zugriffsberechtigungen haben. Diese Ressourcen sind in Webseiten oder Webparts nicht sichtbar. Außerdem werden unzugängliche Ressourcen nicht in Suchergebnissen aufgeführt, weil die unternehmensweite Suche von SharePoint die Sicherheitsanpassungen zum Zeitpunkt der Abfrage durchführt, und zwar auf Grundlage der Identität des Benutzers, der die Abfrage gesendet hat.

Was ist mit der Befehlszeile?
Wenn die grafische Benutzeroberfläche keinen Zugang zu den gewünschten Informationen ohne erhöhte Berechtigungen auf der Ebene der Websitesammlungen eröffnet, bietet vielleicht das Befehlszeilentool „Stsadm.exe“ die Lösung. Vielleicht denken Sie, dass Sie mit dem Befehl
Stsadm -o enumsites -url http://sharepoint
alle Websitesammlungen und Besitzer innerhalb der http://sharepoint-Webanwendung auflisten können. Dann sollten Sie mit dem folgenden Befehl eine Liste aller untergeordneten Websites abrufen können:
Stsadm -o enumsubwebs -url <Websitesammlung>
In einer Webfarmumgebung quittiert Stsadm.exe diese Abfrage jedoch meist mit einer Fehlermeldung, aus der hervorgeht, dass die Berechtigungen für den Datenbankzugriff fehlen. Stsadm.exe kann die Websitesammlungen nicht auflisten, obwohl Sie als Webfarmadministrator agieren und die Websitesammlungen in der SharePoint 3.0-Zentraladministration verwalten können. Die folgende Fehlermeldung wird ausgegeben, wenn Sie Stsadm.exe auf einer Webfarm ohne SQL-Server-Zugriffsberechtigungen verwenden:
C:\Programme\Gemeinsame Dateien\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o enumsites -url http://sharepoint
<Sites Count="2">
<Site Error="Die von der Anmeldung angeforderte &quot;WSS_Content&quot;-Datenbank kann nicht geöffnet werden. Fehler bei der Anmeldung.&#xD;&#xA;Fehler bei der Anmeldung für den Benutzer 'CONTOSO\SPAdmin'.">
<Site Error="Die von der Anmeldung angeforderte &quot;WSS_Content&quot;-Datenbank kann nicht geöffnet werden. Fehler bei der Anmeldung.&#xD;&#xA;Fehler bei der Anmeldung für den Benutzer 'CONTOSO\SPAdmin'." />
Der Webfarmadministrator erhält diese Fehlermeldung, weil Stsadm.exe im Kontext des angemeldeten Benutzers ausgeführt wird (z. B. CONTOSO\SPAdmin), während die Website der SharePoint 3.0-Zentraladministration auf die SharePoint-Datenbanken im Kontext des Systemkontos zugreift, das dem Anwendungspool der SharePoint 3.0-Zentraladministration zugeordnet ist (z. B. CONTOSO\WssConfigAdmin). Obwohl Sie mit den db_owner-Berechtigungen Ihres Kontos für die Inhaltsdatenbank in SQL Server in der Lage sind, den Befehl „Stsadm -o enumsites -url http://sharepoint“ auszuführen, können Sie dennoch nicht die untergeordneten Websites innerhalb der Websitesammlungen auflisten lassen. Beim Befehl „Stsadm -o enumsubwebs -url <Websitesamlung>“ erhalten Sie die Fehlermeldung „Zugriff verweigert. (Ausnahme von HRESULT: 0x80070005 (E_ACCESSDENIED))“ und stehen wieder am Anfang. Es gibt aber eine bessere Möglichkeit, für die keine erhöhten SQL Server-Berechtigungen erforderlich sind.

Websiteinformationen in Inhaltsdatenbanken
Wenn Sie die erforderlichen Informationen nicht mit den standardmäßigen Benutzeroberflächen und Tools in SharePoint erhalten können, müssen Sie direkt die SharePoint-Inhaltsdatenbanken verwenden. Aber Achtung: Das sollte wirklich der letzte Ausweg sein! Die Inhaltsdatenbanken beruhen auf proprietären Schemas und Datenbankenstrukturen, die Microsoft im WSS 3.0-SDK nur teilweise dokumentiert hat, um so die Kunden davon abzuhalten, direkt mit den Datenbanken zu arbeiten. Wenn möglich, sollten Sie über die SharePoint-Benutzeroberfläche, die Befehlszeilentools, das Objektmodell oder die Webdienste auf die gewünschten Informationen zugreifen.
Wenn Sie keine andere Alternative haben und die Datenbanken direkt nutzen müssen, sollten Sie die Lösung zumindest auf den schreibgeschützten Zugriff beschränken. Änderungen am Datenbankschema oder an den Datenbankstrukturen werden nicht unterstützt und können ernsthafte Probleme auslösen, die dazu führen, dass Sie die Websitesammlungen aus einer Sicherung wiederherstellen oder gar die gesamte SharePoint-Webfarm neu installieren müssen.
Eine mögliche Alternative zur Implementierung einer Berichterstellungslösung, die direkt auf die Inhaltsdatenbanken zugreift, besteht darin, das Konto des Webfarmadministrators als sekundären Eigentümer in der Konfiguration der Websitesammlung anzugeben. Webfarmadministratoren können diesen Schritt auf der Website der SharePoint 3.0-Zentraladministration durchführen. Den entsprechenden Link „Websitesammlungsadministratoren“ finden Sie auf der Seite „Anwendungsverwaltung“ unter „SharePoint-Websiteverwaltung“.
Als sekundärer Websitesammlungsadministrator können Sie die Websitesammlung in Ihrem Webbrowser öffnen, die Websiteeinstellungen abrufen und dann unter „Websiteverwaltung“ auf den Link „Websiteverwendungsbericht“ klicken, vorausgesetzt, Sie haben die Option „Verarbeitung der Verwendungsanalyse“ in der SharePoint 3.0-Zentraladministration aktiviert. Wenn Sie Nutzungsdaten in Protokolldateien auf Ihren SharePoint-Servern nachverfolgen möchten, werfen Sie einen Blick auf den Abschnitt „Protokollierung und Berichterstellung“ auf der Seite „Vorgänge“. Das Feature „Websiteverwendungsbericht“ ist standardmäßig deaktiviert.
Die manuelle Erstellung von Websitenutzungsberichten für einzelne Websitesammlungen ist allerdings nicht zweckmäßig in Umgebungen mit zahlreichen Websitesammlungen oder mit strengen Anforderungen, aufgrund derer Sie den Webfarmadministratoren nicht die erforderlichen Berechtigungen gewähren können. Ein praktischerer Ansatz besteht darin, eine einfache ASP.NET-Berichterstellungsanwendung zu implementieren, die alle Websitesammlungen und alle Websites aus der Inhaltsdatenbank zusammen mit wichtigen Statistiken auflistet, z. B. der Anzahl der Elemente, der Gesamtgröße aller Elemente sowie dem Datum der letzten Änderung der Elementen, wie in Abbildung 4 dargestellt.
Abbildung 4 Direktes Abrufen von Websitestatistiken aus einer Inhaltsdatenbank
Abbildung 4 Direktes Abrufen von Websitestatistiken aus einer Inhaltsdatenbank (Zum Vergrößern auf das Bild klicken)
Wenn Sie diese Anwendung unter der Identität des Anwendungspoolkontos der SharePoint 3.0-Zentraladministration ausführen, können Sie den Zugriff auf die Inhaltsdatenbanken auch ohne erhöhte SQL Server-Berechtigungen erhalten. Wie bereits erwähnt, besitzt das Zentraladministrationskonto bereits die nötigen SQL Server-Berechtigungen.
Das Begleitmaterial enthält eine einfache Berichterstattungslösung, bei der SELECT-Abfragen an die Inhaltsdatenbank auf dem SQL Server gesendet werden, sowie Schritt-für-Schritt-Anweisungen zum Bereitstellen dieser Lösung auf einem Webserver. Hierbei ist zu beachten, dass ich keinerlei Sicherheitsprüfungen implementiert habe. Die Lösung lässt sich mit anonymer Authentifizierung ausführen.
Es ist nicht notwendig, den Benutzer zu authentifizieren, weil das Zentraladministrationskonto den erforderlichen Sicherheitskontext für den Zugriff auf die Inhaltsdatenbanken bietet. Ich habe einen benutzerdefinierten Port für die Website der Lösung verwendet, der durch die Windows®-Firewall unter Windows Server 2008 gesperrt wurde, damit nur lokale Benutzer die Webanwendung öffnen können. In meiner Testumgebung waren die Sicherheitsanforderungen damit erfüllt, aber in einer Produktionsumgebung sollten Sie die Sicherheit erhöhen, beispielsweise durch Aktivieren der Windows-Authentifizierung und durch Konfigurieren beschränkender Zugriffsberechtigungen für das virtuelle Verzeichnis der ASP.NET-Anwendung.

Schlussbemerkung
SharePoint bietet flexible Funktionen für die Verwaltung von Websitesammlungen und Websites, mit denen Sie die SharePoint-Infrastruktur zentralisieren und gleichzeitig die Websiteverwaltung gemäß den speziellen Anforderungen Ihres Unternehmens dezentralisieren können. Eine zentralisierte Infrastruktur kann für Unternehmen jeglicher Größe von Vorteil sein, weil eine konsolidierte Umgebung dazu beiträgt, die Kosten zu senken, weil sie die gemeinsame Nutzung von Daten innerhalb der Abteilungen und auch abteilungsübergreifend ermöglicht, weil sie die Grundlage für den gezielten Einsatz des vorhandenen Fachwissens bildet, um die Umgebung mit hoher Sicherheit, Zuverlässigkeit und Skalierbarkeit zu betreiben, und weil sie den Benutzern einen einzigen Zugriffspunkt für Websites und SharePoint-Ressourcen im Unternehmensnetzwerk bietet.
Gleichzeitig können einzelne Abteilungen und Unternehmenseinheiten die volle Kontrolle über ihre SharePoint-Ressourcen behalten. Webfarmadministratoren können Websitesammlungsadministratoren bestimmen, die dann Websiteverwaltungsaufgaben innerhalb ihres Verantwortungsbereichs ohne weitere Eingriffe durch die IT-Abteilung eigenständig durchführen.
Mit der Verlagerung der Kontrolle auf die Abteilungen verlieren Webfarmadministratoren aber auch die Möglichkeit, die Ressourcennutzung in der Infrastruktur mit den standardmäßigen Features und Tools in SharePoint zu überwachen. Das Zuweisen von Kontingenten für Inhaltsdatenbanken, das Verschicken von E-Mail-Erinnerungen an Websitesammlungsadministratoren sowie das Verfolgen der Nutzungsdaten für die Berichterstattung können dabei helfen, das Problem zu verringern, aber um die SharePoint-Infrastruktur effizient zu verwalten, benötigen Webfarmadministratoren weitere Tools, mit denen sie die erforderlichen Websitemetadaten im schreibgeschützten Modus direkt aus den Inhaltsdatenbanken extrahieren.
Zu den verfügbaren Optionen zählt unter anderem der Einsatz von SQL Server 2005 Reporting Services oder einer ähnlichen Berichterstattungslösung auf Unternehmensebene. Wie das Beispiel im Begleitmaterial zeigt, können Sie die erforderlichen Informationen auch mithilfe von SQL Server-SELECT-Abfragen erhalten.

Pav Cherny ist IT-Experte und Autor, der sich auf Microsoft-Technologien für die Zusammenarbeit und einheitliche Kommunikation spezialisiert. Seine Veröffentlichungen umfassen Whitepaper, Produkthandbücher und Bücher mit dem Schwerpunkt IT-Vorgänge und Systemverwaltung. Pav Cherny ist Vorsitzender der Biblioso Corporation, einem Unternehmen, das sich auf verwaltete Dokumentations- und Lokalisierungsdienste spezialisiert hat.


Windows PowerShell Es sieht gut aus
Don Jones

Häufig sollen mit Skripts ansprechend formatierte Dokumente erstellt werden, und ich werde oft gefragt, wie man beispielsweise Tabellen am besten erstellen kann. Es gibt hierfür zwei Möglichkeiten. Der erste Schritt besteht darin, ein Skript zu schreiben, das die Daten, die ich formatieren möchte, in Variablen mit den Namen
$data1, $data2 und $data3 speichert. Anschließend kann ich die Daten formatieren.

Die Textmethode
Im Web
Sie möchten sich die in diesem Monat im Windows PowerShell-Artikel erklärten Verfahren schnell demonstrieren lassen? Gehen Sie zu technetmagazine.com/video, um zu sehen, wie Don Jones diese Cmdlets umsetzt.

In der Regel gehen Programmierer bei dieser Aufgabe genauso vor, wie sie es bei anderen Sprachen wie VBScript, Perl, KiXtart oder einer anderen textorientierten Sprache tun würden. Vielleicht werden im ersten Schritt Spaltenüberschriften auf den Bildschirm geschrieben:
Write-Host "ColumnA'tColumnB'tColumnC"
Beachten Sie, dass das `t eine spezielle Escapesequenz in Windows PowerShellTM ist, die ein Tabstoppzeichen einfügt. Wenn ich jede Zeile meiner Tabelle ausschreiben will (meine Daten sind in $data1, $data2 und $data3), habe ich hierfür mehrere Möglichkeiten. Eine besteht darin, einfach die Variablen zu schreiben und mich darauf zu verlassen, dass die Shell Variable durch ihre Inhalte in doppelten Anführungszeichen ersetzt:
Write-Host "$data1't$data2't$data3"
Eine andere, etwas bessere Methode besteht darin, hierfür den –f-Operator zu verwenden. Bei dieser Methode wird die Formatierung von den Daten getrennt, wodurch die Codezeilen meiner Meinung nach leichter lesbar und besser verwaltbar werden.
Write-Host "{0}'t{1}'t{3}" –f $data1,$data2,$data3
Bei dieser Methode ergeben sich allerdings große Probleme. Zunächst einmal wird, wenn ich mich auf die festen Tabstopps im Konsolenfenster verlasse, die Formatierung an einigen Stellen sehr merkwürdig aussehen. Wenn beispielsweise eine Tabellenzeile 20 Zeichen in der ersten Spalte enthält, bringe ich damit die ganze Formatierung für diese Zeile durcheinander. Außerdem bin ich dadurch, dass ich diesen Text mittels Write-Host ausgebe, mehr oder weniger auf eine Konsolenanzeige beschränkt.
Es gibt keine einfache Möglichkeit, diese Ausgabe an eine Datei zu senden oder sie in andere Formate umzuwandeln, falls ich das jemals tun möchte. Was aber am wichtigsten ist: Bei diesem textbasierten Ansatz wird die inhärent objektbasierte Shell, in der ich arbeite, vollständig ignoriert, und ich nutze damit nicht die leistungsstarken Verfahren und Features, die Windows PowerShell bietet.

Die Windows PowerShell-Funktionsweise
Windows PowerShell ist eine objektorientierte Shell. Das bedeutet, dass Sie im Idealfall nur in Objekten arbeiten, die es der Shell ermöglichen, etwas bei Bedarf in Textanzeigen umzuwandeln. Aber wie erstellen Sie Objekte für zufällige Datenfragmente?
In meinem obigen Beispiel beginne ich damit, ein leeres benutzerdefiniertes Objekt zu erstellen und es in einer Variablen zu speichern:
$obj = New-Object PSObject
Hierdurch erhalte ich ein neues, leeres Objekt, mit dem ich arbeiten kann. Anschließend füge ich dem Objekt meine Daten in Form von Eigenschaften hinzu. Hierzu sende ich mein Objekt einfach zum Add-Member-Cmdlet. Ich füge eine NoteProperty hinzu, gebe der Eigenschaft einen Namen (es empfiehlt sich, als Eigenschaftsnamen die Spaltenüberschriften zu verwenden) und füge dann die Daten als Werte für die Eigenschaften ein:
$obj | Add-Member NotePropertyColumnA $data1
$obj | Add-Member NotePropertyColumnB $data2
$obj | Add-Member NotePropertyColumnC $data3
Jetzt gebe ich einfach dieses Objekt aus, und zwar nicht an die Konsole, sondern an die Pipeline:
Write-Output $obj
Ich kann dann diese Schritte für jede Tabellenzeile wiederholen, die ich ausgeben muss. Die folgende kurze Funktion akzeptiert eine Zeichenfolge und gibt eine Version in Groß- und Kleinbuchstaben sowie die ursprünglichen Zeichenfolge aus:
functionStringVersions {
param([string]$inputString)
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty Original($inputString)
  $obj | Add-Member NoteProperty Uppercase($inputString.ToUpper())
  $obj | Add-Member NoteProperty Lowercase($inputString.ToLower())
  Write-Output $obj
}
$strings = @("one","two","three")
foreach ($item in $strings) {
StringVersions $item
}
Ich fange mit einem Array von Zeichenfolgenvariablen an und sende diese nacheinander an die Funktion. Die Ausgabe der Funktion wird hierdurch in die Pipeline geschrieben.
Dieser Code könnte kompakter geschrieben werden, aber ich habe ihn extra so wie hier gezeigt geschrieben, weil hierdurch besser illustriert wird, was ich mit dem Code erreichen will. Das Ergebnis, das in Abbildung 1 zu sehen ist, ist eine perfekt formatierte Tabelle. Der Grund hierfür ist, dass die Shell bereits weiß, wie Objekte in einer Tabelle zu formatieren sind.
Abbildung 1 Windows PowerShell-Ausgabe in einer Tabelle
Abbildung 1 Windows PowerShell-Ausgabe in einer Tabelle (Zum Vergrößern auf das Bild klicken)
Wenn ein Objekt vier oder weniger Eigenschaften besitzt, wählt Windows PowerShell automatisch eine Tabelle aus. Ohne selbst hierfür etwas getan zu haben, habe ich jetzt eine schön formatierte Tabelle.

Das ist aber noch nicht alles.
Cmdlet des Monats: Get-Command
Bestimmt haben Sie schon einmal Get-Command oder seinen praktischen Alias (gcm) verwendet, um die Liste der verfügbaren Windows PowerShell-Cmdlets aufzurufen. Aber möglicherweise wissen Sie nicht, wie flexibel gcm wirklich ist. Wenn Sie zum Beispiel sehen möchten, was Windows PowerShell mit einem Dienst tun kann, führen Sie „gcm -noun service“ aus. Wenn Sie alle Windows PowerShell-Exportoptionen sehen möchten, versuchen Sie es mit „gcm -verb export“. Wenn Sie nur sehen wollen, welche Cmdlets von einem bestimmten Snap-In wie z. B. den PowerShell-Communityerweiterungen hinzugefügt wurden, versuchen Sie es mit „gcm -pssnapin pscx“. (Sie können „pscx“ durch einen beliebigen Snap-In-Namen ersetzen, um die Cmdlets des jeweiligen Snap-Ins zu sehen.)
Wie Sie sehen, ist Get-Command ein wichtiger Befehl, um den Funktionsumfang der Windows PowerShell vollständig nutzen zu können. Sie können sich auf diese Weise mit dem Funktionsumfang vertraut machen, ohne das Handbuch lesen zu müssen. Mit gcm lässt sich der Funktionsumfang zudem genauer erforschen als mit einem Befehl wie „Help *“. Die Help-Funktion listet nur verfügbare Hilfethemen auf. Cmdlets, die nicht zusammen mit einer Hilfe ausgeliefert wurden, tauchen nicht in der Hilfeliste auf, obwohl sie Ihnen zur Verfügung stehen, wenn Sie sie benötigen.

Der Vorteil dieser Methode geht weit über Tabellen hinaus. Wenn Sie mit Objekten arbeiten, bietet Windows PowerShell einen riesigen Funktionsumfang. Sie wollen Ihre Daten in eine CSV-Datei exportieren? Verwenden Sie Export-CSV. Sie bevorzugen eine HTML-Tabelle? Senden Sie Ihre Objekte an ConvertTo-HTML. Sie benötigen ein Listenformat? Senden Sie die Objekte an Format-List. Mit Objekten können Sie all die Funktionen nutzen, die Shell bereits kennt. Hier ist ein überarbeitetes Beispiel:
functionStringVersions {
  PROCESS {
   $obj = New-Object PSObject
   $obj | Add-Member NoteProperty Original($_)
   $obj | Add-Member NoteProperty Uppercase($_.ToUpper())
   $obj | Add-Member NoteProperty Lowercase($_.ToLower())
   Write-Output $obj
}
}
Dieses Mal habe ich die Funktion geändert, die die Pipelineeingabe akzeptiert (was immer besser ist, wenn Sie mit Objekten arbeiten) und die Objekte an die Pipeline ausgibt.
Der Code für diese Funktion befindet sich jetzt in einem PROCESS-Skriptblock. Das bedeutet, dass diese Funktion eine Pipelineeingabe akzeptiert und den PROCESS-Skriptblock einmal für jedes Objekt ausführt, das an die Pipeline gesendet wurde.
Innerhalb des PROCESS-Skriptblocks verweist die spezielle Variable $_ auf das das aktuelle Pipelineobjekt, das gerade verarbeitet wird. Das Praktische hierbei ist, dass ich jetzt einfach ein Zeichenfolgenarray an eine Pipeline senden kann:
@("one","two","three") | StringVersions
Ich erhalte eine Tabelle, weil die Funktion ihre Ausgabe an die Pipeline sendet. Am Ende der Pipeline weiß die Shell, dass sie ihr Formatierungssubsystem aufrufen muss, das entscheidet, eine Tabelle zu verwenden, weil die Objekte in der Pipeline weniger als fünf Eigenschaften haben (für mehr Eigenschaften verwendet die Shell standardmäßig eine Liste).
Aber ich muss mich nicht auf das Standardverhalten verlassen. Ich kann einfach die Objekte an ein anderes Cmdlet senden, um sie auf andere Weise zu verarbeiten:
@("one","two","three") | StringVersions | Format-List
@("one","two","three") | StringVersions | ConvertTo-HTML | Out-File "strings.html"
@("one","two","three") | StringVersions | Export-CSV "strings.csv"
@("one","two","three") | StringVersions | Select Uppercase,Lowercase -unique
Abbildung 2 zeigt das sich ergebende HTML aus dem zweiten Beispiel in einem Webbrowser. Durch die einfache Repräsentation meiner Ausgabedaten durch Objekte statt als einfachen Text erhalte ich jetzt vollständigen Zugang zu einer Vielzahl von Funktionen, die in die Shell integriert sind: viele verschiedene Formatierungslayouts, HTML-Konvertierung, Exportoptionen, Sortier-, Filter- und Gruppiermöglichkeiten und mehr.
Abbildung 2 Windows PowerShell-Datenausgabe im HTML-Format
Abbildung 2 Windows PowerShell-Datenausgabe im HTML-Format (Zum Vergrößern auf das Bild klicken)
Das alles sind sehr leistungsfähige Funktionen. Ich würde sogar so weit gehen zu behaupten, dass jedes von Ihnen geschriebene Skript ein Objekt als Ausgabe produzieren sollte, damit Sie diese Ausgabe auf so viele unterschiedliche Weisen wie möglich verwenden können, ohne hierzu eine einzige zusätzliche Codezeile schreiben zu müssen.

Don Jones ist Experte im Bereich administrative Windows-Automatisierung und Autor von Büchern wie Windows PowerShell: TFM und VBScript, WMI, and ADSI Unleashed. Sie können ihn über die Foren unter ScriptingAnswers.com erreichen.


Hey, Scripting Guy! Auch nicht so harte Arbeit hat ihren Lohn
Die Scripting Guys von Microsoft

Laden Sie den Code für diesen Artikel herunter: HeyScriptingGuy2008_06.exe (150KB)

Seit Hunderten von Jahren sind Menschen der Überzeugung, dass harte Arbeit Lohn an sich ist, dass ein Tag ehrliche Arbeit zu wahrer Befriedigung führt, dass nicht die Reise, sondern das Ziel wahres Glück bringt, dass ... Sie verstehen schon, worauf wir hinauswollen. Arbeiten Sie hart, ohne sich zu beklagen (denken Sie nur an das Aschenputtel), und irgendwann werden Sie Ihren gerechten Lohn erhalten.
Hinweis: Stimmt es wirklich, dass harte Arbeit nicht nur glücklicher macht, sondern dass Sie irgendwann für Ihre Bemühungen auch belohnt werden? Weshalb stellen Sie uns diese Frage?
Natürlich hatte das Aschenputtel Glück. Schließlich bieten sich alle möglichen Gelegenheiten für harte Arbeit, wenn man bei einer bösen Stiefmutter und boshaften Stiefschwestern lebt. Und wenn man dieses Glück nicht hat? Angenommen Sie leben nicht bei einer bösen Stiefmutter und boshaften Stiefschwestern. Wie können Sie dann lange, zermürbende, undankbare Tage mit harter Arbeit verbringen? Wie werden Sie jemals wahres Glück finden?
Also, wenn Sie fest entschlossen sind, Knochenarbeit zu leisten, sollten Sie sich laut Meinung der Scripting Guys am Schreiben eines Skripts versuchen, das Daten in einem schönen, ordentlichen Tabellenformat ausgibt, wie es die Ausgabe in Abbildung 1 zeigt.
Abbildung 1 Ausgabe im Tabellenformat
Abbildung 1 Ausgabe im Tabellenformat (Zum Vergrößern auf das Bild klicken)
Wie bereits erwähnt: das Aschenputtel hatte sehr viel Glück. Es durfte das Haus gründlich putzen und am Herd inmitten von Asche und Ruß sitzen, wenn es fertig war. Doch selbst das Aschenputtel hätte protestiert, wenn es ein Skript hätte schreiben müssen, das Daten im Tabellenformat anzeigen kann. Inmitten von Asche und Ruß zu sitzen ist eine Sache. Ein Skript zu schreiben, das Daten im Tabellenformat ausgibt, etwas ganz anderes.
Hinweis: Es sei denn, Sie müssen beim Schreiben Ihrer Skripts am Herd sitzen. Dann läuft es so ziemlich auf dasselbe hinaus.
Warum würde das Aschenputtel vor dieser Aufgabe zurückscheuen? Ganz einfach: sie ist viel zu schwierig. Die einzige Möglichkeit, Daten im Tabellenformat in VBScript anzuzeigen, besteht darin, etwas Ähnliches wie dies vorzunehmen:
  • Zuerst legen Sie die maximale Größe für jede Spalte fest. Der Anzeigename eines Diensts soll beispielsweise 52 Zeichen lang sein.
  • Davon ausgehend berechnen Sie die Anzahl der Zeichen in einem Datenelement. Der Anzeigename „Adobe LM Service“ beispielsweise hat 16 Zeichen.
  • Wenn der Anzeigename die 52-Zeichen-Grenze überschreitet, legen Sie die Anzahl von Zeichen fest, die am Ende der Zeichenfolge abgeschnitten werden müssen, damit sie in den zugewiesenen Raum passt. Wenn der Anzeigename 52 Zeichen nicht überschreitet, legen Sie fest, wie viele Leerstellen am Ende der Zeichenfolge hinzugefügt werden müssen, damit sie genau 52 Zeichen lang ist.
  • Wiederholen Sie das Ganze für den nächsten Datensatz. Und für den nächsten. Und so weiter.
Wenn Sie mit der Geschichte vom Aschenputtel vertraut sind, wissen Sie, dass möglicherweise die gute Fee unangemeldet vorbeikommt, eine Maus in einen Systemadministrator verwandelt (kein Kommentar dazu, wie einfach das sein könnte) und diese Maus dann dieses Skript für Sie schreibt. Aber Sie sollten sich lieber nicht darauf verlassen, dass dies geschieht. Wahrscheinlich müssen Sie es schon selbst tun,
wobei Sie wahrscheinlich der zufriedenste Mensch der Welt sind. Und auch der am härtesten arbeitende Mensch. Ohne Übertreibung.
Wahrscheinlich wird so mancher gewillt sein, auf ein wenig Befriedigung zu verzichten, wenn er dafür nicht ganz so schwer arbeiten muss. Wenn Sie zu diesen Menschen gehören, denken Sie wahrscheinlich: „Zum Glück gibt es ja die Scripting Guys. Sie werden mir zeigen, wie eine Maus in einen Systemadministrator verwandelt wird, und mir dann sagen, wie ich die Maus dazu bringen kann, meine Ausgabe als Tabelle zu formatieren.“ Leider haben wir keine guten Nachrichten für Sie: Die Scripting Guys haben absolut keine Ahnung, wie eine Maus in einen Systemadministrator verwandelt wird. (Obwohl wir einen Systemadministrator in eine Maus verwandeln können, wenn das für Sie irgendwie nützlich ist.) Wir wissen nicht, wie Sie irgend jemanden dazu bringen können, Skripts für Sie zu schreiben, ganz abgesehen von Skripts, die Daten im Tabellenformat ausgeben.
Aber das ist ok. Solange Sie Windows® XP oder Windows Server® 2003 ausführen (was bei vielen von Ihnen der Fall ist), brauchen Sie keine Maus, die Ihre Skripts für Sie schreibt. (Nein, tut uns Leid – es funktioniert leider nicht unter Windows Vista®.) Stattdessen können Sie es mit wenig Aufwand dank des Microsoft.CmdLib-Objekts selbst tun. Sehen Sie sich das Beispielskript in Abbildung 2 an.
Figure 2 Erstellen einer Tabellenanzeige
Dim arrResultsArray()
i = 0

Set objCmdLib = _
  CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = _
  WScript.Application

arrHeader = Array("Display Name", _
  "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" _
  & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery _
  ("Select * FROM Win32_Service")

For Each objService In colServices
  ReDim Preserve arrResultsArray(i)
  arrResultsArray(i) = _
  Array(objService.DisplayName, _
    objService.State,objService.StartMode)
  i = i + 1
Next
objCmdLib.ShowResults arrHeader, _
  arrResultsArray, arrMaxLength, _
  strFormat, blnPrintHeader, arrBlnHide
Falls Sie sich wundern: Microsoft.CmdLib ist ein COM-Objekt, das mit Windows XP und Windows Server 2003 geliefert wird. Dieses Objekt hat eine Reihe verschiedener Features. Um weitere Informationen zu erhalten, geben Sie „cmdlib.wsc /?“ in der Eingabeaufforderung ein und lesen die Kommentare in der auf dem Bildschirm angezeigten Skriptdatei. An dieser Stelle soll jedoch nur ein Feature von Microsoft.CmdLib behandelt werden: die Möglichkeit, Daten im Tabellenformat anzuzeigen.
Dies führt zu einer offensichtlichen Frage: Wie werden Daten im Tabellenformat angezeigt? Mal sehen, ob wir das herausfinden können. Wie Sie sehen, steht am Anfang des Beispielskripts eine Definition eines dynamischen Arrays mit der Bezeichnung arrResultsArray:
Dim arrResultsArray()
In einem typischen Skript werden Daten auf dem Bildschirm so schnell zurückgegeben, wie sie abgerufen werden. Doch es ist nicht zu erwarten, dass die Scripting Guys etwas auf normale Art und Weise tun. In diesem Skript werden die Daten nicht zurückgegeben, sobald sie abgerufen werden. Stattdessen werden alle zurückgegebenen Daten in einem Array gespeichert und mithilfe von Microsoft.CmdLib formatiert und angezeigt.
Anders ausgedrückt: Dies ist der Grund, warum zunächst ein dynamisches Array erstellt wird (also ein Array, dessen Größe im Verlauf des Skripts geändert werden kann). Nach dem Definieren des Arrays legen Sie den Wert einer Gegenvariablen mit der Bezeichnung „i“ auf 0 fest. Sie verwenden diese Variable, um die aktuelle Größe des Arrays zu verfolgen.
Falls Sie sich wundern: Der Wert von „i“ wurde auf 0 festgelegt, weil das erste Element in einem Array immer die Indexziffer 0 erhält. Wenn Sie dem Array dann das erste Element hinzufügen, fügen Sie also Element 0 statt Element 1 hinzu.
Als Nächstes müssen Sie die Instanz des Microsoft.CmdLib-Objekts initialisieren. Dies erfolgt mithilfe dieser beiden Codezeilen:
Set objCmdLib = _
CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = WScript.Application
Das führt zu diesem kleinen Codeblock:
arrHeader = Array("Display Name", "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)
Hier werden ein paar Parameter zum Konfigurieren der Ausgabe eingerichtet. In der ersten Zeile weisen Sie einem Array mit der Bezeichnung „arrHeader“ Werte zu. Wie zu erwarten, sind dies die Überschriften für die einzelnen Spalten der Ausgabetabelle. Für dieses Beispielskript rufen Sie Informationen zu den Diensten ab, die auf einem Computer ausgeführt werden. Anschließend zeigen Sie die Werte der Eigenschaften „DisplayName“, „State“ und „Start Mode“ der einzelnen Dienste an.
Es überrascht nicht weiter, dass dem Array die Spaltennamen „Display Name“, „State“ und „Start Mode“ zugewiesen werden (obwohl sie auch A, B und C, Larry, Moe und Curly oder irgendetwas anderes genannt werden könnten, da die Spaltennamen nicht identisch mit den Eigenschaftsnamen sein müssen).
Hinweis: Es gibt (auch in Bezug auf die Namen der Stiefschwestern) viele Variationen des Märchens vom Aschenputtel. In der Disney-Version „Cinderella“ heißen die Stiefschwestern Drizzella und Anastasia, und ganz zufällig lauten der erste und zweite Vorname unseres Scripting Editors genauso!
In der zweiten Codezeile weisen Sie einem anderen Array mit der Bezeichnung arrMaxLength Werte zu. Dieses Array nimmt die Größe jeder Spalte in der Tabelle auf. In unserer Ausgabe sollen Spalte 1 (der Dienstanzeigename) 52 Zeichen zugeordnet werden. Dem Dienstzustand und dem Startmodus sollen dann jeweils 12 Zeichen zugeordnet werden. (Microsoft.CmdLib fügt automatisch eine Leerstelle zwischen den Spalten ein.) Wenn die Spaltengrößen 52, 12 und 12 Zeichen betragen sollen (was der Fall ist), verwenden Sie den folgenden Code:
arrMaxLength = Array(52, 12, 12)
Die dritte Zeile gibt das Ausgabeformat für die Daten an. Die Daten sollen als Tabelle angezeigt werden. Daher wird der Wert „strFormat“ (die Variable, die den Ausgabetyp enthält) auf „Table“ festgelegt. Angenommen die Daten sollen stattdessen als eine durch Komma getrennte Werteliste angezeigt werden. In diesem Fall würde das Format so auf CSV festgelegt:
strFormat = "CSV"
Dabei erhalten Sie eine Ausgabe ähnlich der folgenden:
"Display Name","State","Start Mode"
"Adobe LM Service","Stopped","Manual"
"Adobe Active File Monitor V4","Stopped","Manual"
"Alerter","Stopped","Manual"
"Application Layer Gateway Service","Running","Manual"
"Apple Mobile Device","Running","Auto"
"Application Management","Stopped","Manual"
Beachten Sie, dass Microsoft.CmdLib nicht nur Kommas zwischen die einzelnen Elemente, sondern die einzelnen Werte auch in doppelte Anführungszeichen gesetzt hat. Dieses Feature ist nützlicher, als Sie vielleicht zuerst denken. Schließlich müssten Sie bei manueller Erstellung Code verwenden, der folgendermaßen aussieht:
Wscript.Echo Chr(34) & objService.DisplayName & Chr(34) & "," & Chr(34) & objService.State & Chr(34) & "," & Chr(34) & objService.StartMode & Chr(34)
Oje.
Was ist los? Sie mögen keine Tabellen, aber auch nicht das CSV-Format? Nun, in diesem Fall könnte das Format auf „List“ festgelegt werden, sodass Sie eine Ausgabe ähnlich der folgenden erhalten:
Display Name: Adobe LM Service
State:        Stopped
Start Mode:   Manual
Display Name: Adobe Active File Monitor V4
State:        Stopped
Start Mode:   Manual
Doch wir schweifen vom Thema ab. (Was wir ja hin und wieder gerne tun.) Nach Definieren des Ausgabeformats legen Sie den Wert einer Variablen mit dem Namen „blnPrintHeader“ auf „True“ fest:
blnPrintHeader = True
Sie verwenden „blnPrintHeader“, damit Microsoft.CmdLib die Spaltenüberschriften druckt. Was passiert aber, wenn die Spaltenüberschriften nicht gedruckt werden sollen? Kein Problem – in diesem Fall wird „blnPrintHeader“ auf „False“ festgelegt:
blnPrintHeader = False
Schließlich liegt diese Codezeile vor:
arrBlnHide = Array(False, False, False)
Wenn Ihre Daten nun angezeigt werden sollen, bietet Microsoft.CmdLib die Option, eine Spalte ein- oder auszublenden. Zum Ausblenden einer Spalte (also zum Unterdrücken von Daten für eine bestimmte Eigenschaft), wird der Wert für diese Eigenschaft auf „True“ festgelegt. Zum Einblenden einer Spalte, wird der Wert auf „False“ festgelegt.
In dieser Ausgabe werden die Werte für die Eigenschaften „DisplayName“, „State“ und „StartMode“ angezeigt, und zwar in dieser Reihenfolge. Daher werden in diesem Array die Werte „False“, „False“ und „False“ verwendet Wie gehen Sie vor, wenn DisplayName eingeblendet, State ausgeblendet und StartMode eingeblendet werden soll? In diesem Fall verwenden Sie diese Codezeile:
arrBlnHide = Array(False, True, False)
„False“ wird also zum Einblenden einer Spalte und „True“ zum Ausblenden verwendet.
Jetzt sind die Scripting Guys bereit, einige Daten auszugeben, d. h., sie wären bereit dazu, wenn sie Daten hätten. (Haben die Scripting Guys je ein Skript geschrieben, das keine Daten ausgegeben hat, dann übermäßig viel Zeit zum Debuggen dieses Skripts aufgewendet, nur um dann festzustellen, dass ursprünglich überhaupt keine Daten abgerufen wurden? Selbstverständlich nicht – wie kommen Sie nur auf diese Idee?)
Der nächste Schritt besteht also darin, eine Bindung mit dem Windows-Verwaltungsinstrumentationsdienst (Windows Management Instrumentation, WMI) auf dem lokalen Computer herzustellen und dann die ExecQuery-Methode zum Abrufen von Informationen zu allen auf diesem Computer installierten Diensten zu verwenden.
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery ("Select * FROM Win32_Service")
Wir sollten wahrscheinlich erwähnen, dass Sie hier nicht darauf beschränkt sind, mit WMI-Daten zu arbeiten. Wie zu erwarten ist, kann Microsoft.CmdLib mit beliebigen Daten arbeiten. WMI ist nur eine praktische Möglichkeit, alle möglichen Daten abzurufen.
Wenn eine Sammlung dienstbezogener Daten vorliegt, wird eine „For Each“-Schleife eingerichtet, die alle Dienste in der Sammlung durchläuft. Doch statt die Eigenschaftswerte für jeden Dienst wiederzugeben, wird dieser Code ausgeführt:
ReDim Preserve arrResultsArray(i)
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
i = i + 1
Was wird mit diesem Codeblock gemacht? In Zeile 1 wird die Größe des Arrays mithilfe des Befehls „ReDim Preserve“ geändert, wobei nicht nur die Größe des Arrays geändert wird, sondern auch vorhandene Daten im Array beibehalten werden. (Ohne das Schlüsselwort „Preserve“ würde die Größe des Arrays geändert, aber derzeit im Array vorhandene Daten würden gelöscht.)
Welche Größe soll das Array erhalten? In der ersten Schleife wird ein Array der Größe 0 erstellt, d. h. ein Array, das ein Element enthält. Wie lässt sich aber mit Sicherheit sagen, dass ein Array der Größe 0 erstellt wird? Weil die Gegenvariable „i“ verwendet wird, die 0 entspricht.
Wenn die Variable „i“ verwendet wird, um die Größe des Arrays zu repräsentieren, bedeutet dies dann nicht, dass die Größe immer auf 0 festgelegt wird? Das wäre tatsächlich der Fall, doch jedes Mal, wenn die Schleife durchlaufen wird, erhöht sich der Wert „i“ um 1. Wie Sie sehen, geschieht genau das in Zeile 3 des Codeblocks.
Jetzt müssen Sie sich nur noch um eine Codezeile kümmern:
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
Hier werden einfach die Eigenschaftswerte, die von Interesse sind (DisplayName, State und StartMode) dem Array „arrResultsArray“ hinzugefügt. Beachten Sie, dass die Eigenschaftswerte nicht einzeln, sondern als ein Array von Werten hinzugefügt werden. Zugegeben, das ist ein wenig ungewöhnlich: Es bedeutet, dass jedes Element im Array „arrResultsArray“ ein anderes Array ist, aber so funktioniert Microsoft.CmdLib nun mal.
Das könnte natürlich dazu führen, dass Sie sich wieder Gedanken machen. „Ein Array von Arrays? Wie um alles in der Welt soll ich auf all die einzelnen Werte in einem Array voller Arrays zuzugreifen können?“ Geraten Sie nicht in Panik. Es ist ganz einfach: Microsoft.CmdLib erledigt dies alles für Sie.
Hinweis: Leider ist das Zugreifen auf alle einzelnen Werte in einem Array von Arrays so ziemlich das Einzige, das Microsoft.CmdLib für Sie tun kann. Das Putzen und Geschirrspülen für die böse Stiefmutter sowie das Schneidern der Kleider für die boshaften Stiefschwestern werden für die nächste Version des Objekts in Betracht gezogen.
Tatsächlich können Sie die Daten (im ordentlichen Tabellenformat) ausgeben, indem einfach die ShowResults-Methode aufgerufen wird und der Methode alle zuvor im Skript konfigurierten Arrays und Variablen übergeben werden:
objCmdLib.ShowResults arrHeader, arrResultsArray, arrMaxLength, strFormat, blnPrintHeader, arrBlnHide
Wie sieht das Ergebnis dann aus? Es sieht genau wie die ordentlich formatierte Ausgabe aus, die wir uns beim Betrachten von Abbildung 1 erhofft hatten.
Nicht schlecht, oder? Sie erhalten eine ordentliche Ausgabe und mussten fast nichts dazu tun. (Ihr nächstes Skript wird sogar noch einfacher, da Sie nur einige kleine Änderungen an diesem ersten Skript vornehmen müssen.)
Zugegebenermaßen bietet Ihnen das nicht dieselbe Befriedigung, die das Aschenputtel aufgrund seiner Schufterei tagein und tagaus hatte, nur damit es Skript in einer Tabelle ausgeben konnte. Sie werden wahrscheinlich auch keinen Prinzen heiraten dürfen, denn das ist nun wirklich nicht Teil der Abmachung. Aber das scheint ein geringer Preis in Anbetracht der ordentlichen Ausgabe mithilfe eines VBScript-Skripts, besonders dann, wenn Sie sich vor Augen führen, wie Prinzen heute so sind.
Und wer weiß: vielleicht bekommen Sie Ihren Prinzen trotzdem. Schließlich brauchen selbst königliche Personen Informationen über all die Dienste, die auf ihren Computern installiert sind.

Der Scripting Perplexer von Dr. Scripto
Die monatliche Herausforderung, die nicht nur Ihr Talent zum Rätsellösen testet, sondern auch Ihre Skriptingfähigkeiten.

Juni 2008: PowerShell-Pfad
In jedem dieser Rätsel verbinden Sie die Buchstaben waagerecht, senkrecht und diagonal, um den Namen eines Windows PowerShell-Cmdlet zu erhalten. Jeder Buchstabe wird nur ein Mal verwendet. Hier ist ein Beispiel:
Das in diesem Rätsel erstellte Cmdlet heißt New-Alias. Jetzt sind Sie an der Reihe. Hier sind noch drei Rätsel:

ANSWER:
Der Scripting Perplexer von Dr. Scripto
Antworten: PowerShell-Pfad, Juni 2008

Read-Host

Set-AuthenticodeSignature

Die Scripting Guys von Microsoft arbeiten für Microsoft (oder sind zumindest dort angestellt). Wenn sie nicht gerade ihrem Hobby, dem Baseball (oder verschiedenen anderen Aktivitäten) nachgehen, betreiben sie das TechNet-Skriptcenter. Besuchen Sie es unter www.scriptingguys.com.


Die Desktopdateien Sicherheit und Einhaltung von Bestimmungen
Wes Miller

Als IT-Experte stehen Sie möglicherweise Zielen gegenüber, die sich ergänzen sollten, aber stattdessen oft miteinander konkurrieren. Sicherheit und die Einhaltung von Bestimmungen sind zwei dieser Ziele einer Organisation, die gemeinsam zu besseren Ergebnissen führen sollten. Leider ist das aber in der Regel nicht der Fall. Ich möchte Ihnen in diesem Artikel
einen Überblick darüber geben, warum Sicherheit nicht immer bedeutet, dass die von Ihnen geforderten Initiativen berücksichtig werden, und warum die Einhaltung von Bestimmungen oftmals bedeutet, dass es keine Sicherheit gibt oder dass die Sicherheit nicht so hoch ist, wie sie sein könnte, wenn die Einhaltung von Bestimmungen wirklich gleichbedeutend mit Sicherheit wäre.

Sicherheit ist keine Option zum Aktivieren
SDL-Ressourcen
  • The Security Development Lifecycle von Michael Howard und Steve Lipner (Microsoft Press, 2006)
  • Der Blog zum Sicherheitsentwicklungszyklus
  • Ein Einblick in den Sicherheitsentwicklungszyklus bei Microsoft
  • Sicherheitsentwicklercenter
  • Der Trustworthy Computing-Sicherheitsentwicklungszyklus

Die Einhaltung von Bestimmungen ist in der Regel verbunden mit Anforderungen (Personen, Prozess, Infrastruktur, Technologie usw.), die einer Organisation, einer Branche, einem Unternehmen oder einem Produkt von außen auferlegt werden. Manchmal geht es bei der Einhaltung von Bestimmungen um Standards, die eine Branche (wie z. B. bei Datensicherheitsstandards der Kreditkartenbranche) selbst eingeführt hat. Im Idealfall sind dies Initiativen, die (zumindest zu einem gewissen Grad) bereits auf die Arbeitsweise Ihrer Organisation ausgerichtet sind. Wenn sich ein Standard durchsetzt, werden Sie ihn nicht ignorieren können, sofern Sie weiterhin im Geschäft bleiben wollen. Letztendlich müssen Sie den Standard auch bei sich implementieren und das Beste daraus machen.
Es gibt eine andere Art der Einhaltung von Bestimmungen, die meist problematischer ist. Ich beziehe mich hier auf Initiativen der US-Regierung wie z. B. den Health Insurance Portability and Accountability Act (HIPAA) und Sarbanes-Oxley, bei denen eine Implementierung und der Zeitpunkt dafür selten frei wählbar sind.
Der wichtige Punkt bei der Einhaltung gesetzlicher Richtlinien ist, dass dabei oftmals ein Top-Down-Ansatz zum Einsatz kommt. In der Regel gibt es eine Schablone, die die Initiative definiert, und Sie müssen sich Ihre Produkte und Prozesse anschauen und einen Weg finden, wie Sie sie in diese Schablone einpassen können. Sie müssen sich zu jedem Zeitpunkt nicht nur über den Zweck der Einhaltungsinitiative im Klaren sein, sondern auch (was vielleicht noch wichtiger ist) über die eventuellen rechtlichen oder finanziellen Konsequenzen, wenn Sie die Initiative nicht oder nicht richtig einhalten.
Auch wenn wir dem Zweck vieler Einhaltungsinitiativen zustimmen, ist eine Implementierung oft schwierig und erreicht u. U. nicht das gewünschte Ziel. Außerdem sind viele leider wirkungslos (d. h. es gibt keine direkten rechtlichen oder finanziellen Konsequenzen, die bei einer Nichterfüllung auferlegt werden können).
Als Patient kann ich den Nettonutzen von HIPAA für mich nicht vollständig beschreiben. Was ich Ihnen aber sagen kann, ist, dass ich bei einem Arztbesuch viel mehr Formulare ausfüllen muss. Aber noch schlimmer sind vielleicht die unbeabsichtigten Konsequenzen. Haben Sie schon einmal versucht, Ihren Arzt zu bitten, wichtige medizinische Informationen an einen anderen Arzt weiterzuleiten? Wenn hierfür keine schriftliche Erlaubnis vorliegt, passiert gar nichts, egal, wie dringend die Informationen benötigt werden.
Was ich damit sagen will, ist, dass einige Einhaltungsinitiativen bürokratische Aktionen ohne tiefern Sinn darstellen. Sie entwickeln oder ändern Ihren Prozess oder Ihr Produkt in diesem Fall nur, um die Initiative zu erfüllen. Ich frage mich in diesen Situationen oft, ob das überhaupt Sinn macht.
Sicherheit ist dagegen eine Bottom-Up-Initiative, wenn sie richtig angegangen wird. Ob Sie nun ein Softwareprodukt oder die Architektur für das neue Netzwerk Ihrer Organisation entwickeln: Vergessen Sie nie das Grundprinzip „zweimal messen, einmal schneiden“. Wenn Sie beispielsweise Produktarchitektur entwickeln, beschreiben Sie zunächst auch Kommunikation, Lokalisierung, Versionen und so weiter. Sie sollten dabei aber auch die Sicherheitselemente beschreiben, die vom ersten Tag an in die Anwendung integriert werden müssen (und Sie sollten diese Elemente während der Entwicklung im Auge behalten und optimieren).
Wenn Sie mit Anwendungen oder Architekturen arbeiten, die nicht von Ihnen entwickelt wurden (das ist sicherlich bei den meisten von Ihnen der Fall), ist es ebenso wichtig, eine detaillierte Sicherheitsprüfung durchzuführen, die ich oft in dieser Rubrik erwähne. Wenn Sie nicht verstehen, wie etwas funktioniert, wie können Sie dann wissen, wie sicher etwas ist? Mehr zum Microsoft®-Sicherheitsentwicklungszyklus (Security Development Lifecycle, SDL) finden Sie in der Randleiste unter „SDL-Ressourcen“.

Das große Ganze
Ich erinnere mich noch daran, dass mir am Anfang einmal jemand gesagt hat, dass Sicherheit nicht einfach mit der Implementierung von Verschlüsselung, Zugriffssteuerungslisten oder TLS oder einer Public Key-Infrastruktur (PKI) gleichzusetzen ist. Bei echter Sicherheit geht es darum, das große Ganze im Auge zu haben und zu verstehen: Man muss verstehen, warum eine Version eines Protokolls nicht mehr verwendet wird oder sogar nie unterstützt wurde, warum dieses neue Sicherheitselement vor Man-in-the-Middle-Angriffen schützt, weshalb Ihre Implementierung für Produktversion 2 viel sicherer als die für Version 1 ist, selbst wenn Version 1 viel schneller war. Man muss auch verstehen, wie die einzelnen Teile Ihrer Infrastruktur zusammenpassen.
Einhaltung von Bestimmungen dagegen bedeutet, sich Ihre Technologie vorzunehmen und sicherzustellen, dass die von Ihnen entwickelte Infrastruktur bestimmte Kriterien erfüllt. Einige Initiativen wie z. B. die Datensicherheitsstandards der Kreditkartenbranche oder Bestimmungen zur Sicherheit elektrischer Geräte sind gut gemeint und führen vielleicht zu echten Sicherheitsänderungen. Aber letztendlich verlieren Sicherheitsinitiativen bei dem Sammelsurium an „Einhaltungsinitiativen“, die Sie mit Ihren begrenzten Ressourcen bei Ihren eigenen spezifischen Projekten berücksichtigen müssen, an Boden.
Sicherheit ist schon seit langem das Stiefkind der Softwareentwicklung. Bestimmt haben viele von Ihnen in Organisationen gearbeitet, in denen Sicherheit etwas war, „um das man sich später kümmern würde“. Nun ja, Einhaltungsinitiativen werden hierbleiben, weil die Philosophie, dass Sicherheit warten kann, nicht funktioniert und nie funktioniert hat.

Gut genug
Ich habe vor kurzem die Stelle gewechselt. Ich arbeite jetzt für ein Startupunternehmen hier in Austin, Texas, das eine Anwendungswhitelisting-Technologie ähnlich der Technologie entwickelt, die wir bei Winternals mit unserem Protection Manager entwickelt haben. Was ich dabei sehr interessant finde, ist, mit Kunden darüber zu reden, für wie sicher sie ihre aktuellen Technologien halten bzw. wie sicher die von ihnen verwendete Technologiesuite ihre Infrastruktur ihrer Meinung nach macht. Es ist zwar sehr wahrscheinlich, dass die meisten Technologien sicher sind und in ihnen keine Sicherheitslücken klaffen, aber der Kommentar, den ich oft zu hören bekomme und bei dem mir immer ein Schauer über den Rücken läuft, ist, dass ein System „sicher genug“ ist.
Einhaltungsinitiativen sind merkwürdig: Sie können sie erfüllen oder nicht. Die Verantwortung tragen Sie. Die Kosten für die Nichterfüllung einer Initiative sind meist eine Geldstrafe, eine Vertragsstrafe oder der Ausschluss aus einer Organisation. Oftmals reicht es nicht, nur sicherzustellen, dass sich etwas wirklich ändert.
Bei behördlichen Initiativen begegne ich regelmäßig der Haltung „gut genug für den Prüfer“ oder der Bereitwilligkeit, ohne ein Einhaltungsframework zu arbeiten, weil die entsprechende Gesetzgebung (wie z. B. HIPAA) die Bestimmung nicht richtig durchsetzt, was bedeutet, dass es viel billiger ist, keine entsprechenden Maßnahmen zu implementieren und dafür spätere potenzielle Folgen in Kauf zu nehmen.
Sicherheit bewegt sich oft in die gleiche Richtung, ist aber meiner Meinung nach konkreter. Wenn Sie als Entwickler oder Implementierer Ihrer Geschäftsführung sagen, dass das Produkt am Markt potenziell mehr Sicherheitsrisiken ausgesetzt sein kann, wenn ein bestimmter Punkt nicht in die Spezifikation aufgenommen wird, können Sie zumindest später, wenn das Produkt auf dem Markt ist oder Sie es bereitgestellt haben, sagen: „Darauf habe ich von Anfang an hingewiesen.“ Meiner Erfahrung nach werden Einhaltungsinitiativen oft zu hastig und mit dem kleinstmöglichen Budget umgesetzt. Das Ziel hierbei ist, nur die Mindestanforderungen der Initiative zu erfüllen und damit vielleicht die Initiative so wie sie auf dem Papier steht zu erfüllen, was aber meiner Meinung nach nicht dem Geist der Initiative entspricht.

Analysieren Ihrer Situation
Ressourcen zur Sicherheit und zur Einhaltung von Bestimmungen
  • Leitfaden zu Sicherheits- und Einhaltungslösungen
  • Sicherheitsleitfaden
  • Planungsleitfaden für die Einhaltung der Datensicherheitsstandards der Kreditkartenbranche
  • Einhaltung gesetzlicher Vorschriften und Sicherheitsupdates
  • Gewährleisten der Einhaltung von Bestimmungen
  • Office for Civil Rights – HIPAA
  • PCI Security Standards Council
  • North American Electric Reliability Council

Es ist wahrscheinlich idealistisch, wenn ich Ihnen sage, dass Sie Ihr Produkt und Ihre Organisation so sicher wie möglich machen sollten, aber die Realität ist, dass die meisten Einhaltungsinitiativen einen Kompromiss infolge schlechter Entwicklungsarbeit oder noch häufiger aufgrund von Bequemlichkeit darstellen. Wir leben in einer Welt, in der „gut genug“ leider gut genug ist. In der Welt der Sicherheit ist „gut genug“ allerdings selten eine weise Entscheidung. Wir, die IT-Experten der Welt, nehmen uns vielleicht Einhaltungsinitiativen zu Herzen und versuchen, sie sowohl nach dem Wortlaut als auch ihrem Geiste nach umzusetzen, und müssen gleichzeitig dafür sorgen, dass die von uns eingerichtete Infrastruktur nicht nur so sicher ist, wie sie sein darf, sondern so sicher, wie sie sein sollte. Anders ausgedrückt: Erfüllen Sie Richtlinien durch echte Sicherheit, nicht nur dadurch, dass Sie die Initiative erfüllen.
Es ist hierbei wichtig, einen Schritt zurückzutreten und sich die Technologie anzusehen, die Sie entwickeln, egal, ob es sich hierbei um kommerzielle Software oder um eine Technologiesuite handelt, die Sie in ein größeres System integrieren möchten. Ich kann gar nicht oft genug betonen, wie wichtig es ist, die einzelnen Komponenten des Systems zu verstehen, wie sie alle zusammenarbeiten und welchen größeren Risiken Ihr System ausgesetzt ist.
In Abhängigkeit von der Branche, in der Sie arbeiten, spielen bei Ihrer Arbeit wahrscheinlich unterschiedliche Einhaltungsinitiativen eine Rolle. Eventuell begegnen Sie ihnen tagtäglich oder nur, wenn Sie neue Projekte oder Technologien entwickeln. Vielleicht sind sie nur Teil Ihrer Arbeit, wenn entsprechende Überprüfungen bevorstehen. Egal. Ich bin der Meinung, dass Einhaltungsinitiativen nicht ignoriert werden sollten, aber ich möchte Sie auffordern, den Status Quo in Frage zu stellen und statt nur auf das Ziel hinzuarbeiten, die Ihnen zugewiesenen Einhaltungsinitiativen zu erfüllen, eine vollständige Sicherheitsprüfung durchzuführen, um Ihre Technologie richtig zu verstehen, und die Technologie zum gleichen Zeitpunkt wie Ihre Einhaltungsprüfung zu modellieren.

Was haben Sie zu verlieren?
Letztendlich sind die Strafen für die Nichterfüllung einer Einhaltungsinitiative nicht hundertprozentig klar. Wenn Sie eine Initiative nicht einhalten, setzen Sie sich genau dem Risiko aus, vor dem die Initiative Sie schützen soll. Die Konsequenzen erscheinen vielleicht vage und nicht akut, sie sind aber real. Es handelt sich bei ihnen vielleicht auch nicht um persönliche Konsequenzen. Seien Sie pragmatisch, aber denken Sie immer auch an den schlimmsten Fall.
Wenn Sie einen Prozess oder ein Produkt vom Standpunkt der Sicherheit aus betrachten, sollte die Bedrohung offensichtlich sein und, was noch wichtiger ist, Sie sollten sofort die potenziellen Kosten sehen, die entstehen können, wenn die Sicherheitslücke nicht geschlossen wird.
Viele Personen, mit denen ich über dieses Thema gesprochen habe, haben mir gesagt, dass Einhaltungsinitiativen manchmal unter den Teppich gekehrt werden, weil sie oft ziemlich viel Raum für Interpretationen lassen. Nachdem Sie eine Sicherheitsprüfung durchgeführt haben, dürfte dies aber nicht mehr der Fall sein. Die unmittelbaren Sicherheitslücken müssten deutlich sichtbar sein. Wenn sie es nicht sind, sollten Sie sich vielleicht noch einmal überlegen, wen Sie in Ihre Sicherheitsprüfungen involvieren. Vielleicht fehlen wichtige Teammitglieder, die helfen können, die eigentlichen Probleme in Ihrer Lösung zu finden.

Wenig Erfolg
Im letzten Jahr habe ich zum Thema Sicherheit den Beitrag „So behalten Sie Ihre Daten“ (technet.microsoft.com/magazine/cc162325) geschrieben. Seitdem ist ein Jahr vergangen, mehr Systeme sind beschädigt worden, mehr unverschlüsselte Laptops sind verloren gegangen und mehr persönliche Informationen sind in fragwürdige Hände gefallen. Es ist schwer zu sagen, ob überhaupt Fortschritte gemacht wurden. Warum befinden wir uns immer noch in dieser Situation? Projekte werden oft nicht innerhalb des vorgegebenen Zeitrahmens erledigt, die Projektbudgets sind zu klein, die Ressourcen sind überlastet, und es wird versucht, zu viele Features in einem zu engen Zeitrahmen zu liefern.
Derartige Situationen führen leider dazu, dass nur die minimal notwendige Arbeit erledigt wird. Das ist sicher nicht der richtige Weg, um dafür zu sorgen, dass eine Lösung sicher ist und die Bestimmungen erfüllt und außerdem nicht verhindert, dass das Projekt innerhalb des festgelegten Zeitrahmens und des Budgets abgeschlossen wird.
Ich persönlich bin folgender Meinung:
  1. Sie sollten keine Lösung entwickeln, wenn Sie nicht bereit sind, sie zu sichern.
  2. Jedes Mal, wenn Sie neue Features hinzufügen, müssen Sie zuerst die Sicherheitselemente entwickeln.
  3. Wenn Ihre Organisation nicht bereit ist, Sicherheit als einen Schritt in Ihren Entwicklungsprozess einzubinden, sollten Sie die Gesamtziele Ihres Unternehmens oder Ihrer Organisation hinterfragen.
Organisationen verfügen zunehmend über Kunden- oder Partnerdaten, für deren Datenschutz sie verantwortlich sind. Leider leben wir in einer Welt, in der Sicherheit zu oft nicht selbstverständlich ist und Mitarbeiter es oft nicht wagen, die Sicherheitsrichtlinien ihrer Organisation zu hinterfragen.
Viel zu häufig wird das Thema Sicherheit erst angegangen, nachdem persönliche Daten von Kunden, Studenten, Patienten und Mitarbeitern gestohlen wurden bzw. nachdem das Unternehmen oder die Organisation finanzielle Verluste erlitten hat. Die Nichteinhaltung von Bestimmungen wird dabei gar nicht erwähnt.
Wir müssen alle zu viel, oftmals für zu wenig Geld und gewöhnlich in einer zu kurzen Zeit erledigen. Als IT-Experten sind wir aber dafür verantwortlich zu hinterfragen, warum Sicherheit nicht den Schwerpunkt bildet und warum die Geschäftsführung nur dann über Sicherheit nachdenkt, wenn es Einhaltungsinitiativen gibt oder, was wahrscheinlicher ist, wenn eine Sicherheitsverletzung mit realen oder potenziellen rechtlichen Konsequenzen eingetreten ist (was die Organisation in eine peinliche Lage bringen oder sogar gefährden könnte).

Nehmen Sie meine Aufforderung an
Mein Hauptanliegen ist, Sie aufzufordern, den Status Quo zu hinterfragen. Wenn Sie damit beauftragt werden, nur die Einhaltungsziele zu erfüllen, sorgen Sie dafür, dass Sie nicht nur Zeit verschwenden, um das Sicherheitskonzept von jemand anderem zu erfüllen. Ihr Ziel muss darin bestehen, das System zu sichern und dabei den Prozess oder Ihre Infrastruktur so zu gestalten, dass die Einhaltungsinitiative erfüllt wird. Weitere Informationen zu diesem Thema finden Sie in der Randleiste „Ressourcen zur Sicherheit und zur Einhaltung von Bestimmungen“.
Um es auf den Punkt zu bringen: Denken Sie daran, dass Einhaltung von Bestimmungen allein oft nicht reicht, um ein System wirklich sicher zu machen. Wenn dagegen Sicherheit richtig implementiert und instrumentiert wird, sind Sie oftmals schon auf dem richtigen Weg, die Bestimmungen einzuhalten.

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


Führung eines IT-Unternehmens 10 Wege, um eine Führungsperson im Bereich Umweltfragen zu werden
Michael Walsh and Eliza Walsh

Jedes Unternehmen scheint heutzutage über seinen Beitrag zum Umweltschutz zu sprechen. IT kann bei diesen Anstrengungen eine wichtige Rolle spielen und eine großartige Gelegenheit für Sie darstellen, den Wandel voranzutreiben und Thought Leader in Ihrem Unternehmen und in der Branche zu werden. Doch wo fangen Sie an? Hier sind 10 Wege, wie Sie eine effektive Leitfigur für Initiativen im Bereich Umwelt und Nachhaltigkeit werden.
Machen Sie sich mit den Problemen vertraut
Der erste Schritt besteht darin, eine breitgefächerte und tief gehende Fachkenntnis in Fragen der Umweltverträglichkeit und Computernutzung zu entwickeln. Als IT-Experte sollten Sie zunächst ein gutes Verständnis über die Möglichkeiten haben, wie die durch die Computernutzung entstehenden Umweltbelastungen verringert werden können. Dazu gehören z. B. die Energieverwaltung, Hardwarekonsolidierung und Abfallbeseitigung.
Als leitender Umweltbeauftragter müssen Sie auch eine Vorstellung davon haben, wie Software und Hardware dazu beitragen können, die Auswirkungen der Vorgänge über die IT-Abteilung hinaus einzugrenzen. Dies kann dazu führen, dass Sie eng mit Personalmanagern, Rechtsanwälten und Geschäftsführern arbeiten, um Richtlinien zu definieren, die auf die Gesamtumweltauswirkungen des Unternehmens zugeschnitten sind. Dies kann alles Mögliche beinhalten, angefangen bei Richtlinien für Geschäftsreisen bis zu globalen Regeln für den Beitrag zum CO2-Ausstoß.
Individuen innerhalb und außerhalb Ihres Unternehmens werden erwarten, dass Sie die entsprechenden Fachkenntnisse über die Umwelt, das Unternehmen und die Branchen haben, in denen Ihr Unternehmen operiert. Deshalb müssen Sie Ihr Verständnis über die Umweltverträglichkeit und die nachhaltige Computernutzung sowie die einmaligen kurz- und langfristigen Anforderungen Ihres Unternehmens evaluieren.
Wenn Sie neu im Unternehmen sind oder eine neue Rolle übernommen haben, werden Sie wahrscheinlich unter (realem oder scheinbarem) Druck stehen, schnell zu handeln. Dies trifft vor allem auf Unternehmen zu, die noch nicht viel Erfahrung im bewussten Umgang mit Umweltfragen haben und dies jetzt nachholen möchten.
Es ist besser, wenn Sie der Versuchung, zu schnell zu handeln, widerstehen. Voreilige Handlungen können sowohl Ihre als auch die Glaubwürdigkeit des Unternehmens aufs Spiel setzen. Kurzfristig empfiehlt sich eine Konzentration auf dringende Probleme. Die Diskussion strategischer Initiativen kann so lange verschoben werden, bis Sie dazu bereit sind oder bis Ihre Anlaufzeit vorbei ist.

Bewerten Sie Ihr Unternehmen objektiv
Der nächste Schritt besteht darin, eine kritische Bewertung der Umweltverträglichkeit Ihres Unternehmens oder der Branche vorzunehmen. Dafür müssen Sie die wichtigsten Beteiligten und andere einflussreiche Personen innerhalb und außerhalb des Unternehmens hinzuziehen.
Sie müssen ein Netzwerk interner und externer Kontakte aus den Personen aufbauen, die Ihnen eine Definition des Ökosystems der Beteiligten ermöglichen. Diese Personen können Ihnen helfen, ein Verständnis dafür zu entwickeln, auf welcher Stufe das Unternehmen auf der Skala der Umweltverträglichkeit steht.
Je nach Ihren Verantwortungsbereichen müssen Sie möglicherweise herausfinden, welche Stellung Ihr Unternehmen (derzeit und künftig) im Hinblick auf die Einhaltung von Umweltrichtlinien, Standards und Gesetzen einnimmt. Sie müssen eventuell die Position Ihres Unternehmens hinsichtlich Ihrer Mitbewerber und der Erwartungen von Analysten überprüfen. Außerdem müssen Sie verstehen, wie Ihr Unternehmen und dessen Umsetzung von Umweltbelangen von Ihren Kunden, Partnern, Regierungsorganisationen und Verbraucherverbänden wahrgenommen werden. Dazu gehören eventuell auch das Festlegen der gegenwärtigen und zukünftigen technologischen, finanziellen und umweltbedingten Einschränkungen in Bezug auf Ihre Initiativen.
Je nach der Größe und den finanziellen Möglichkeiten Ihres Unternehmens lohnt es sich, zusätzliche Forschung in Betracht zu ziehen. Interne Umfragen, Fokusgruppen und die Drittanbieterforschung können konstruktive Einblicke liefern. Sie können Ihnen helfen, die Mitarbeiterzufriedenheit im Hinblick auf frühere Umweltaktionen des Unternehmens zu verstehen und zu sehen, welche Stellung Ihr Unternehmen in Bezug auf den Wettbewerb einnimmt und wo latente Marktchancen bestehen. Die Möglichkeiten der Drittanbieterforschung zur Validierung oder Widerlegung der Meinungen, die von den Hauptbeteiligten vertreten werden, stellt hierbei jedoch den größten potenziellen Nutzen dar.

Führen Sie sich vor Augen, wann Sie welches Ziel erreichen möchten
Sie können jetzt allmählich verstehen, welche Anforderungen Ihr Unternehmen kurz- und langfristig erfüllen muss. Zu Beginn können Sie diese Anforderungen annähernd auf ein bzw. fünf Jahre festlegen und diesen Zeitrahmen anschließend an Ihre spezifischen Anforderungen anpassen. Der Kernpunkt ist, dass es sich bei der Umwelt auf keinen Fall um eine kurzfristige Angelegenheit handelt, und diejenigen, die nur kurzfristig Stellung beziehen, erweisen ihren Unternehmen, Aktionären, Partnern und Kunden einen sehr schlechten Dienst.
Zum Festlegen der Position, die Ihr Unternehmen in einem Jahr bzw. in fünf Jahren erreichen muss, müssen Sie die Ihre gegenwärtige und zukünftige Geschäftslage bestimmen. Dazu gehören die Unternehmenskultur, die kurz- und langfristigen Geschäftsziele, aktuelle und zukünftige finanzielle Einschränkungen, Pläne zur geografischen Ausdehnung und die sich verändernden Gesetze und Richtlinien für Ihre Branche.
Beispielsweise bietet ein Rechenzentrum ein Beispiel für den Konflikt zwischen taktischen Entscheidungen und strategischer Positionierung. In der Vergangenheit waren die Räumlichkeiten die primäre Überlegung beim Entwurf eines Rechenzentrums. In den letzten Jahren wurde jedoch die Energieversorgung zunehmend zum einschränkenden Faktor für Wachstum und zu einem steigenden Betriebskostenfakor. Die Betreiber von Rechenzentren, die erkannt haben, welche langfristigen Implikationen die zunehmende Bedeutung von Energie hat, haben Schritte unternommen, um unwirtschaftlichen Energieverbrauch zu verringern. Dazu gehörten radikale Veränderungen in der Verwaltung von Rechenzentren, die dem vorherrschenden vom Raumaspekt gesteuerten Entscheidungsfaktor zuwiderliefen. In einigen Fällen waren die Investitionen in einen verringerten Energieverbrauch im Vergleich zum bestehenden Denkmuster mit erheblichen kurzfristigen Kosten verbunden. Mit dem beachtlichen Anstieg der Energiepreise werden die Betreiber von Rechenzentren, die den Kurs der Rechenzentrumverwaltung vor einigen Jahren proaktiv verändert haben, heute als visionär angesehen, und ihre Unternehmen wurden jetzt für die anfänglichen Investitionen mehr als entschädigt.

Entwickeln Sie eine Vision und Strategie
Jetzt müssen Sie eine Vision und Strategie entwickeln. Es liegt auf der Hand, dass dies aus dem Verständnis heraus geschehen muss, wo sich Ihr Unternehmen heute befindet und welches Ziel es hat. Beim Festlegen der Vision und der Strategie sind diese ihrer Natur nach nicht als konstant anzusehen. Auch wenn Ihr Unternehmen sich der Umwelt langfristig verpflichtet hat, werden Ihre Vision und Strategie vermutlich nicht langfristig angelegt sein. Sie wird sich infolge interner und externer Variablen, z. B. Veränderungen in den gesetzlichen Anforderungen, Verschiebungen bei der Kundenwahrnehmung und sich entwickelnder Geschäftsanforderungen, in Zukunft noch großen Veränderungen unterliegen. Aufgrund der wachsenden Umweltinitiativen von Unternehmen ist es wichtig, die Vision und Strategie der IT-Abteilung mit der umfassenderen Unternehmensvision und -strategie in Einklang zu bringen.
Mit der Vision legen Sie gleichzeitig die Richtung Ihres Unternehmens fest. Sie müssen Ihre Worte vorsichtig auswählen, damit sie wohl durchdacht, genau und zusammenhängend, aber nicht abschließend sind. Die Vision hat nicht den Zweck, alles abzudecken, was Ihr Unternehmen in Bezug auf die Umwelt unternehmen wird. Durch sie sollen nur die jeweiligen Probleme angesprochen werden, um Ihren Mitarbeitern und Partnern die Richtung zu weisen. Die Vision wird oft im Rahmen eines Leitsatzes oder einer Grundsatzerklärung mitgeteilt. Es ist sehr wichtig, dass Sie Ihre Vision bereits in den ersten sechs Monaten beginnen.
Durch Festlegen der Strategie definieren Sie nicht nur die Richtung. Sie legen gleichzeitig die expliziten Geschäftsziele und das Investitionsprofil zum Erreichen dieser Ziele fest. Es gibt Modelle, die Ihnen beim Gestalten eines strategischen Plans Hilfestellung geben können. Zwei der besten Modelle für Fragen der Umwelt und Nachhaltigkeit sind die Modelle SWOT (Strengths, Weaknesses, Opportunities und Threats) und PESTLE (Political, Economic, Social, Technological, Legal und Environmental). Sie können dann die Strategie, z. B. einen strategischen Plan, in einem Dokument definieren.
Beachten Sie, dass Führungspersonen, die vor der Herausgabe der schriftlichen Grundsatzerklärung von den wahrgenommenen Befürwortern und Gegenspielern in großem Umfang Feedback zur eigenen Vision und Strategie einholen, wahrscheinlich größere Aussichten auf Erfolg haben. Dies trifft vor allem auf diejenigen zu, die in ihrem endgültigen Plan auf das Feedback von Gegenspielern eingehen.

Überzeugen Sie aufgrund geschäftlicher Anforderungen
Mit der Überzeugungsarbeit muss nicht bis zur Veröffentlichung einer Vision und Strategie gewartet werden. Vielmehr muss sie an dem Tag beginnen, an dem Sie die Rolle übernehmen. Nach der Veröffentlichung Ihrer Vision und Strategie müssen Sie jedoch verstärkt eine öffentliche Rolle einnehmen, und zwar sowohl intern als auch extern. Anfangs müssen Sie bzw. Ihr Beauftragter die Vision einflussreichen Gruppen wie Mitarbeitern, Analysten, Medien, Partnern, Kunden und Verbraucherverbänden vermitteln. Sie müssen sie dazu anregen und motivieren, an Ihre Vision und Strategie zu glauben, und überzeugende Argumente dafür liefern, dass Ihre Strategie den Interessen Ihres Unternehmens und Ihrer Zielgruppen zuträglich ist.
Mit der Zeit müssen Sie den Fokus auf die einzelnen Elemente der Strategie verlagern. Außerdem müssen Sie diese Zielgruppen regelmäßig auf dem Laufenden halten, indem Sie auf wichtige, den Erfolg demonstrierende Meilensteine hinweisen, strategische Änderungen mitteilen und offen über die Herausforderungen für Ihr Unternehmen oder die Branche im Allgemeinen sprechen.
Stellen Sie sich darauf ein, dass jede Gruppe unterschiedliche Interessen und Anforderungen präsentiert. Auch wenn Sie auf die spezifischen Anforderungen und Interessen der jeweiligen Gruppen eingehen müssen, muss Ihre zugrunde liegende Vision und Strategie konstant bleiben. So können Sie die Zustimmung der verschiedenen Zielgruppen effektiver einholen.
Widerstehen Sie dem Drang, widersprüchliche „Geschäftsanforderungen“ bekannt zu geben, um verschiedene Zielgruppen zu beschwichtigen. Führungspersonen, die dies tun, erzielen keine Glaubwürdigkeit in Bezug auf die Probleme. Dadurch wird bestenfalls ihre Wirksamkeit als Vorreiter von Veränderungen eingeschränkt. Schlimmstenfalls kann dies die Glaubwürdigkeit des gesamten Unternehmens gefährden. In Abbildung 1 werden die sieben Schlüssel zur effektiven Kommunikation Ihrer Botschaft hervorgehoben.
Abbildung 1 Sieben Schlüssel zur Kommunikation Ihrer Botschaft
Abbildung 1 Sieben Schlüssel zur Kommunikation Ihrer Botschaft (Zum Vergrößern auf das Bild klicken)

Verwalten Sie Ihre Mitteilungen
Berücksichtigen Sie bei der Überzeugungsarbeit für Ihre Vision und Strategie, dass interne und externe Mitteilungen professionell und unter Integritätsgesichtspunkten gestaltet werden sollten. Die Umwelt und Nachhaltigkeit sind mit der sozialen Verantwortung von Unternehmen ebenso verknüpft wie mit den Bereichen Produktentwicklung, Dienstleistungen, Vertrieb und Marketing. Selbst wenn Ihre Organisation Ihnen funktional die Rolle des leitenden Umweltbeauftragten zugewiesen hat – ohne Ihnen eine direkte Verfügungsgewalt über den Beitrag zu einer nachhaltigen Entwicklung im Rahmen der unternehmerischen Sozialverantwortung zu übertragen – sollten Sie für Ihre Tätigkeit annehmen, dass für Sie dieselben Standards gelten wie für einen so genannten Citizenship Leader.
Unterschätzen Sie das Engagement externer Zielgruppen für Umweltprobleme und ihre Vertrautheit mit umweltfreundlichen Geschäftsmethoden nicht. Unterschätzen Sie auf keine Fall, dass Ihre Mitteilungen nicht ernst genommen werden könnten, wenn sie keine Integrität aufweisen bzw. zu viel oder zu wenig versprechen. Andernfalls könnte Ihrem Unternehmen das Etikett angeheftet werden, dass es sich einen grünen Anstrich verschaffen will.
Deshalb benötigen Sie eine Kommunikationsstrategie mit einem Überprüfungsprozess einschließlich interner Experten, die Feedback bieten können, bevor Sie öffentlich Stellung beziehen. Ihre Kommunikationsstrategie muss die Hauptelemente Ihrer Botschaft ins Bild setzen, wie z. B. ein Unternehmensinfoblatt, einen entsprechenden Rahmen für die Botschaft, eine Liste autorisierter Sprecher sowie Gesprächspunkte. Die Kommunikationsstrategie, die für eine klare Struktur und Konsistenz sehr wichtig ist, muss bald nach der Entwicklung Ihrer Vision und Strategie abgeschlossen werden. Den Verfassern der Mitteilungen sollte daher persönliche Verantwortung für die Inhalte übertragen werden.

Ermöglichen Sie eine Verwaltung durch Messungen
Es ist wichtig, dass Sie die Verantwortlichkeiten verwalten, die sich im Bereich Ihrer Vision und Strategie befinden. Ob es sich um Betriebsvorgänge, Produktentwicklung oder Vertrieb und Marketing handelt, Sie müssen die Faktoren definieren, die sich auf Ihre Fähigkeit zum Erreichen Ihrer Ziele auswirken. Listen Sie diese Faktoren in einer genauen Liste auf, und integrieren Sie sie in den umfassenden strategischen Plan. Sie müssen diese Faktoren dann qualitativ und/oder quantitativ in Grundwerte umarbeiten und Kontrollwerte festlegen, die eine zukünftige Analyse ermöglichen. Diese Kontrollmetriken müssen aktiv verwaltet werden.
Die Verantwortungsbereiche für die Erstellung von Berichten über diese Kontrollmetriken müssen klar definiert werden, und Sie sollten regelmäßige Besprechungen mit allen Hauptbeteiligten ansetzen. Die Beteiligten können dann die Auswirkungen der Kontrollmetriken auf die Stabilität des strategischen Plans erörtern. Dies wird durch die Zuordnung der Metriken auf die Faktoren und wiederum der Faktoren auf die einzelnen Elemente des strategischen Plans ermöglicht.
Leider werden viele leitende Umweltbeauftragte feststellen, dass ihre Organisationen nicht darauf vorbereitet sind, solche Kontrollmetriken mit den Messtools zu unterstützen. Doch diese Tools sind erforderlich, um die Datenqualität und -menge bereitzustellen, die für eine korrekte Analyse und Darstellung der Umwelt- und Nachhaltigkeitsbemühungen erforderlich sind. Deshalb müssen Sie spezielle Messtools entwickeln, sei es durch einen Neuentwurf des Geschäftsprozesses, die Bereitstellung der Zusammenarbeits- und Messtechnik oder die Entwicklung angepasster interner Tools.
Ohne Unterstützung seitens der Unternehmensführung bei der Investition in diese Messtools werden Sie wahrscheinlich vor ernsten Kosten-Nutzen-Entscheidungen stehen, ob Sie den richtigen Messtools auf Kosten einer Personalbestandserweiterung den Vorrang geben sollen.

Erstellen Sie eine Analyse und einen Bericht über die Umweltbelastung
Die Erfassung von Datenmengen entsprechender Qualität ermöglicht eine eingehende Analyse. Diese Analyse ist für Thought Leaders äußerst wichtig, um den Erfolg ihrer Initiativen sowie die Auswirkungen ihrer Aktionen auf das Unternehmen oder seine Branche zu verstehen.
Der sich wandelnde Rahmen von Richtlinien, Standards, Gesetzen und freiwilligen Maßnahmen zur Berichterstattung von Unternehmen im Hinblick auf Umweltbelange setzt Unternehmen zunehmend unter Druck, ausführliche Informationen über ihren Beitrag zur Umweltbelastung zu veröffentlichen. Wenn die notwendigen Tools und Prozesse zur Verfügung stehen, um die Verwaltung, Messung und Analyse zu unterstützen, vereinfacht dies die Erfassung von Informationen, die für vorgeschriebene Jahresberichte, Steuererklärungen und freiwillige unternehmerische Nachhaltigkeitsberichte benötigt werden. Es ist deshalb wichtig, dass Sie die Berichterstattungsanforderungen für Ihr Unternehmen kennen und wissen, wie sie in Zukunft aussehen werden, damit Sie in eine integrierte Verwaltungs-, Mess-, Analyse- und Berichtinfrastruktur investieren können, die sich entsprechend Ihren Geschäftsanforderungen erweitern lässt.
Technologie ist für Analyse und Berichterstattung von Unternehmen, die sich zu innovativen Leitfiguren entwickeln möchten, von großer Bedeutung. Software spielt eine wichtige Rolle in diesem Bereich, vor allem Software, die für Umweltverwaltung, Prozessentwurf, Datenerfassung und -bearbeitung, Fernerkundung, Zusammenarbeit, Visualisierung und Präsentation verwendet wird.
Kommerziell verfügbare Software muss manchmal für bestimmte Anwendungen im Umweltbereich angepasst werden. Folglich bedarf es erheblicher Investition in die Technologie, um eine integrierte Verwaltungs-, Mess-, Analyse- und Berichtinfrastruktur zu ermöglichen.

Seien Sie eine innovative Führungsperson
Ein innovativer Führungsstil ist etwas, was jeder leitende Umweltbeauftragte anstreben sollte. Es gibt verschiedene Arten von Thought Leaders (siehe einige Beispiele in Abbildung 2), denen eines gemeinsam ist: Ihre Fachkenntnis hängt nicht von einem Titel ab, sondern von ihren bisherigen von Integrität und Offenheit getragenen Handlungen zur Förderung des Wandels.
Abbildung 2 Typen innovativer Führungspersonen
Abbildung 2 Typen innovativer Führungspersonen (Zum Vergrößern auf das Bild klicken)
Das globale Ökosystem der Umweltverträglichkeit hängt davon ab, dass Thought Leaders sich für Veränderungen einsetzen. Dank eines ausgedehnten Netzwerks von Kontakten, die sich über Regierungs-, nichtstaatliche, Branchen- und Verbraucherorganisationen erstrecken, kann eine innovative Führungsperson einflussreiche Parteien zusammenbringen, um Probleme zu behandeln, die eine enge Zusammenarbeit erfordern. Ein Thought Leader ist außerdem mit vielen der neu entstehenden Umweltprobleme vertraut, die die globale Community betreffen, und kann diese Probleme an ein globales Publikum herantragen.
Abschließend fasst eine innovative Führungsperson Lösungen für wichtige Probleme ins Auge, die von der Branche im Allgemeinen noch nicht in den Mittelpunkt gestellt werden. Die Entwicklung dieser Lösungen bedarf eventuell Einfluss von außen und die Zusammenarbeit mit anderen, einschließlich Mitbewerbern, und kann dazu führen, dass Ihr eigenes Unternehmen in noch nicht bediente Märkte vordringt. Das Ergebnis ist jedoch, dass innovative Führungspersonen eine Veränderung bewirken können, die globaler Natur ist.

Bleiben Sie auf dem Laufenden
Es geht hier um eine neue Disziplin, und das vorhandene Wissen verändert sich regelmäßig. Kontinuierliche Glaubwürdigkeit erfordert ein gut fundiertes Fachwissen über die verschiedensten wissenschaftlichen, richtlinienbasierten, gesetzlichen, wirtschaftlichen, technologischen und geschäftlichen Perspektiven, die von anderen Umweltbeauftragten in Führungspositionen gefördert werden. Das erfordert auch, dass Sie nicht unbedingt mit der vorherrschenden Tagesmeinung übereinstimmen, sondern für einzigartige Perspektiven werben, die auf einem fachkundigen Verständnis der Umweltverträglichkeit und Computernutzung beruhen. Angesichts der steigenden Anzahl von leitenden Umweltbeauftragten in der Branche (bzw. denjenigen, die sich als solche bezeichnen) werden Sie sich durch diese Art von Integrität profilieren können.
Eine etablierte Führungsperson muss zudem sicher sein, dass sie Verantwortung an Mitarbeiter delegieren kann, die über spezifische Kenntnisse auf einem bestimmten Gebiet verfügen, und erfahreneren Vertretern der Umweltpolitik im Unternehmen den Vortritt lassen können, wenn die Umstände es erfordern. Durch regelmäßige Besprechungen mit Vorgesetzten und eine sorgfältige Berichterstattung wird gewährleistet, dass Sie stets umfassend über die Anstrengungen Ihres Unternehmens in Bezug auf Umweltverträglichkeit informiert sind. Dabei kommt es darauf an, dass Sie sich bewusst sind, wann Sie im Auftrag des Unternehmens sprechen müssen. Dies erfordert ein klares Verständnis Ihrer zentralen Verpflichtungen und ist eine Eigenschaft, in der sich Ihre Verantwortung beim Aufrechterhalten der von externen und internen Zielgruppen erwarteten Überzeugungen im Bereich Umwelt klar und deutlich ausdrückt.

Michael Walshist leitender Umweltproduktmanager bei Microsoft.
Eliza Walshist Beraterin für Kommunikationsstrategie und war früher als Kommunikationsexpertin für Microsoft in China tätig.


Berichte aus der Praxis Gemeinsame Monitornutzung mittels Split Screen
Kentaro Toyama

Möglichst viele Menschen sollen die Chance haben, Computer zu nutzen: Dies ist das Ziel von Microsoft Research India, das mit MultiPoint (vorgestellt in der Ausgabe des TechNet Magazins vom Mai 2008) ein Programm entwickelt hat, das vielen Benutzern die Interaktion mit einem Computer über mehrere Mäuse ermöglicht.
Split Screen, ebenfalls entwickelt von Microsoft Research India, ermöglicht eine weitere Form der gleichzeitigen gemeinsamen Arbeit an einem Computer. Das Programm richtet einen PC mit zwei Tastaturen und zwei Mäusen ein und passt dann die Terminaldienste so an, dass der Monitor in der Mitte geteilt wird. Anschließend kann der Monitor von zwei Personen gemeinsam genutzt werden, die separate Instanzen des Betriebssystems und ihre eigenen Anwendungen unabhängig voneinander ausführen (research.microsoft.com/users/udaip/splitscreen.htm). So könnte beispielsweise eine Person ein Textverarbeitungsprogramm ausführen, während die andere an einer Tabelle arbeitet.
Um Split Screen zu ermöglichen, werden drei separate Instanzen von Terminalserver verwendet, die in Windows Server® 2003 ausgeführt werden (derzeit erfolgt eine Aktualisierung auf Windows Server 2008). Die erste ist ein Container, der Maus- und Tastaturereignisse erfasst und verteilt. Diese Schicht verwendet denselben Trick, der bereits für MultiPoint angewendet wurde, wo alle Maus- und Tastaturereignisse zusammen mit ihren Geräte-IDs erfasst werden. (Windows® weist USB-Geräten automatisch eindeutige IDs zu, wenn sie angeschlossen werden. Diese sind zwar nicht eindeutig für das Hardwaregerät, aber eindeutig innerhalb der aktuellen Instanz des Vorgangs, und genau dies ist erforderlich, um zu erkennen, ob zwei Mausklicks von derselben Maus oder von verschiedenen Mäusen ausgeführt werden.) Der Container zeichnet auch die Mauszeiger.
In dem Container öffnen wir zwei zusätzliche Instanzen von Terminalserver, die jeweils nur die Ereignisse empfangen, die für einen Bildschirm relevant sind. Im Standardmodus werden beispielsweise alle Mausereignisse der Maus mit der ID x auf der linken Seite des geteilten Bildschirms wiedergegeben, während alle Ereignisse der Maus mit der ID y auf der rechten Seite ausgeführt werden.
Split Screen verwendet die Terminaldienste, um einen Computermonitor in der Mitte zu teilen
Split Screen verwendet die Terminaldienste, um einen Computermonitor in der Mitte zu teilen (Zum Vergrößern auf das Bild klicken)
Die Containerinstanz von Terminalserver ist wichtig, um umfassende Kontrolle darüber zu haben, welche Ereignisse wo wiedergegeben werden, und erweiterte Features zu ermöglichen. So können wir beispielsweise dem rechten Cursor gestatten, auf den linken Bildschirm zu wechseln und auf ein Element zu zeigen (vielleicht im Rahmen eines Lernprogramms) oder sogar mit dem anderen Fenster zu interagieren.
In diesem Fall würde ein Teil der rechten Mausereignisse auch auf dem linken Bildschirm stattfinden. Außerdem haben wir die Verwendung von Virtualisierungstechnologie in Windows zur Ausführung ähnlicher Funktionen erwogen. Möglich ist das, aber wir haben festgestellt, dass der Ressourcenverbrauch höher ist.
Die Forscher hatten Bedenken, dass Benutzer frustriert reagieren könnten, wenn sie nur eine Bildschirmhälfte zur Verfügung haben. In Bangalore in Indien führten wir Studien mit der Hope Foundation durch, die Jugendlichen aus Familien mit niedrigem Einkommen elementare Computerkenntnisse vermittelt. Die Jugendlichen lernten offenbar mit Split Screen genauso viel, als wenn sie einen ganzen Computer für sich gehabt hätten. Zumindest galt dies für ein begrenztes Spektrum von IT-Schulungsaufgaben. Wir achteten auch auf ergonomische Probleme, die aber nicht auftraten (selbst an 14-Zoll-Bildschirmen nicht). Am meisten freute sich das IT-Schulungscenter aber darüber, dass mit der gleichen Zahl von Computern doppelt so viele Schüler ausgebildet werden konnten.
Microsoft Research India führt Gespräche mit der Terminaldienste-Gruppe und mit anderen Microsoft-Gruppen, um festzustellen, ob es sich lohnt, Split Screen als Technologie zu vermarkten. Wenn Split Screen für Sie nützlich sein könnte, teilen Sie uns bitte mit, in welchen Szenarios Sie die Technologie einsetzen möchten. Senden Sie eine E-Mail an splitscr@microsoft.com.

Kentaro Toyama ist stellvertretender Direktor von „Microsoft Research India“ (research.microsoft.com/india) und Forschungsleiter der Gruppe „Technology for Emerging Markets“ (research.microsoft.com/research/tem), die Technologien für wirtschaftlich schwache Gemeinschaften weltweit entwickelt.


Windows Confidential Die beiden schlechtesten PCs, die es je gab
Raymond Chen

Im März 2007 , als die Zeitschrift PC World ihre Liste der schlechtesten zehn PCs erstellte, fielen mir die beiden ersten auf, weil wir beide Modelle bei der Arbeit verwendeten. Nun, „verwendeten“ ist zu viel gesagt. Vielleicht entspricht es eher der Wahrheit, dass ich beobachten konnte, wie diese Computer den Großteil ihres produktiven Lebens im Büro eines Microsoft-Mitarbeiters verbrachten.
Der Barbie-PC der Marke Mattel stand auf der Liste von PC World bei den schlechtesten Computern an zweiter Stelle. Dieser Computer war eine enorme Verbesserung gegenüber den billigen Computern in einer langweiligen Farbe. Stattdessen war es ein billiger Computer in einer langweiligen Farbe, der mit pinkfarbenen Aufklebern auf dem Gehäuse, dem Monitor und den Lautsprechern „verschönert“ werden konnte. Zudem war Software zum Thema Barbie vorinstalliert.
Wir kauften einen dieser PCs als Testcomputer, und der arme Tester, der sich mit diesem Gerät abplagte, hatte zumindest so viel Humor, dass er sich mit gespielter Begeisterung an die Aufgabe machte und alle beigefügten Aufkleber und Dekorationen anbrachte, um sicherzustellen, dass der Computer „richtig“ installiert wurde. Er stand auf einem Tisch, der vom Flur aus gleich sichtbar war, und jeder, der vorbeikam und diese Computerkatastrophe in leuchtendem Pink sah, durfte hereinkommen und mit ihm herumspielen.
Der Barbie-PC war eine Quelle ständigen Vergnügens. Jedes Mal, wenn es Probleme mit dem Computer gab und Entwickler zum Debuggen herangezogen werden mussten, mussten sie erst zwei Mal hinsehen und äußerten sich oft voller Begeisterung über das Gerät, an dem sie arbeiten sollten. Ich habe gehört, dass in einem Sommer die Hochschulpraktikanten eine Kopie der Datacenter Edition von Windows Server® auf dem Barbie-PC installierten, um sich einen Spaß zu machen.
Der erste Preis – oder besser gesagt, die schlechteste Bewertung – ging an den Packard Bell-PC. Welch schöne Erinnerungen. Ein Beispiel für das gute Design dieses Computers: bei der Standardkonfiguration war jeder Erweiterungssteckplatz belegt. Vielleicht dachte der Hersteller: „Unser Computer ist so perfekt, dass er nie aktualisiert werden muss!“
Damals, zur Zeit des Windows® 95-Projekts, kaufte ein leitender Mitarbeiter einen dieser Computer für zu Hause und installierte regelmäßig den aktuellen Build von Windows 95 als Teil des „Dogfooding“-Verfahrens darauf. Wie nicht anders zu erwarten, kam es zu allen möglichen Problemen, und er musste den Computer häufig zum Debuggen mitbringen.
Der Entwicklungsmanager des Windows 95-Projekts war ein kluger Mann, der Probleme bevorzugt auf äußerst direkte Weise löste. Ein Beispiel: Um sicherzustellen, dass Windows 95 mit umfassender Anwendungskompatibilität ausgeliefert wurde, fuhr er mit seinem Kleintransporter zum lokalen Computerladen und kaufte jeweils eine Kopie aller PC-Programme, die dort erhältlich waren. Dann verteilte er die Software auf den Tischen in der Kantine und forderte die Mitglieder des Windows 95-Produktteams auf, jeweils zwei Softwareprodukte mitzunehmen, unter der Bedingung, dass sie diese installieren und ausführen und Fehlerinformationen für alles einsenden würden, das nicht richtig funktionierte, selbst wenn es sich nur um eine Kleinigkeit handelte. Als Gegenleistung dafür durften sie die Software behalten. Die Szene in der Kantine war wie auf einem Flohmarkt, auf dem alle auf der Suche nach einem Schnäppchen sind und einander aufgeregt fragten: „Und was hast du Tolles gefunden?“
Beschämt darüber, wie oft der leitende Mitarbeiter seinen Heimcomputer zum Debuggen mitbringen musste, entschied sich der Entwicklungsmanager des Windows 95-Projekts wieder für den direkten Weg. Im lokalen Computerladen kaufte er einen Packard Bell-PC, der mit dem des Mitarbeiters identisch war.
Die Tatsache, dass zwei dieser Computer überhaupt existierten, war schlimm genug. Noch schlimmer war, dass mir die Aufgabe übertragen wurde, jeden neuen Build von Windows 95 darauf zu installieren und entstehende Probleme zu debuggen. Wenn der Mitarbeiter zu Hause nun den aktuellen Build auf seinem Heimcomputer installierte, gab es keine Probleme mehr.
Wenn Sie diesen Artikel genau gelesen haben, ist Ihnen bei diesem Plan vielleicht ein Hindernis aufgefallen. Da beim Packard Bell-PC alle Erweiterungssteckplätze belegt waren, konnte nirgendwo ein Netzwerkadapter installiert werden. Ich musste auf andere undurchsichtige Mittel zurückgreifen, um Netzwerkkonnektivität zu erhalten. Dieser Computer war mir wirklich verhasst.

Raymond Chen befasst sich auf seiner Website „The Old New Thing“ und in seinem gleichnamigen Buch mit der Geschichte von Windows und mit der Win32-Programmierung. Die Objekte in seinem Spiegel sind näher als sie zu sein scheinen.