Sicherheit

Verwaltung der Kennwörter gemeinsam genutzter Konten

Chris Stoneff

Auf einen Blick:

• Risiken für Kennwörter gemeinsam genutzter und privilegierter Konten
• Speicherung von Kennwörtern
• Verwalten und Sichern gemeinsam genutzter Kennwörter
• Einhaltung von Bestimmungen

Inhalt

Beschreibung des Problems
Je länger, desto besser
Domänengewalt
Immer wieder Entschuldigungen
Was rechtliche Bestimmungen fordern
Ein automatisierter Ansatz
Denken Sie darüber nach

Eines der Probleme, mit denen sich Administratoren immer öfter befassen müssen, ist das regelmäßige Ändern des Kennworts für gemeinsam genutzte und privilegierte Konten, wie z. B. für das integrierte

Administrator- oder root-Konto, ein Firecallkonto oder vielleicht sogar ein Prozesskonto. Das vordefinierte Administrator- oder root-Konto ist das Konto, das in jeder Version von Windows®, Linux und UNIX vorhanden ist. Es hat immer die gleiche Sicherheits-ID (SID) oder Benutzer-ID (User Identifier, UID). Firecallkonten sind Konten, die Sie erstellen, um den Notfallzugriff auf ein sicheres System zu vereinfachen. Diese Firecall- oder Administratorkonten werden manchmal von ansonsten weniger privilegierten Benutzern verwendet, um Zugriff auf Schlüsselsysteme zu erlangen, wenn ein Problem vorliegt. Prozesskonten sind jene Konten, die Sie verwenden, um Dienste, Aufgaben, COM+-Anwendungen und eingebettete Elemente auszuführen, wie z. B. Skripts und andere Binärdateien, die einer Anmeldung bedürfen.

Sie haben Ihre Systeme wahrscheinlich mithilfe von Installationsskripts oder Installationsabbildern bereitgestellt. Außerdem besitzen alle Ihre Arbeitsstationen oder Server wahrscheinlich den gleichen Administratorkontonamen und das gleiche, aus 8 Zeichen bestehende Kennwort, das höchstwahrscheinlich seit der ersten Bereitstellung der Systeme nicht mehr geändert wurde. Aus diesem Grund verwende ich den Begriff „Kennwort“ in der Einzahl, statt von „Kennwörtern“ zu sprechen.

Ein Administrator könnte diese Kennwörter ändern, um bewährte Methoden umzusetzen oder um rechtlichen Bestimmungen zu entsprechen, wie z. B. dem Sarbanes-Oxley Act (SOX), dem Payment Card Industry Data Security Standard (PCI) oder dem Health Insurance Portability and Accountability Act (HIPAA). Manchmal führt ein Administrator entsprechende Schritte durch, wenn ein Administrator oder Techniker, der diese Kennwörter kennt, das Unternehmen verlässt, weil befürchtet wird, dass die Existenz einer Sicherheitslücke allgemein bekannt werden könnte oder dass das Unternehmen die Möglichkeit zur Verarbeitung von Kreditkarten verlieren könnte. Trotz dieser Faktoren sollte der Administrator schon allein deswegen diese Kennwörter ändern, um die Sicherheit des Unternehmens sowie der Daten, die das Unternehmen schützen muss, zu gewährleisten.

Beschreibung des Problems

Es gibt einige Faktoren, die Sie verstehen müssen, wenn Sie mit diesen Konten und ihren Kennwörtern zu tun haben:

1. Je älter ein Kennwort ist, desto unsicherer ist es.
2. Längere Kennwörter sind im Allgemeinen schwerer zu knacken.
3. Wie Computer die Authentifizierung durchführen, ändert sich nicht einfach deshalb, weil sie einer Domäne angehören. Jede Domäne ist im Grunde eine Arbeitsgruppe.

„Je älter ein Kennwort ist, desto unsicherer ist es“, ist eine irreführende Aussage. Was dieser Satz wirklich bedeutet, ist, dass es nur eine Frage der Zeit ist, bis es gelingt, in einen Computer einzubrechen, sofern der entsprechende Wille vorhanden ist. Wenn jemand fragt, wie lange es dauert, ein Kennwort zu knacken, sage ich gewöhnlich, dass es darauf keine definitive Antwort gibt. Stattdessen nenne ich einige Faktoren, die helfen können, die Frage für ein bestimmtes System zu beantworten:

• Wie viele Personen kennen das Kennwort?
• Arbeiten alle diese Personen immer noch für das Unternehmen?
• Wenn einige der Personen, die das Kennwort des Kontos kennen, nicht mehr für das Unternehmen arbeiten, haben sie das Unternehmen im Guten verlassen?
• Verhindern Sie das Starten von Diskette, über das CD- bzw. DVD-Laufwerk oder über das Netzwerk?
• Sind die Benutzer der Computer auch lokale Administratoren?
• Verwenden alle Ihre Systeme genau das gleiche Kennwort für ihre privilegierten Konten?

Am Anfang der Liste beginnend, kann man sagen, je mehr Personen ein Geheimnis kennen, desto wahrscheinlicher ist es, dass das Geheimnis allgemein bekannt wird. Ich habe für Unternehmen gearbeitet, deren Administratoren es vorzogen, das gemeinsame Kennwort auf denselben Wert zu setzen und dem IT-Personal sowie den Praktikanten mitzuteilen, wie die Kennwörter lauten, statt die Kennwörter bei Bedarf an ihrer Stelle einzutippen. Mit der Zeit tauchten im Unternehmen Computer mit verschiedenen nicht genehmigten Einstellungen auf, und es gab gewöhnliche Netzwerkbenutzer, die in der Lage waren, sich bei diesen Konten anzumelden.

Wenn alle Personen, die die Kennwörter kennen, immer noch für das Unternehmen arbeiten und zufriedene, pflichtbewusste Mitarbeiter sind, wird dieses Zugriffsrisiko ein wenig verringert. Aber es kann immer passieren, dass Sie es mit einem böswilligen Benutzer zu tun bekommen. Wenn irgendeiner dieser Benutzer das Unternehmen nicht im Guten verlassen hat, gibt es ein unkontrolliertes, schädliches Element, das in der Lage ist, mit einem nicht nachverfolgbaren Konto in Ihr Netzwerk einzubrechen.

Wenn Sie das Starten von etwas anderem als von der Festplatte nicht unterbinden, ermöglichen Sie das Starten der Computer mithilfe nicht autorisierter Abbilder, wie z. B. Windows PE oder verschiedener Linux-Systeme, die das Dateisystem des Computers direkt lesen und Zugriff auf den gesicherten Speicher des Computers erlangen können. (Ich sollte darauf hinweisen, dass viele Sicherheitsverletzungen interne Ursachen haben. Selbst wenn alle Mitarbeiter und Praktikanten immer noch im Unternehmen arbeiten, bietet das keine Garantie dafür, dass die Kennwörter und die Systeme sicher sind.)

Ich habe viele Personen getroffen, die sich weiterhin beim Netzwerk eines früheren Arbeitgebers angemeldet haben, nur weil sie es konnten. Dies ist insofern ein wenig amüsant, als sie das Problem der zweifelhaften Praxis aufzeigen, Systemkennwörter nicht zu ändern. Es ist aber auch erschreckend, wenn man bedenkt, welchen Schaden sie anrichten könnten, wenn sie böswillige Absichten hätten.

Wenn Sie es ermöglichen, Computer von einer DVD oder über das Netzwerk zu starten, können Sie u. U. nicht überwachen, was Benutzer tun. Das bedeutet, dass ein Benutzer mit einer Linux-Startdiskette oder einem Netzwerkabbild oft direkten Zugriff auf Ihrem Dateisystem erlangen kann. Wenn Ihre Systeme für ihre privilegierten Konten den gleichen Benutzernamen und das gleiche Kennwort verwenden, ist die Katastrophe vorprogrammiert. Mehr dazu aber später.

Die Relevanz des Alters und der Länge der Kennwörter hängt von der Methode ab, die zum Knacken eines Kennworts verwendet wird. Wenn eine Brute-Force-Methode eingesetzt wird, um Kennwörter zu ermitteln, ist alles im Wesentlichen eine Frage der Zeit. Je seltener ein Kennwort geändert wird, desto mehr Zeit steht dem Angreifer für das Knacken des Kennworts zur Verfügung.

Entsprechend weisen längere Kennwörter exponentiell mehr Zeichenvariationen auf und erfordern deshalb mehr Zeit, um geknackt zu werden. So ist es wichtig, darauf zu achten, ob Ihre Kennwörter weniger als 7 Zeichen, 8 bis 14 Zeichen oder 15 bzw. mehr Zeichen umfassen. Wenn die Kennwörter weniger als 15 Zeichen lang sind und Sie Windows verwenden: Deaktivieren Sie LM-Hashes (LAN-Manager) als Teil der Systemkonfiguration oder innerhalb der Gruppenrichtlinie?

Welchen Einfluss hat die Länge des Kennworts? Im Fall von Windows ist die Antwort einfach. Wenn wir die Geschichte der Microsoft-Hashingprozesse einmal weglassen, lässt sich sagen, dass Microsoft zwei Arten von Hashes für Kennwörter implementiert: LM-Hashes und MD4-Hashes (Message Digest 4). Standardmäßig verwendet Microsoft LM-Hashes, und die Werte werden für alle Kennwörter mit einer Länge bis zu 14 Zeichen gespeichert, es sei denn Sie deaktivieren explizit die Speicherung dieser Hashes. Diese Kennwörter werden in zwei Werte mit je 7 Zeichen unterteilt – den ersten Wert für die ersten 7 Zeichen und den zweiten Wert für die zweiten 7 Zeichen (siehe Abbildung 1).

Abbildung 1 Beispiel einer Hashtabelle

Wenn Ihr Kennwort also nur 7 Zeichen lang ist, wäre es in einem einzigen LM-Hash enthalten. Seit Jahren empfiehlt Microsoft das Verwenden von mindestens 8 Zeichen in Kennwörtern. Der Grund bestand darin, dass das 8. Zeichen dafür sorgen würde, dass das Kennwort in zwei LM-Hashwerte geteilt wird.

Es ist aber wichtig festzuhalten, dass LM-Hashes allgemein verstanden werden und sehr leicht zu umgehen sind. Ihr einziger Zweck besteht in aktuellen Lösungen darin, zur Abwärtskompatibilität mit Legacysystemen wie z. B. Windows NT® 4.0 beizutragen.

Heutzutage sollten Sie Kennwörter (oder vielmehr Kennsätze) mit mindestens 15 oder vorzugsweise noch mehr Zeichen verwenden, weil für sie definitionsgemäß kein LM-Hash generiert wird. Wenn es in Ihrer Umgebung keine realistische Option ist, die Verwendung von Kennwörtern mit mindestens 15 Zeichen erforderlich zu machen, sollten Sie die Speicherung der LM-Hashes sowohl im Abbilderstellungsprozess (mithilfe einer lokalen Richtlinie) als auch in Ihrer Active Directory®-Gruppenrichtlinie deaktivieren.

Diese Richtlinie befindet sich unter Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen. Setzen Sie einfach die Richtlinie „Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern“ auf AKTIVIERT.

Es ist wichtig, sich zu erinnern, dass eine gute Richtlinie zwar die Verwendung von Groß- und Kleinbuchstaben sowie Ziffern oder Sonderzeichen vorschreibt, dass aber eine noch bessere Richtlinie eine Kennwortlänge von mindestens 15 Zeichen erzwingt.

Je länger, desto besser

Eine derzeit verwendete Methode zum Eindringen in Computer wird „Rainbow Tables“ (Regenbogentabellen) genannt und nutzt die LM-Hashes aus. Längere Kennwörter können aber die Wirksamkeit von Regenbogentabellen negieren.

Ich bin überrascht, wie viele Administratoren, die für die Sicherheit verantwortlich sind, sehr wenig (oder nichts) über Regenbogentabellen zu wissen scheinen. Es gibt verschiedene Möglichkeiten, Regenbogentabellen zur Behandlung verschiedener Algorithmen zu erstellen. Aber dabei handelt es sich lediglich um eine im Voraus berechnete Liste aller LM-Hashes für Kennwörter mit 0 bis 14 Zeichen.

Voraussetzung für die Verwendung von Regenbogentabellen ist, dass der Angreifer zunächst die LM-Hashes ermittelt kann. Dies führt zur bereits erwähnten Frage, wie das System gestartet werden kann (mittels CD oder DVD) oder ob Ihre Benutzer lokale Administratoren sind. Letzten Endes können diese LM-Hashes in wenigen Sekunden mithilfe frei verfügbarer Tools (wie z. B. pwdump) extrahiert werden. Unter Verwendung von Regenbogentabellen werden dann die Hashes durchsucht, um das Kennwort zu ermitteln.

Um meine eigene Neugier zu befriedigen, habe ich ein Kennwort für das vordefinierte Administratorkonto eines Systems festgelegt. Es umfasste 14 Zeichen und enthielt verschiedene Groß- und Kleinbuchstaben sowie Sonderzeichen und Ziffern. Ich verwendete dann Regenbogentabellen, die ich kostenlos über das Internet heruntergeladen hatte, und es gelang mir, die Kennworthashes für alle Konten auf meinem System zu extrahieren und das Kennwort des Administratorkontos in weniger als zwei Minuten zu ermitteln.

Ich muss zugeben, dass es großen Spaß macht zuzusehen, wie der erste LM-Hash geknackt wird, gefolgt vom zweiten Hash, und wenn Sie sie dann kombinieren, haben Sie das Kennwort. Um es noch einmal zu wiederholen: Wenn ich meine LM-Hashes, wie oben diskutiert, mithilfe der Richtlinie deaktiviert hätte, hätte ich diese Angriffsmethode enorm erschwert, wenn nicht gar unmöglich gemacht.

Domänengewalt

Dadurch, dass Sie sich in einer Domäne befinden, wird das Problem nicht behoben. Computer in einer Domäne führen die Authentifizierung immer noch auf die gleiche Weise durch. Wie bereits erwähnt, ist jede Domäne im Grunde eine Arbeitsgruppe. Diese einfache Aussage ist nicht immer offensichtlich. Ich habe viele Unterhaltungen über dieses Thema geführt, und ich stelle fest, dass ich oft Administratoren daran erinnere, was für den Zugriff auf einen Computer erforderlich ist – ein Benutzername und ein Kennwort. Dann muss ich im Detail erörtern, wie Windows in einer Arbeitsgruppe funktioniert.

Wenn Sie versuchen, auf ein System zuzugreifen, müssen Sie für das Remotesystem einen Benutzernamen und ein Kennwort bereitstellen. Bei Verwendung der integrierten Authentifizierung versucht Windows, dies für Sie zu tun. Dies bedeutet, dass, wenn Sie auf ein anderes Windows-System zugreifen, Windows Ihren derzeit für die Anmeldung verwendeten Benutzernamen und das zugehörige Kennwort verwendet. Wenn Sie also versuchen, auf ein anderes Windows-System zuzugreifen, werden Sie nie aufgefordert, diesen Benutzernamen und dieses Kennwort einzugeben, wenn das Remotesystem den gleichen Benutzernamen und das gleiche Kennwort aufweist.

Dies wird auch als Pass-Through-Authentifizierung bezeichnet. Der Prozess funktioniert sowohl in Arbeitsgruppen als auch domänenübergreifend. Im schlimmsten Fall fragt Sie das System nach einem Benutzernamen und einem Kennwort, was bedeutet, dass Sie einfach Ihre Anmeldeinformationen erneut eingeben müssen.

Selbst wenn Sie eine Arbeitsstation oder einen Server einer Domäne hinzufügen und Active Directory zu Ihrem zentralen Kontorepository wird, verschwinden nicht einfach auf magische Weise alle lokalen Sicherheitskontenverwaltungen (Security Account Managers, SAMs) oder lokalen Kontospeicher auf diesen Systemen. Das Einzige, was mit diesen lokalen SAMs zu geschehen scheint, ist, dass sie nicht mehr verwaltet und gesichert sind, und darin liegt die Ursache des Problems. Wann haben Sie das letzte Mal das integrierte Administrator- oder root-Konto auf Ihren Systemen geändert? Laden Sie besser noch irgendein Berichterstattungs-Dienstprogramm herunter, das Ihnen zeigen kann, wie alt die Kennwörter aller Ihrer Konten sind, und stellen Sie fest, ob die Ergebnisse einer Überprüfung standhalten würden.

Wenn Sie immer noch nicht ganz sicher sind, was ich meine, melden Sie sich über ein Domänenkonto mit Administratorrechten bei irgendeiner Ihrer Domänenarbeitsstationen an. Öffnen Sie die Computerverwaltung auf Ihrem System, und erstellen Sie einen lokalen Benutzer namens „ToldYouSo“. Geben Sie dem Konto ein Kennwort, und fügen Sie es der lokalen Administratorgruppe Ihres Systems hinzu. Wiederholen Sie diesen Prozess auf einem zweiten Domänensystem.

Melden Sie sich nun von einem dieser Systeme mit dem lokalen ToldYouSo-Konto an, und versuchen Sie, auf den zweiten Computer zuzugreifen, indem Sie zu \\systemName\c$ wechseln. Sie können nun auf die administrative Freigabe zugreifen, und Sie werden nicht einmal aufgefordert, ein Kennwort einzugeben! Ich hoffe, dieses Beispiel ist für Sie keine Überraschung. Aber wenn es eine ist, lernen Sie bitte daraus, und lassen Sie mich noch einmal wiederholen: Nur weil Ihr System einer Domäne angehört, ändert dies nichts daran, dass alle diese Systeme immer noch so funktionieren, als ob sie einer Arbeitsgruppe angehören würden.

Der Punkt ist, dass, wenn Sie für Ihre gemeinsam genutzten und privilegierten Konten Kennwörter verwenden, die (wenn überhaupt) nur selten geändert werden, Ihre gemeinsam genutzten und privilegierten Konten gefährdet sind. Alles, was nötig ist, um Ihr gesamtes Netzwerk zu beeinträchtigen, ist Zeit.

Immer wieder Entschuldigungen

Wenn ich mit Administratoren und sogar mit den Hauptverantwortlichen für den IT-Bereich rede, höre ich oft die gleichen Hauptgründe, weshalb diese Kontokennwörter nicht geändert werden:

• Wir haben Tausende von Systemen und nicht genug Zeit oder genügend Mitarbeiter, um diese Konten zu ändern.
• Wir haben nicht das notwendige Budget.
• Wir haben unsere Administratorkonten vollständig deaktiviert.
• Wir wurden noch nie erfolgreich angegriffen. Deshalb denken wir, dass nicht wirklich ein Problem besteht.
• Die Prüfer haben es nicht bemerkt.

Obwohl ich die ersten zwei Gründe in gewisser Weise nachvollziehen kann, sind dies keine akzeptablen Entschuldigungen. Ich zittere bei dem Gedanken, dass meine persönlichen Informationen bei Unternehmen gespeichert sein könnten, die sich aus irgendeinem Grund nicht mit diesem Problem befassen.

Obwohl es stimmt, dass nicht auf jedem System in Ihrem Netzwerk vertrauliche Informationen gespeichert sind, haben die Benutzer dieser Computer möglicherweise Zugriff auf vertrauliche Informationen, wie z. B. Ihre Sozialversicherungsnummer, Ihre Krankheitsgeschichte oder Ihre Finanzdaten. Als Administrator eines Systems kann ein Benutzer Key Logger und Dienstprogramme zur Bildschirmaufzeichnung installieren, die Anwendung der Gruppenrichtlinie verhindern, Shims in verschiedene Subsysteme einführen, um Daten aufzuzeichnen und zu übertragen, und so weiter. Wenn der Benutzer dies auf einem einzelnen Computer tut, ist es für Sie viel schwieriger, diesen böswilligen Benutzer zu ermitteln, da er sich Administrator nennt.

Wussten Sie, dass das Deaktivieren des vordefinierten Administratorkontos in Windows nicht verhindert, dass Sie sich mit diesem Konto anmelden können? Probieren Sie Folgendes aus: Starten Sie Ihr System im abgesicherten Modus neu, und melden Sie sich mit dem vordefinierten Administratorkonto an. Sie können wahrscheinlich erfolgreich das Kennwort verwenden, das dem Konto vom ursprünglichen Abbild zugewiesen wurde. Weitere Informationen zu diesem Verhalten finden Sie im Microsoft® Knowledge Base-Artikel „Zugreifen auf den Computer nach dem Deaktivieren des Administratorkontos“ (support.microsoft.com/kb/814777).

Was rechtliche Bestimmungen fordern

Von Bestimmungen wie SOX, PCI, HIPAA und anderen kann einem schwindlig werden. Die Anforderungen zu verstehen, kann sehr schwierig sein, da sie sehr umfangreich und nicht klar definiert sind. Was alle diese Bestimmungen fordern, kann im Allgemeinen folgendermaßen zusammengefasst werden.

Zunächst müssen Sie jederzeit nachweisen können, wer Zugriff auf sämtliche privilegierten Konten und Informationen hat, und eine Methode bereitstellen, um dies zu beweisen. Dies ist in allen Szenarios ein guter Ansatz – ein privilegiertes Konto ist ein Konto mit der Berechtigung, auf jedem System jede beliebige Aktion durchzuführen. Dies ist das vordefinierte Administratorkonto. Dies ist das Firecallkonto. Diese sind die Konten, die alle Ihre Helpdeskmitarbeiter und jeder Administrator, der für Sie arbeitet, wahrscheinlich kennen.

Wenn Sie sich entscheiden, eine Lösung zu implementieren, um diese Kennwörter gemeinsam genutzter Konten zu verwalten, erstellen Sie einen Überwachungspfad zum vordefinierten Administratorkonto, wo derzeit keiner existiert. Sie erhalten ein Kennwort, das variabel ist. Da die Lösung automatisiert ist, kostet es Sie nicht Wochen an Arbeitszeit, diese Kennwörter zu ändern. Da die Lösung Überwachungsfunktionen bietet, kommt Ihr Unternehmen letzten Endes dem Bestehen der Überprüfung einen Schritt näher.

Ein automatisierter Ansatz

Die effektivste Möglichkeit, entsprechende Probleme bei Konten wie diesen zu vermeiden, besteht darin, die Konten regelmäßig zu ändern, damit zwei Konten niemals das gleiche Kennwort aufweisen. Bei gemeinsam genutzten Kennwörtern würde die Beeinträchtigung eines Systems auch die Beeinträchtigung eines anderen bedeuten. Anders gesagt, es sollte keine allgemeinen lokalen Konten oder Domänenkonten geben.

Wenn Sie mit automatisierten Lösungen arbeiten, die diese Kennwörter verwalten und randomisieren können, vermeiden Sie, nur das absolute Minimum dessen zu tun, was die Prüfer fordern. Warum z. B. nur 8 Zeichen für Ihre Kennwörter verwenden, wenn Sie ohne jegliche zusätzliche Anstrengung 15 oder 20 oder 127 verwenden können (siehe Abbildung 2)?

Abbildung 2 Verwendung von Automatisierung zur Erstellung sehr langer Kennwörter (zum Vergrößern auf das Bild klicken)

Erwägen Sie auch, Ihre privilegierten Konten jeden Tag zu randomisieren (siehe Abbildung 3). Es gibt keinen Grund, dies nur alle 90 Tage zu tun, wenn Sie es monatlich oder halbmonatlich oder sogar täglich tun können. Wenn das Verfahren automatisiert ist, sollte schließlich keine zusätzliche Arbeit für Sie entstehen. Wenn Sie dies regelmäßig tun, zwingen Sie außerdem die Benutzer, die Kennwörter über die überwachte Abrufschnittstelle des Tools wiederherzustellen, wodurch ein Überwachungspfad bereitgestellt wird, wo zuvor keiner vorhanden war. (Wenn Sie gegenwärtig geschriebene Kennwörter in einem Umschlag in einem Safe in der hinteren Ecke von jemandes Büro aufbewahren, haben Sie keinen Überwachungspfad für diese Kennwörter, wie Sie ihn hätten, wenn Sie eine Kennwortverwaltungslösung verwenden würden.)

Abbildung 3 Randomisieren Sie Ihre privilegierten Konten täglich (zum Vergrößern auf das Bild klicken)

Stellen Sie abschließend sicher, dass, wenn Kennwörter wiederhergestellt werden, sie nach einem festgelegten Zeitraum nach der Wiederherstellung erneut randomisiert werden. Ich meine nicht die geplanten Randomisierungsaufträge, die Sie erstellt haben. Ich spreche vom Erstellen von Einmalkennwörtern, die nur für ein paar Stunden statt für einige Monate gültig sind. Diese Methode zwingt die Benutzer wiederum, die Kennwörter über die überwachte Abrufschnittstelle des Tools wiederherzustellen, wodurch ein Überwachungspfad bereitgestellt wird.

Denken Sie darüber nach

Das Problem der Verwaltung der Kennwörter gemeinsam genutzter Konten darf nicht ignoriert werden. Dies bedeutet, dass Sie eine Methode haben sollten, um Ihre Kennwörter zuverlässig und regelmäßig zu ändern. Die Lösung muss skalierbar und flexibel sein. Sie muss auch einen gesicherten Zugriff auf die Kennwörter bieten und muss jede Aktion überwachen, die vom Tool sowie von jedem Benutzer des Tools durchgeführt wird. Außerdem müssen die generierten Kennwörter auf jedem System eindeutig sein, um ein Eindringen infolge gemeinsam genutzter Kontoinformationen zu vermeiden.

Viele Anbieter befassen sich seit Jahren mit diesem Problem, und in jüngster Zeit haben sich viele neue Anbieter dieses Problems angenommen. Halten Sie sich unbedingt auf dem aktuellen Stand, und probieren Sie alle neuen Tools aus, bevor Sie eines erwerben, um sicherzustellen, dass die Lösung, für die Sie sich entscheiden, für Ihre Umgebung die richtige ist.

Chris Stoneff ist Produktmanager bei Lieberman Software (liebsoft.com), einem Softwareentwickler im Bereich Sicherheit und Systemverwaltung. Sein Interesse gilt nicht nur der Frage, wie etwas auf eine bestimmte Weise funktioniert, sondern auch warum das so ist.