© Anna Koldunova

In der deutschen Corporate-IT philosophiert man noch über sichere interne Netze, andernorts ist man schon weiter: Zero-Trust-Umgebungen machen Zugriffsberechtigungen von einer Vielzahl von Faktoren abhängig, die allesamt zu einem komplexen Konzept gehören.

Im dritten Jahr der Corona-Pandemie ist längst klar, dass vielen Unternehmen das Virus als wahrer Segen für das eigene Geschäft in Erinnerung bleiben dürfte. Die Hersteller von VPN-Lösungen fallen zweifelsfrei in diese Kategorie: Als Homeoffice und Telearbeit in vielen Firmen von der Ausnahme zur Regel mutierten, wurden vorhandene VPN-Lösungen (Abbildung 1) vielerorts zum Nadelöhr. Kaum jemand hatte damit gerechnet, dass von heute auf morgen die auf den VPN-Gateways anliegende Last explodieren würde. Die großen Netzwerkhersteller halfen ihrer Kundschaft da gern aus, und viele Admins legten sich leistungsfähigere Systeme für OpenVPN zu (Abbildung 2).

Abbildung 1: VPN-Gateways wie dieses Gerät von Draytek kommen mit großen Mengen an Nutzern klar. Corona-bedingt stoßen sie vielerorts trotzdem an ihre Leistungsgrenzen. Quelle: Draytek

Abbildung 2: Eigenbau-VPN-Lösungen, wie hier auf Basis von OpenVPN, entsprechen nicht mehr modernen Sicherheitskonzepten und bringen die genutzte Hardware an ihre Grenzen. Quelle: KIT

Implizit gehen bei der Verwendung von VPNs alle Beteiligten von folgender Prämisse aus: Es gibt einen Unterschied zwischen dem internen und dem externen Netz, und es gilt, interne Clients anders zu behandeln als externe. VPNs kommen regelmäßig gerade deshalb zum Einsatz, weil spezifische Dienste aus dem Internet gar nicht erreichbar sein sollen. In vielen Unternehmen bilden sie einen Bestandteil einer seit vielen Jahren organisch gewachsenen Sicherheitsarchitektur. Weil die Anforderungen an Sicherheit in den vergangenen zwei Dekaden kontinuierlich stiegen, haben Firmen immer mehr Geld in private Netze investiert und immer mehr Dienste von der Außenwelt abgeschnitten.

Gerade große Unternehmen sind längst dazu übergegangen, den Zugriff auf E-Mails via Internet zu verbieten. An den Mailserver des Unternehmens kommt man nur noch heran, indem man sich in das VPN einloggt. Das bringt allerlei mehr oder weniger witzige Nebeneffekte mit sich. Außendienstmitarbeiter etwa fluchen, wenn sie irgendwo auf dem platten Land für einen Kunden einen Vertrag anlegen wollen, das VPN wegen der instabilen Leitung aber gerade nicht funktioniert.

Lange Historie

Ausdrücklich sei an dieser Stelle festgehalten, dass Admins in der Regel keine Schuld an diesen Zuständen trifft. Gerade große Firmen setzen auf Sicherheitskonzepte, deren Ursprünge oft noch in den 1990er-Jahren liegen und die nur jene Ressourcen sinnvoll einbinden, die damals zur Verfügung standen. Ein bestehendes Sicherheitskonzept durch ein anderes zu ersetzen, ist insbesondere im laufenden Betrieb eine echte Herkulesaufgabe, vor der viele Verantwortliche aus nachvollziehbaren Gründen zurückschrecken.

Die Einteilung der Welt in “gut” (intern) und “böse” (extern) gehört im Jahr 2022 dennoch auf den Prüfstand, weil sie wie beschrieben mittlerweile oft mehr Probleme schafft, als sie zu lösen vermag. Zudem gibt es durchaus Alternativen: Unter dem Titel Zero Trust firmieren im Netz seit Jahren mehrere Sicherheitsansätze, die eine solche Einteilung fallen lassen. Dieser Artikel stellt das Zero-Trust-Prinzip vor und zeigt, wie es sich in der Praxis umsetzen lässt.

Implizite Annahmen

Ein wenig Wissen um die Hintergründe kommt dabei durchaus zupass, weil vielen mittlerweile gar nicht mehr klar ist, wo die Wurzeln der Konzeption heutiger Corporate-Netze liegen. Die klassische Einteilung in ein unsicheres externes und ein sicheres internes Netz nimmt mehrere Dinge implizit an.

Zunächst geht sie davon aus, dass es grundsätzlich legitim ist, anhand des Aufenthaltsorts Annahmen über das zu erwartende Nutzungsverhalten zu treffen. Die eigenen Mitarbeiter wollen dem Unternehmen nichts Böses, anders als sinistre Hacker, die sich aus dem Netz in fremde Umgebungen einklinken und dort ihr Unwesen treiben. Die zweite Prämisse: Anhand der Lokation eines Clients lassen sich Annahmen darüber treffen, um wen es sich handelt und welche Berechtigungen sich daraus ableiten. Wer es erst einmal ins interne Netz schafft, gilt automatisch als vertrauenswürdig und genießt oft uneingeschränkte Privilegien. Dazu zählt auch der Zugriff auf Infrastrukturkomponenten, die externen Clients verschlossen bleiben.

Vor dem Hintergrund des heutigen Wissens über Informationssicherheit müssen solche Ansätze zumindest als schwierig gelten. Auch Clients im internen Netz stellen ein Sicherheitsrisiko dar. Dabei müssen sich nicht gleich externe Eindringlinge auf verschlungenen Wegen Zugang zu einem Setup verschaffen. Es genügt schon ein Mitarbeiter, der einfach nur den Anhang einer authentisch wirkenden, aber schädlingsbelasteten E-Mail öffnet. Hinzu kommen ehemalige Beschäftigte, die mit ihrer Entlassung hadern und der Versuchung einer Kurzschlussreaktion unterliegen. Allerdings sehen viele klassische Sicherheitskonzepte Ereignisse dieser Art gar nicht erst vor, und der Katzenjammer ist groß, wenn dann doch jemand unberechtigt Daten hinausträgt.

Alternativen zum sicheren Netz

In der Informationssicherheitsbranche ist das Konzept der guten und schlechten Netze deshalb seit einiger Zeit verpönt. Wollen Admins sich eines solchen Setups entledigen, stellt sich die Frage nach einer Alternative. Genau hier kommt das Zero-Trust-Prinzip ins Spiel. Dessen grundsätzliche Prämisse besteht darin, dass Clients keinesfalls allein aufgrund ihrer Lokation besonderen Rechte genießen dürfen.

Ein Dienst geht also in Zero-Trust-Konzepten stets davon aus, dass ein Client sinistre Absichten hat, bis er das Gegenteil unter Beweis stellt, etwa durch eine Anmeldung mit eindeutigen Zugangsdaten. Selbst daraus resultiert noch kein uneingeschränktes Vertrauen, denn neben einer validen Anmeldung gehört zu einer Zero-Trust-Umgebung als integrale Komponente stets auch ein ausgefeiltes Rechtekonzept mit zentraler Verwaltung. Damit also ein Client nach der Authentifizierung etwas tun darf, muss er dazu explizit die Berechtigung besitzen.

Ein weiterer zentraler Faktor bei Zero Trust: Sämtliche Verbindungen sind zu verschlüsseln. Das klingt aus heutiger Sicht möglicherweise etwas redundant, doch Firmen wie Google oder Netflix brachten ihre Zero-Trust-Prinzipien in den ersten Versionen vor fast zehn Jahren an den Start. Zu dieser Zeit waren SSL-Zertifikate teuer und Dienste wie Let’s Encrypt noch nicht erfunden. Viele verzichteten daher auf Verschlüsselung. Zero Trust schließt das explizit aus: Daten müssen auf der Leitung verschlüsselt werden, damit ein Ganove sie nicht durch Anzapfen der Verbindung in die Hände bekommt.

Missverständnissen vorbeugen

Ein häufig gegen das Zero-Trust-Modell in Stellung gebrachter Slogan lautet: Es könne ja kaum gewollt sein, dass sich Maschinen mit kritischer Infrastruktur etwa per SSH frei aus dem Internet erreichen lassen – das öffne Missbrauch Tür und Tor. Das stimmt, doch wer so argumentiert, hat zumindest ein unvollständiges Verständnis von der Idee hinter Zero Trust.

Auch Googles Mailserver sind per SSH aus dem Netz nicht unmittelbar zu erreichen. Das liegt aber nicht daran, dass Google dem eigenen Zero-Trust-Modell abgeschworen hätte. Viel eher gilt insbesondere für den administrativen Zugang zu Infrastruktur, dass der meist einer kleinen, eher statisch definierten Gruppe von Menschen vorbehalten bleibt. Es gibt für den durchschnittlichen Nutzer von Googles Diensten schlicht keinen Grund, per SSH auf die Server zuzugreifen. Der wesentliche Unterschied zu konventionellen Ansätzen, die Netze in Gut und Böse teilen: Etliche zentrale Google-Dienste – jene für die Massen – lassen sich tatsächlich ohne besondere Verbindung erreichen.

Das Zero-Trust-Modell schließt die Verwendung von VPNs für spezielle Zwecke also gar nicht aus. Es richtet sich aber gegen die in vielen Firmen herrschende zentrale Annahme, nur weil ein Client Zugriff auf das VPN habe, dürfe er besondere Rechte genießen. Oft fungiert die spezielle Verbindung dabei als einzige, zentrale Sicherheitsmaßnahme: Wer es erst einmal ins VPN schafft, erhält uneingeschränkten Zugriff auf viele Dienste. Genau dem schiebt das Zero-Trust-Modell einen Riegel vor.

Bis der Admin in einer bestehenden Umgebung das VPN ausschalten oder seine Nutzung einschränken kann, steht viel Arbeit an, denn Zero Trust lässt sich nicht durch die Installation eines bestimmten Programms erreichen. Viel mehr gilt es, ein Konzept zu schaffen, das alle nötigen Komponenten einer Umgebung bestmöglich integriert. Wie wir im Folgenden noch sehen werden, führt das an vielen Stellen zu größeren Herausforderungen.

LDAP hilft

Wie eingangs erwähnt, ist die zentrale Verwaltung von Benutzern und Rechten ein wesentliches, wenn nicht gar das zentrale Element einer Zero-Trust-Strategie. Wie man zu einer zentralen Benutzerverwaltung kommt, ist dabei den meisten Admins relativ klar: Benutzerverzeichnisse gibt es für Linux schließlich in mehrfacher Ausfertigung. Sie implementieren bei Bedarf praktisch auch eine Rechteverwaltung, aber nur, wenn der Admin sie in seiner Planung von Anfang an bedenkt.

Auf dem Markt haben sich zwei Systeme für die zentrale Verwaltung von Anwendern etabliert: LDAP und Active Directory (AD). Gerade in Corporate-IT-Umgebungen findet sich regelmäßig eine leidlich aktuelle Instanz von Microsofts AD (Abbildung 3), und mit etwas Glück ist deren LDAP-Kompatibilität aktiviert. Dann kann der Zugriff auf die Benutzerverwaltung sowohl per LDAP als auch per nativem AD-Protokoll erfolgen. Das Gros relevanter Software bietet heute Unterstützung für mindestens eine diese Zugangsarten.

Abbildung 3: Active Directory kann in einer Zero-Trust-Architektur als zentrale Komponente für Benutzer- und Rollenverwaltung zum Einsatz kommen, ebenso wie LDAP. Quelle: Microsoft

Steht noch kein fertiges Benutzerverzeichnis zur Verfügung und will der Admin ein solches auf Linux-Basis aus der Taufe heben, steht er vor der Qual der Wahl. Infrage kommt einerseits LDAP in der klassischen Implementierung von OpenLDAP. Das gilt zumindest für Suse Linux Enterprise Server und Ubuntu, denen OpenLDAP weiterhin beiliegt. Red Hat fährt bei seinem Enterprise Linux einen eigenen Kurs und liefert stattdessen das Red Hat Identification Management aus. Das setzt im Kern auf FreeIPA, eine Konkurrenzimplementierung zu OpenLDAP mit einigen zusätzlichen Features. So bringt FreeIPA etwa ein integriertes Management von SSH- und SSL-Schlüsseln mit, verwaltet ab Werk Systeme ebenso wie Benutzer und liefert eine Vielzahl an CLI-Werkzeugen.

Nicht ob, sondern wie

Ganz gleich, für welche Option der Administrator sich entscheidet: Fast noch wichtiger als die Existenz von Benutzernamen und ihnen zugeordneten Passwörtern ist ein Rollen- und Rechtekonzept, das sich auch im zentralen Benutzerverzeichnis abbilden lässt. Hier wird es knifflig: Wie man Berechtigungen in LDAP & Co. abbildet, daran scheiden sich oft die Geister.

Eine häufig zum Einsatz kommende Methode beruht auf LDAP-Gruppen. Logisch bildet der Admin dabei die Zugriffsrechte auf eine Ressource als Mitgliedschaft in einer Gruppe ab. Zugang zum jeweiligen Dienst erhalten nur jene Nutzer, die der entsprechenden LDAP-Gruppe angehören. Feiner abstufen kann man das jedoch nicht, weshalb sich Workarounds entwickelt haben. Oft finden sich etwa unterschiedliche LDAP-Gruppen für Nutzer und Administratoren von Diensten. Der Haken an der Sache: Der danach an LDAP angekoppelte Dienst muss in der Lage sein, diese Gruppen auch auszuwerten. Daneben existieren weitere Hürden. Schließlich kennen LDAP und Konsorten auch Rollen sowie zusätzliche Hierarchieebenen. Diese Faktoren stellen in der Praxis oft ein zentrales Hindernis dar.

Erst planen, dann bauen

Das unterstreicht, welche tragende Rolle bei der Einführung von Zero-Trust-Modellen die Planung im Vorfeld spielt. Bevor Systemverwalter auch nur darüber nachdenken, OpenLDAP oder FreeIPA auszurollen, sollten sie anhand einer RASCI-Matrix ein praktikables Design für Nutzer und Rollen haben, das schon im Vorfeld so viele Eventualitäten wie möglich abbildet.

Wie üblich gilt: Ist das Konzept erst einmal im Einsatz, lassen sich tiefgreifende Veränderungen nur noch schwer umsetzen und führen in der Regel zu Unmut bei den Benutzern. Steht dagegen schon im Vorfeld fest, welche Berechtigungen der Zugriff auf einzelne Dienste erfordert, lässt sich das zentrale Benutzerverzeichnis entsprechend implementieren. Das Hauptaugenmerk liegt danach auf der Software, die spezifische Dienste für Anwender bereitstellt.

Wenige Standards

Aus Sicht des Systemverwalters erscheint dabei besonders problematisch, dass Zero Trust bis heute nicht in Form eines etablierten technischen Standards vorliegt, sondern nur als eine Vielzahl teils konkurrierender Konzepte. Der Standard SP800-207 [1] des amerikanischen National Institute for Standards and Technology (NIST) definiert zwar eine Zero-Trust-Architektur, bleibt dabei aber einigermaßen schwammig. Möchte eine Software also den Anforderungen von Zero Trust genügen, gibt es kein fertiges Drehbuch, an dem sie sich orientieren könnte.

Wie gut sich einzelne Komponenten in Zero Trust integrieren lassen, hängt stark vom Einzelfall ab. Zentrale Dienste wie eine vorhandene Groupware oder Mailserver bieten in den meisten Fällen entsprechende Flexibilität. Standardlösungen wie Dovecot oder Postfix etwa beherrschen die Anbindung an LDAP mit vielen Rädchen für das Feintuning. Ein Mail-Setup, das Zero Trust mit Zwei-Faktor-Authentifizierung (2FA) implementiert, lässt sich insofern recht gut realisieren.

Unübersichtlicher wird die Situation, kommen proprietäre Tools zum Einsatz, die gar keine Verbindung zu LDAP herstellen oder Features wie 2FA nicht implementieren. Hier muss der Administrator zu Workarounds greifen: Die Libpam etwa bietet implizit Zwei-Faktor-Authentifizierung und verfügt mittlerweile über Module, die etwa Googles Authenticator einbinden. Das ermöglicht es sogar, den SSH-Login auf entfernten Systemen zusätzlich zu sichern, sodass der bloße SSH-Schlüssel nicht mehr ausreicht, sondern die Anmeldung zudem ein Token aus dem Google Authenticator erfordert. Allerdings hat sich gerade die Implementierung über PAM in der Vergangenheit als Performance-Fresser entpuppt. Hier fällt dem Admin die Aufgabe zu, die unterschiedlichen Parameter abzuwägen.

Spezielle Software

Immerhin gibt es mehrere Projekte, die den Administrator bei der Implementation von Zero Trust unterstützen. Ein prominenter Vertreter ist Teleport (Abbildung 4), das breitbrüstig als Ersatz für OpenLDAP & Co. antritt und “identity-aware authentication” verspricht. Im Hintergrund setzt es dabei auf etablierte Standards wie X.509 oder OpenID und exponiert diese zur Nutzerseite hin, während es gegenüber klassischen Diensten wie SSH als Client auftritt. Praktisch handelt es sich bei Teleport also um eine Art Proxy, der die Migration in Richtung Zero Trust stark erleichtert.

Abbildung 4: Teleport zeigt, wie es geht: Der Dienst fungiert als ein Proxy zwischen einer Zero-Trust-Architektur und anderen Anwendungen, auf die es den Zugriff entsprechend einschränkt. Quelle: Teleport

Das bringt gerade im Hinblick auf proprietäre oder Legacy-Software noch einen anderen Vorteil mit sich: Solche Anwendungen lassen sich überhaupt erst mit Services wie Teleport in Zero-Trust-Architekturen integrieren. Wer schon einmal versucht hat, alte In-House-Software neu zu installieren, der weiß, wie schwierig sich das etliche Jahre nach dem Entstehen des Programms gestalten kann. Das gilt umso mehr für nachträgliche Veränderungen an der Software.

Es ist zweifellos kein Zufall, dass Teleport auf seiner Website die Banken als eigene Kundengruppe hoher Relevanz zuerst nennt. Dort findet sich besonders häufig steinalte Legacy-Software, bei der man an die Integration in moderne Sicherheitsarchitekturen kaum noch zu denken wagt.

Mobile Geräte

Mobilen Geräten kommt im IT-Alltag eine stetig wachsende Relevanz zu. Kein Wunder, sind doch Smartphones und Tablets längst zu halben Computern mutiert, mit denen sich einfache Aufgaben im Alltag bequem erledigen lassen. Gerade Smartphones betrifft der VPN-Wahn mancher Firmen überproportional, weil die Mobilfunknetze in Deutschland oft genug keine stabile VPN-Verbindung ermöglichen.

Auch unabhängig von Zero Trust gelten für mobile Geräte schon besondere Spielregeln. Wie bei Laptops muss die Verschlüsselung der auf dem Gerät liegenden Daten hohe Priorität haben. Schließlich kommen solche Devices deutlich einfacher abhanden als ein installierter Desktop auf einem Schreibtisch. Aus demselben Grund gilt es, den noch immer viel zu häufig vorzufindenden Umstand zu unterbinden, dass Anwender auf ihren Smartphones die Sicherheitssperre per Face-ID, Fingerabdruck oder PIN deaktivieren. Ein so konfiguriertes Smartphone oder Tablet gibt seine Daten ohne Weiteres preis, und zwar auch in den falschen Händen.

Nicht zuletzt haben Firmen ein gehobenes Interesse daran, stets die Kontrolle über ein Gerät zu behalten, selbst wenn es gestohlen wurde oder verloren gegangen ist. Dann soll zumindest die Möglichkeit bestehen, es aus der Ferne zu löschen und die weitere Verwendung durch eine Aktivierungssperre zu unterbinden. Das geklaute Device kann dann höchstens noch als Ersatzteilspender dienen – auch wenn die Hersteller das zunehmend unterbinden, allen voran Apple.

Zero Trust und Mobilgeräte

In Umgebungen nach Zero-Trust-Standard kommt den Geräten darüber hinaus noch eine andere, zentrale Bedeutung zu: Weil es in Zero Trust alle Authentifizierungen über mehrere Faktoren abzusichern gilt, fungieren sie als Sicherheitstoken, etwa per Google Authenticator. Das heißt freilich, dass die beschriebenen Sicherheitsmaßnahmen umso dringender zu beachten sind – Stichwort Unlock-Mechanismus: Lässt sich ein Gerät ohne Weiteres entsperren, bleibt der installierte Google Authenticator als zweiter Faktor ohne Wirkung. Das gilt zumindest dann, wenn es einem Angreifer gelingt, Gerät und Passwort unter die eigene Kontrolle zu bringen. Eine passende Unlock-Konfiguration tut also not.

So zentral die Rolle mobiler Geräte in Zero-Trust-Umgebungen auch ausfällt, insbesondere als zweiter Faktor für Authentifizierung: Bislang gibt es kaum sinnvolle Möglichkeiten, die Geräte mit Linux-Bordmitteln zentral zu administrieren. Zumindest existiert auf der Softwareebene nichts, was es mit den zentralen Werkzeugen von Google (Abbildung 5) oder Apple (Abbildung 6) auch nur im Ansatz aufnehmen könnte. Das umfasst etwa Features wie die beschriebene Möglichkeit, ein verloren gegangenes Smartphone aus der Ferne zu löschen. Wer Diensthandys ausgibt, sollte für Zero Trust diesen Faktor also in der Planung berücksichtigen. Es lässt sich kaum vermeiden, hier in den sauren Apfel zu beißen und auf die Dienste der beiden großen Hersteller mobiler Betriebssysteme zurückzugreifen.

Abbildung 5: Mobilen Geräten kommt in Zero-Trust-Systemen eine zentrale Rolle zu. Um einen Device-Manager wie Googles Setup für Android kommt der Admin kaum herum. Quelle: Google

Abbildung 6: Auch Apple bietet für iOS-Geräte seit längerer Zeit die Möglichkeit, per Fernwartung eine Policy Compliance mit bestimmten Regeln zu erzwingen. Quelle: Apple

Selbst bauen oder kaufen?

Bis hierhin hat dieser Artikel die grundlegenden Ideen hinter Zero Trust beleuchtet und Möglichkeiten erläutert, diese lokal umzusetzen. Zur Einführung von Zero Trust gibt es jedoch auch andere Möglichkeiten. Auf dem Markt existieren mehrere Firmen, die ihre Zero-Trust-Architektur öffentlich dokumentiert haben. Google gilt mit seinem Beyond Corp genannten Prinzip sogar als Vorreiter und hat in bekannter Manier Zero Trust längst in ein Produkt mit allen Schikanen gepresst.

Wer Zero Trust schnell und umfassend einführen möchte, kann also Google mit der Umsetzung beauftragen. Die Sache hat freilich einen Haken: Für alltägliche Dienste wie E-Mails oder Office-Anwendungen landet man, wenn man bei Google bestellt, zwangsläufig in deren Wolke. Die ist allerdings a priori perfekt auf Zero Trust vorbereitet, weil sie etwa die Anbindung an Active Directory oder andere Authentifizierungsmechanismen ermöglicht und dann über alle Dienste des “Googleverse” eine durchgängige Rechteverwaltung implementiert.

Doch neben Google unterstützen längst auch andere Dienstleister Unternehmen gegen Einwurf von Münzen bei der Migration hin zu Zero Trust. Dabei reicht das Angebot von bloßer Beratung bis hin zu fertigen Suites auf Cloud-Basis. Zumindest für die US-basierten Anbieter muss man allerdings stets den Faktor im Hinterkopf behalten, dass der US CLOUD Act und die DSGVO sich nicht unter einen Hut bringen lassen. Für europäische Unternehmen gilt damit, dass der Umstieg auf Zero Trust keinesfalls ein Selbstläufer ist, sondern eine langfristige Planung im Vorfeld bedingt.

Komplex, aber nötig

Unternehmen sei trotzdem wärmstens ans Herz gelegt, sich schnellstens mit dem Thema zu befassen. Hysterisch gewachsene Firewall-Regeln auf mehreren Ebenen, die kein Mensch mehr versteht (und deren Urheber schon lange nicht mehr im Unternehmen arbeiten), komplett überlastete VPN-Gateways und mögliche Angriffe aus dem Innern eines Unternehmens sind reale Probleme und verursachen viel Aufwand. Das verdeutlicht unmissverständlich, dass Sicherheitskonzepte aus den 1990-ern kaum den Anforderungen von 2022 entsprechen.

Obendrein befindet sich Europa hier einmal mehr im Hintertreffen. Technologiefirmen aus den USA oder Asien setzen Zero-Trust-Modelle seit Jahren erfolgreich ein. Während man hierzulande noch über Passwortrichtlinien philosophiert und sich über lahme VPN-Verbindungen ärgert, sind anderswo zentrale Dienste längst uneingeschränkt und deutlich sicherer verfügbar. Freilich: Die Migration hin zu Zero Trust erweist sich als mühsam und langwierig. Hier sollte der Grundsatz “lieber ein Ende mit Schrecken als ein Schrecken ohne Ende” gelten. Dafür ist es gerade in der deutschen Corporate-IT allerhöchste Eisenbahn. (jcb/jlu)