Planen der Gefährdung
Regel Nummer 1: Niemand glaubt, dass ihm oder ihr etwas Schlimmes zustoßen kann, bis es geschieht. - 10 unumstößliche Gesetze der Sicherheitsverwaltung
In vielen Organisationen sind Notfallwiederherstellungspläne vor allem auf die Wiederherstellung nach regionalen Katastrophen oder Ausfällen ausgerichtet, die zum Verlust von Computingdiensten führen. Bei der Arbeit mit einer beeinträchtigten Kundschaft stellen wir jedoch häufig fest, dass die Wiederherstellung nach absichtlicher Beeinträchtigung in den Notfallwiederherstellungsplänen fehlt. Dies gilt insbesondere, wenn die Beeinträchtigung zu einem Diebstahl geistigen Eigentums oder einer absichtlichen Zerstörung führt, die logische Grenzen (z. B. Zerstörung aller Active Directory-Domänen oder aller Server) und nicht physische Grenzen (z. B. Zerstörung eines Rechenzentrums) betrifft. Eine Organisation hat möglicherweise Pläne zur Reaktion auf Vorfälle, in denen erste Aktivitäten beim Auffinden einer Beeinträchtigung definiert sind, darin werden jedoch häufig Schritte zur Wiederherstellung nach einer Beeinträchtigung, die sich auf die gesamte Computerinfrastruktur auswirkt, ausgelassen.
Da Active Directory umfassende Identitäts- und Zugriffsverwaltungsfunktionen für Benutzer*innen, Server, Arbeitsstationen und Anwendungen bietet, ist es ein häufiges Ziel für Angreifer*innen. Wenn Angreifer*innen Zugriff auf eine Active Directory-Domäne oder einen Active Directory-Domänencontroller erhalten, kann darüber auf die gesamte Active Directory-Gesamtstruktur zugegriffen werden, sie kann kontrolliert oder sogar zerstört werden.
In diesem Dokument wurden bereits einige der häufigsten Angriffe gegen Windows und Active Directory sowie Gegenmaßnahmen erläutert, die Sie implementieren können, um Ihre Angriffsfläche zu verringern. Die einzige sichere Möglichkeit, nach einer vollständigen Beeinträchtigung von Active Directory den Betrieb wiederherzustellen, besteht darin, sich auf sie vorzubereiten, bevor sie eintritt. Dieser Abschnitt beschäftigt sich weniger mit Details zur technischen Implementierung als vorherige vorherigen Abschnitte dieses Dokuments und mehr mit allgemeinen Empfehlungen, über die Sie einen ganzheitlichen, umfassenden Ansatz zum Schützen und Verwalten der kritischen Geschäfts- und IT-Ressourcen Ihrer Organisation erstellen können.
Unabhängig davon, ob Ihre Infrastruktur noch nie angegriffen wurde, versuchte Sicherheitsverletzungen erfolgreich abgewehrt hat oder bereits Opfer von Angriffen geworden ist und vollständig kompromittiert wurde, sollten Sie für die unvermeidliche Tatsache planen, dass Sie immer wieder angegriffen werden. Angriffe lassen sich nicht verhindern. Aber es ist unter Umständen möglich, erheblichen Verstöße oder umfassenden Beeinträchtigungen vorzubeugen. Jede Organisation sollte ihre bestehenden Risikomanagementprogramme genau bewerten und die erforderlichen Anpassungen vornehmen, um ihr Gesamtrisikoniveau zu verringern, indem sie ausgewogene Investitionen in die Verhinderung, Erkennung, Eindämmung und Wiederherstellung tätigt.
Um effektive Schutzmaßnahmen zu schaffen und gleichzeitig Dienste für die von Ihrer Infrastruktur und Ihren Anwendungen abhängigen Benutzer*innen und Unternehmen bereitzustellen, müssen Sie möglicherweise neue Möglichkeiten zum Verhindern, Erkennen und Eindämmen von Beeinträchtigungen in Ihrer Umgebung in Betracht ziehen, um den Betrieb anschließend wiederherzustellen. Die Ansätze und Empfehlungen in diesem Dokument helfen Ihnen möglicherweise nicht dabei, eine beeinträchtigte Active Directory-Installation zu reparieren, sie können Ihnen aber dabei helfen, Ihre nächste Installation zu schützen.
Empfehlungen zum Wiederherstellen einer Active Directory-Gesamtstruktur werden unter AD-Gesamtstrukturwiederherstellung: Schritte zum Wiederherstellen der Gesamtstruktur vorgestellt. Sie können ggf. verhindern, dass Ihre neue Umgebung vollständig kompromittiert wird. In jedem Fall verfügen Sie aber über Tools, um den Betrieb wiederherzustellen und die Kontrolle über Ihre Umgebung zurückzuerlangen.
Neues Überdenken des Ansatzes
Regel Nummer 8: Die Schwierigkeit der Verteidigung eines Netzwerks ist direkt proportional zu seiner Komplexität. - 10 unumstößliche Gesetze der Sicherheitsverwaltung
Es besteht allgemein Einigkeit, dass ein Computer, auf dem Angreifer*innen System-, Administrator- oder Root-Zugriff bzw. einen gleichwertigen Zugriff erlangt haben, unabhängig vom Betriebssystem nicht mehr als vertrauenswürdig betrachtet werden kann – ganz egal, wie viel Aufwand zur Bereinigung des Systems betrieben wird. Active Directory ist davon nicht ausgenommen. Wenn ein*e Angreifer*in privilegierten Zugriff auf einen Domänencontroller oder ein Konto mit umfassenden Berechtigungen in Active Directory erhalten hat, können Sie das Verzeichnis nicht mehr in einen vollständig vertrauenswürdigen Zustand zurückführen, sofern Sie nicht über eine Aufzeichnung aller durch die angreifende Person vorgenommenen Änderungen oder eine bekanntermaßen gute Sicherung verfügen.
Wenn ein Mitgliedsserver oder eine Arbeitsstation in einem Angriff beeinträchtigt und verändert wird, ist der Computer nicht mehr vertrauenswürdig, aber benachbarte, nicht gefährdete Server und Arbeitsstationen können weiterhin vertrauenswürdig sein. Die Kompromittierung eines einzelnen Computers bedeutet nicht unbedingt, dass alle Computer kompromittiert sind.
In einer Active Directory-Domäne hosten jedoch alle Domänencontroller Replikate derselben AD DS-Datenbank. Wenn ein einziger Domänencontroller beeinträchtigt und bei einem Angriff die AD DS-Datenbank geändert wird, werden diese Änderungen auf alle anderen Domänencontroller in der Domäne repliziert. Abhängig von der Partition, in der die Änderungen vorgenommen werden, kann das auch die Gesamtstruktur betreffen. Selbst wenn Sie jeden Domänencontroller in der Gesamtstruktur neu installieren, installieren Sie nur die Hosts neu, auf denen sich die AD DS-Datenbank befindet. Böswillige Änderungen an Active Directory werden genau so einfach auf neu installierten Domänencontrollern repliziert wie auf Domänencontrollern, die seit Jahren ausgeführt werden.
Bei der Bewertung beeinträchtigter Umgebungen stellen wir häufig fest, dass das vermutete erste Sicherheitsverletzungsereignis tatsächlich Wochen, Monate oder sogar Jahre, nachdem Angreifer*innen die Umgebung ursprünglich beeinträchtigt haben, ausgelöst wurde. Angreifer*innen erhalten in der Regel die Anmeldeinformationen für Konten mit umfassenden Berechtigungen lange, bevor eine Sicherheitsverletzung erkannt wird. Sie nutzen dann diese Konten, um das Verzeichnis, Domänencontroller, Mitgliedsserver, Arbeitsstationen und sogar verbundene Nicht-Windows-Systeme zu beeinträchtigen.
Diese Erkenntnisse stimmen mit verschiedenen Ergebnissen im Verizon-Bericht 2012 zu Datenverletzungen überein, der Folgendes besagt:
98 % der Datenschutzverletzungen stammen von externen Agenten.
85 % der Datenschutzverletzungen wurden erst nach Wochen oder später entdeckt.
92 % der Vorfälle wurden von einem Drittanbieter entdeckt.
97 % der Verstöße wären durch einfache oder mittlere Kontrollen vermeidbar gewesen.
Eine Beeinträchtigung des zuvor beschriebenen Ausmaßes ist praktisch irreparabel, und der typische Ratschlag, jedes beeinträchtigte System abzubauen und neu zu erstellen, ist einfach nicht umsetzbar oder gar unmöglich, wenn Active Directory beeinträchtigt oder zerstört wurde. Selbst die Wiederherstellung eines bekannten fehlerfreien Zustands beseitigt nicht die Lücken, durch die die Umgebung überhaupt erst kompromittiert werden konnte.
Obwohl Sie jedes Element Ihrer Infrastruktur verteidigen müssen, muss ein*e Angreifer*in lediglich genügend Lücken in Ihrer Verteidigung finden, um zum gewünschten Ziel zu gelangen. Wenn Ihre Umgebung relativ einfach und in makellosem Zustand ist und in der Vergangenheit gut verwaltet wurde, kann die Umsetzung der weiter oben in diesem Dokument enthaltenen Empfehlungen ein einfach umzusetzender Vorschlag sein.
Wir haben jedoch festgestellt, dass es mit dem Alter, der Größe und der Komplexität der Umgebung zunehmend wahrscheinlicher wird, dass die Empfehlungen in diesem Dokument nicht ohne Probleme oder sogar gar nicht umgesetzt werden können. Es ist viel schwieriger, eine Infrastruktur nach einem aufgetretenen Problem zu schützen, als neu zu beginnen und eine Umgebung zu konstruieren, die gegen Angriffe und Kompromittierung resistent ist. Aber wie bereits erwähnt ist es keine Kleinigkeit, eine gesamte Active Directory-Gesamtstruktur neu zu erstellen. Aus diesen Gründen empfehlen wir einen konzentrierteren, zielgerichteteren Ansatz zum Schutz Ihrer Active Directory-Gesamtstrukturen.
Anstatt zu versuchen, alle mit Problemen behafteten Dinge zu reparieren, sollten Sie einen Ansatz in Betracht ziehen, bei dem Sie die für Ihr Unternehmen und Ihre Infrastruktur wichtigsten Elemente priorisieren. Versuchen Sie nicht, die Probleme in einer Umgebung voller veralteter, falsch konfigurierter Systemen und Anwendungen zu korrigieren, sondern erstellen Sie eher eine neue kleine, sichere Umgebung, in die Sie die Benutzer*innen, Systeme und Informationen, die für Ihr Unternehmen am wichtigsten sind, sicher übernehmen können.
In diesem Abschnitt wird ein Ansatz beschrieben, mit dem Sie eine unberührte AD DS-Gesamtstruktur erstellen können, die für Ihre Kerninfrastruktur die Funktion eines „Rettungsboots“ oder einer „Sicherheitszelle“ übernimmt. Eine unberührte Gesamtstruktur ist einfach eine neu installierte Active Directory-Gesamtstruktur, die in der Regel in Größe und Umfang begrenzt ist und mit aktuellen Betriebssystemen, Anwendungen und den unter Reduzieren der Angriffsfläche von Active Directory beschriebenen Prinzipien erstellt wird.
Durch Implementieren der empfohlenen Konfigurationseinstellungen in einer neu erstellten Gesamtstruktur können Sie eine AD DS-Installation schaffen, die von Grund auf mit sicheren Einstellungen und Methoden aufgebaut ist. Dabei können Sie auch die Herausforderungen verringern, die mit der Unterstützung von Legacysystemen und -anwendungen einhergehen. Ausführliche Anweisungen für den Entwurf und die Implementierung einer unberührten AD DS-Installation liegen zwar außerhalb des Rahmens dieses Dokuments, Sie sollten jedoch einige allgemeine Prinzipien und Richtlinien befolgen, um eine „Sicherheitszelle“ zu erstellen, in der Sie Ihre wichtigsten Ressourcen unterbringen können. Diese Richtlinien lauten wie folgt:
Identifizieren von Prinzipien zum Isolieren und Schützen kritischer Ressourcen
Definieren Sie einen begrenzten, risikobasierten Migrationsplan.
Nutzen Sie „nicht migratorische“ Migrationen, sofern notwendig.
Implementieren Sie eine „kreative Zerstörung“.
Isolieren Sie Legacysysteme und -anwendungen.
Vereinfachen Sie die Sicherheit für Endbenutzer.
Identifizieren von Prinzipien zum Isolieren und Schützen kritischer Ressourcen
Die Eigenschaften der unberührten Umgebung, die Sie für die Unterbringung kritischer Ressourcen erstellen, können sehr unterschiedlich sein. Sie können beispielsweise eine unberührte Gesamtstruktur erstellen, zu der Sie nur VIP-Benutzer*innen sowie vertrauliche Daten migrieren, auf die ausschließlich diese Benutzer*innen zugreifen können. Sie können eine unberührte Gesamtstruktur erstellen, zu der Sie nicht nur VIP-Benutzer*innen migrieren, sondern sie als administrative Gesamtstruktur implementieren. Dazu nutzen Sie die unter Reduzieren der Angriffsfläche von Active Directory beschriebenen Prinzipien, um sichere Verwaltungskonten und Hosts zu erstellen, die zum Verwalten Ihrer Legacy-Gesamtstrukturen aus der unberührten Gesamtstruktur verwendet werden können. Sie können eine zweckorientierte Gesamtstruktur implementieren, die VIP-Konten, privilegierte Konten und Systeme mit zusätzlichen Sicherheitsanforderungen enthält, z. B. Server mit Active Directory Certificate Services (AD CS). Das Ziel besteht ausschließlich darin, diese von weniger sicheren Gesamtstrukturen zu trennen. Schließlich können Sie eine unberührte Gesamtstruktur implementieren, die zum faktischen Speicherort für alle neuen Benutzer*innen, Systeme, Anwendungen und Daten wird, sodass Sie Ihre Legacygesamtstruktur schließlich über nach und nach außer Betrieb setzen können.
Unabhängig davon, ob Ihre unberührter Gesamtstruktur einige Benutzer*innen und Systeme enthält oder die Grundlage für eine aggressivere Migration darstellt, sollten Sie bei Ihrer Planung die folgenden Prinzipien befolgen:
Gehen Sie davon aus, dass Ihre Legacygesamtstrukturen beeinträchtigt wurden.
Konfigurieren Sie eine unberührte Umgebung nicht so, dass sie einer Legacygesamtstruktur vertraut. Sie können allerdings eine Legacyumgebung so konfigurieren, dass sie einer unberührten Gesamtstruktur vertraut.
Migrieren Sie keine Benutzerkonten oder Gruppen von einer Legacygesamtstruktur zu einer unberührten Umgebung, wenn die Möglichkeit besteht, dass Gruppenmitgliedschaften, der SID-Verlauf oder andere Attribute der Konten böswillig geändert wurden. Verwenden Sie stattdessen „nicht migratorische“ Ansätze, um eine unberührte Gesamtstruktur aufzufüllen. (Nicht migratorische Ansätze werden weiter unten in diesem Artikel beschrieben.)
Migrieren Sie keine Computer von Legacygesamtstrukturen zu unberührten Gesamtstrukturen. Implementieren Sie in der unberührten Gesamtstruktur neu installierte Server, installieren Sie Anwendungen auf den neu installierten Servern, und migrieren Sie Anwendungsdaten zu den neu installierten Systemen. Kopieren Sie bei Dateiservern Daten auf neu installierte Server, legen Sie ACLs mithilfe von Benutzer*innen und Gruppen in der neuen Gesamtstruktur fest, und erstellen Sie dann Druckserver auf ähnliche Weise.
Lassen Sie keine Installation von Legacybetriebssystemen oder -anwendungen in der unberührten Gesamtstruktur zu. Wenn eine Anwendung nicht aktualisiert und neu installiert werden kann, belassen Sie sie in der Legacygesamtstruktur, und erwägen Sie eine kreative Zerstörung, um die Funktionen der Anwendung zu ersetzen.
Definieren eines eingeschränkten, risikobasierten Migrationsplans
Das Erstellen eines begrenzten, risikobasierten Migrationsplans bedeutet einfach, dass Sie bei der Entscheidung, welche Benutzer*innen, Anwendungen und Daten in Ihre unberührte Gesamtstruktur migriert werden sollen, die Migrationsziele entsprechend dem Risiko für Ihre Organisation identifizieren, wenn Benutzer*innen oder Systeme beeinträchtigt sind. VIP-Benutzer*innen, deren Konten wahrscheinlich von Angreifern ins Visier genommen werden, sollten in der unberührten Gesamtstruktur untergebracht werden. Anwendungen, die wichtige Geschäftsfunktionen bereitstellen, sollten auf neu erstellten Servern in der unberührten Gesamtstruktur installiert werden, und besonders sensible Daten sollten auf gesicherte Server in der unberührten Gesamtstruktur verschoben werden.
Wenn Ihnen die unternehmenskritischen Benutzer*innen, Systeme, Anwendungen und Daten in Ihrer Active Directory-Umgebung noch nicht ganz klar sind, identifizieren Sie sie gemeinsam mit den Geschäftseinheiten. Jede für den Betrieb des Unternehmens erforderliche Anwendung sollte identifiziert werden, ebenso wie alle Server, auf denen kritische Anwendungen ausgeführt oder kritische Daten gespeichert werden. Indem Sie die Benutzer*innen und Ressourcen identifizieren, die für die fortgesetzte Funktion Ihrer Organisation erforderlich sind, erstellen Sie eine auf natürliche Weise priorisierte Sammlung von Ressourcen, auf die Sie sich konzentrieren sollten.
Nutzen von „nicht migratorischen“ Migrationen
Unabhängig davon, ob Ihre Umgebung mit Sicherheit oder vermutlich kompromittiert wurde oder Sie einfach Legacydaten und Objekte aus einer Active Directory-Legacyinstallation nicht zu einer neuen Installation migrieren möchten, sollten Sie Migrationsansätze in Betracht ziehen, bei denen Objekte eigentlich gar nicht migriert werden.
Benutzerkonten
Bei einer herkömmlichen Active Directory-Migration von einer Gesamtstruktur zu einer anderen wird das Attribut SIDHistory (SID-Verlauf) für Benutzerobjekte verwendet, um die SIDs der Benutzer*innen sowie der Gruppen, in denen Benutzer*innen in der Legacygesamtstruktur Mitglieder waren, zu speichern. Wenn Benutzerkonten zu einer neuen Gesamtstruktur migriert werden und auf Ressourcen in der Legacygesamtstruktur zugreifen, wird mithilfe der SIDs im SID-Verlauf ein Zugriffstoken erstellt, über das die Benutzer*innen auf Ressourcen zugreifen können, auf die sie vor der Migration der Konten Zugriff hatten.
Die Verwaltung des SID-Verlaufs hat sich jedoch in einigen Umgebungen als problematisch erwiesen, da das Auffüllen der Zugriffstoken für Benutzer*innen mit aktuellen und historischen SIDs zu Token Bloat führen kann. Dies ist ein Problem, bei dem die Anzahl der im Zugriffstoken eines Benutzers oder einer Benutzerin gespeicherten SIDs den im Token verfügbaren Speicherplatz aufbraucht oder sogar überschreitet.
Die Tokengröße kann zwar in begrenztem Umfang erhöht werden können, die letztliche Lösung für Token Bloat besteht jedoch darin, die Anzahl der mit Benutzerkonten verknüpften SIDs zu verringern. Dies kann durch rationalisierte Gruppenmitgliedschaften, die Beseitigung des SID-Verlaufs oder eine Kombination aus beidem geschehen. Weitere Informationen zu Token Bloat finden Sie unter MaxTokenSize und Kerberos Token Bloat.
Anstatt Benutzer*innen aus einer Legacyumgebung mithilfe des SID-Verlaufs zu migrieren (insbesondere einer Umgebung, in der Gruppenmitgliedschaften und SID-Verläufe beeinträchtigt sein können), sollten Sie sie über Metaverzeichnisanwendungen „migrieren“, ohne SID-Verläufe in die neue Gesamtstruktur zu übertragen. Beim Erstellen von Benutzerkonten in der neuen Gesamtstruktur können Sie die Konten mit einer Metaverzeichnisanwendung den zugehörigen Konten in der Legacygesamtstruktur zuordnen.
Wenn Sie den neuen Benutzerkonten Zugriff auf Ressourcen in der Legacygesamtstruktur gewähren möchten, können Sie über das Metaverzeichnistool Ressourcengruppen identifizieren, auf die die Legacykonten der Benutzer*innen zugreifen konnten, und dann diesen Gruppen die neuen Konten der Benutzer*innen hinzufügen. Abhängig von Ihrer Gruppenstrategie in der Legacygesamtstruktur müssen Sie möglicherweise lokale Domänengruppen für den Ressourcenzugriff erstellen oder vorhandene Gruppen in lokale Domänengruppen konvertieren, um die neuen Konten Ressourcengruppen hinzufügen zu können. Konzentrieren Sie sich zunächst auf die kritischsten Anwendungen und Daten, und migrieren Sie diese zur neuen Umgebung (mit oder ohne SID-Verlauf), um den Aufwand in der Legacyumgebung zu begrenzen.
Server und Arbeitsstationen
Bei einer herkömmlichen Migration von einer Active Directory-Gesamtstruktur zu einer anderen ist die Migration von Computern im Vergleich zur Migration von Benutzer*innen, Gruppen und Anwendungen häufig relativ einfach. Abhängig von der Computerrolle kann die Migration zu einer neuen Gesamtstruktur lediglich das Entfernen aus einer alten Domäne und das Beitreten zu einer neuen Domäne umfassen. Die Migration von intakten Computerkonten zu einer unberührten Gesamtstruktur lässt sich jedoch nicht mit dem Schaffen einer neuen Umgebung vereinbaren. Anstatt Computerkonten (die möglicherweise beeinträchtigt, falsch konfiguriert oder veraltet sind) zu einer neuen Gesamtstruktur zu migrieren, sollten Sie Server und Arbeitsstationen in der neuen Umgebung neu installieren. Sie können Daten von Systemen in der Legacygesamtstruktur zu Systemen in der unberührten Gesamtstruktur migrieren, aber nicht zu den Systemen, in denen die Daten gespeichert werden.
Anwendungen
Anwendungen können die größte Herausforderung bei jeder Migration von einer Gesamtstruktur zu einer anderen darstellen. Bei einer „nicht migratorischen“ Migration sollten Sie jedoch eines der wichtigsten Prinzipien anwenden: Anwendungen in der unberührten Gesamtstruktur sollten aktuell und unterstützt sein und neu installiert werden. Daten können ggf. aus Anwendungsinstanzen in der alten Gesamtstruktur migriert werden. In Situationen, in denen eine Anwendung in der unberührten Gesamtstruktur nicht neu erstellt werden kann, sollten Sie Ansätze wie kreative Zerstörung oder Isolation von Legacyanwendungen in Betracht ziehen, wie im folgenden Abschnitt beschrieben.
Implementieren einer kreativen Zerstörung
Kreative Zerstörung ist ein Begriff aus der Wirtschaft, der eine wirtschaftliche Entwicklung durch Zerstörung einer früheren Ordnung beschreibt. In den letzten Jahren wird der Begriff auch auf die Informationstechnologie angewandt. Er bezieht sich in der Regel auf Mechanismen, über die eine alte Infrastruktur beseitigt wird. Sie wird nicht aktualisiert, sondern durch etwas vollkommen Neues ersetzt. Das Gartner Symposium ITXPO für CIOs und Leitende IT-Führungskräfte 2011 stellte kreative Zerstörung als eines der wichtigsten Themen zur Kostensenkung und Effizienzsteigerung vor. Verbesserungen der Sicherheit sind als natürliches Nebenprodukt des Prozesses möglich.
Beispielsweise kann eine Organisation mehrere Geschäftseinheiten umfassen, die unterschiedliche Anwendungen mit ähnlicher Funktionalität, aber abweichender Modernität und Anbieterunterstützung ausführen. In der Vergangenheit verwaltete die IT-Abteilung möglicherweise die Anwendung jeder Geschäftseinheit separat. Für eine Konsolidierung musste herausgefunden werden, welche Anwendung die beste Funktionalität bietet, um dann Daten von den anderen zu dieser Anwendung zu migrieren.
Bei der kreativen Zerstörung verwalten Sie keine veralteten oder redundanten Anwendungen, sondern Sie implementieren vollkommen neue Anwendungen, die die alten ersetzen, migrieren Daten zu den neuen Anwendungen und setzen die alten Anwendungen sowie die Systeme, auf denen sie ausgeführt wurden, außer Betrieb. In einigen Fällen können Sie die kreative Zerstörung von Legacyanwendungen umsetzen, indem Sie eine neue Anwendung in Ihrer eigenen Infrastruktur bereitstellen. Sie sollten jedoch nach Möglichkeit die Anwendung stattdessen in eine cloudbasierte Lösung portieren.
Durch die Bereitstellung cloudbasierter Anwendungen als Ersatz von veralteten internen Anwendungen verringern Sie nicht nur den Wartungsaufwand und die Kosten, sondern auch die Angriffsfläche Ihrer Organisation, indem Sie Sicherheitsrisiken in Form von Legacysystemen und -anwendungen beseitigen, die von Angreifer*innen genutzt werden können. Dieser Ansatz bietet einer Organisation eine schnellere Möglichkeit, die gewünschte Funktionalität zu erhalten und gleichzeitig Legacyziele in der Infrastruktur zu beseitigen. Auch wenn das Prinzip der kreativen Zerstörung nicht für alle IT-Ressourcen gilt, bietet es häufig eine sinnvolle Möglichkeit, Legacysysteme und -anwendungen zu beseitigen und gleichzeitig robuste, sichere, cloudbasierte Anwendungen bereitzustellen.
Isolieren von Legacysystemen und -anwendungen
Ein natürliches Nebenprodukt der Migration Ihrer unternehmenskritischen Benutzer*innen und Systeme zu einer unberührten, sicheren Umgebung besteht darin, dass die Legacygesamtstruktur dann weniger wertvolle Informationen und Systeme enthält. Die Legacysysteme und -anwendungen in der weniger sicheren Umgebung können zwar ein erhöhtes Risiko der Beeinträchtigung darstellen, sorgen aber auch einen geringeren Schweregrad der Beeinträchtigung. Indem Sie Ihre kritischen Unternehmensressourcen neu erstellen und modernisieren, können Sie sich auf die Bereitstellung einer effektiven Verwaltung und Überwachung konzentrieren, ohne Legacyeinstellungen und -protokolle berücksichtigen zu müssen.
Indem Sie diese Systeme aus Domänen entfernen, in denen sie die Implementierung von Legacyeinstellungen notwendig machten, können Sie die Sicherheit der Domänen anschließend erhöhen, indem Sie sie ausschließlich mit aktuellen Betriebssystemen und Anwendungen konfigurieren. Es ist jedoch vorzuziehen, Legacysysteme und -anwendungen nach Möglichkeit außer Betrieb zu setzen. Wenn die Außerbetriebnahme für einen kleinen Teil Ihres Legacybestands nicht möglich ist, können Sie durch Abtrennung in eine separate Domäne (oder Gesamtstruktur) in der restlichen Legacyinstallation nach und nach Verbesserungen durchführen.
Vereinfachen der Sicherheit für Endbenutzer*innen
In den meisten Organisationen haben Benutzer*innen, die durch ihre Rollen Zugriff auf die vertraulichsten Informationen haben, oft am wenigsten Zeit zum Erlernen komplexer Zugriffsbeschränkungen und -kontrollen. Sie sollten zwar über ein umfassendes Sicherheitsschulungsprogramm für alle Benutzer*innen in Ihrer Organisation verfügen, die Sicherheit jedoch auch so einfach wie möglich gestalten, indem Sie transparente Kontrollen und Vereinfachungsmaßnahmen implementieren, nach denen sich die Benutzer*innen richten.
Sie können beispielsweise eine Richtlinie definieren, in der Führungskräfte und andere VIPs verpflichtet sind, sichere Arbeitsstationen für den Zugriff auf vertrauliche Daten und Systeme zu verwenden. Der Zugriff auf weniger vertrauliche Daten erfolgt dann mit anderen Geräten. Dies ist eine Maßnahme, die sich Benutzer*innen einfach merken können, aber Sie können den Ansatz über eine Reihe von Back-End-Steuerelementen erzwingen.
Sie können Authentifizierungssicherung verwenden, über die Benutzer*innen der Zugriff auf vertrauliche Daten nur gewährt wird, wenn sie sich mit ihren Smartcards bei ihren sicheren Systemen angemeldet haben. Ebenso können Sie durch IPsec und Einschränkungen der Benutzerberechtigungen die Systeme steuern, von denen aus eine Verbindung mit vertraulichen Datenrepositorys hergestellt werden kann. Sie können dynamische Zugriffssteuerung implementieren, um den Zugriff auf Daten basierend auf den Merkmalen eines Zugriffsversuchs einzuschränken und dadurch Geschäftsregeln in technische Kontrollen zu übersetzen.
Aus Sicht der Benutzer*innen ist der Zugriff auf vertrauliche Daten aus einem geschützten System ganz einfach, und der Zugriffsversuche von einem ungesicherten System aus finden ganz einfach nicht statt. Bezüglich der Überwachung und Verwaltung Ihrer Umgebung tragen Sie jedoch dazu bei, identifizierbare Muster für den Zugriff der Benutzer*innen auf vertrauliche Daten und Systeme herzustellen, sodass anomale Zugriffsversuche einfacher erkannt werden können.
In Umgebungen, in denen der Benutzerwiderstand gegenüber langen, komplexen Kennwörtern zu unzureichenden Kennwortrichtlinien geführt hat (insbesondere für VIP-Benutzer*innen), sollten Sie alternative Ansätze für die Authentifizierung in Betracht ziehen. Alternative Ansätze sind beispielsweise Smartcards (die in verschiedenen Ausführungen und mit zusätzlichen Features für eine sicherere Authentifizierung erhältlich sind), biometrische Kontrollen wie Fingerabdrucksensoren oder sogar die Absicherung von Authentifizierungsdaten durch TPM-Chips (Trusted Platform Module) auf den Computern der Benutzer*innen. Die Multi-Faktor-Authentifizierung verhindert keinen Diebstahl von Anmeldeinformationen, wenn ein Computer bereits kompromittiert wurde. Aber da sie eine benutzerfreundliche Authentifizierungsmethode für Benutzer*innen darstellt, können den Konten von Benutzer*innen, für die herkömmliche Kontrollen über Benutzername und Kennwort zu kompliziert sind, robustere Kennwörter zugewiesen werden.