Wie energieeffizient sind die Rechenzentren in Deutschland?

Wie sich der Rechenzentrumsmarkt und insbesondere das Thema der Energieeffizienz in Rechenzentren in Deutschland entwickelt, ist Thema einer aktuellen Umfrage bei Rechenzentrumsbetreibern. Die Umfrage wird vom Borderstep Institut im Rahmen des vom Bundesministerium für Wirtschaft und Energie geförderten Forschungsprojektes TEMPRO durchführt.  

Rechenzentrumsbetreiber werden gebeten, sich an dieser vertraulichen Umfrage zu beteiligen. Unter allen Teilnehmern wird ein IPad verlost. Die Forscher erhoffen sich, mit Hilfe der Ergebnisse der Befragung auch künftig Informationen zur Marktentwicklung und zur Entwicklung der Energieeffizienz im Deutschland zur Verfügung stellen zu können.

Migration öffentlicher Ordner zu Office 365-Gruppen

Office 365-Gruppen stellen ein Sicherheitskonzept dar, mit dem Gruppenarbeit in Office 365 effektiver dargestellt werden kann. Grundsätzlich sind Office 365-Gruppen ein Objekt in Azure Active Directory, das mit Office 365 verbunden ist. Administratoren können einer Office 365-Gruppe verschiedene Benutzer zuordnen. Dadurch stehen den Gruppen verschiedene Funktionen zur Verfügung, mit denen sich auch Daten speichern lassen.

Mit dieser Kombination können Gruppen Zugriffsberechtigungen erteilt werden, die für einzelne Teammitglieder gelten. Erhält ein Benutzer zum Beispiel das Recht auf die Office 365-Gruppe „Einkauf“ zuzugreifen, erhält der Benutzer automatisch Zugriff auf alle Tools und Daten der Gruppe. Dazu gehört zum Beispiel auch die SharePoint-Teamsite der Gruppe und die verschiedenen Datenablagen.

Office 365-Gruppen erhalten ein Exchange-Postfach in Office 365, so wie es bei öffentlichen Ordnern möglich ist. Außerdem erhalten Office 365-Gruppen einen gemeinsamen Kalender. Dieser erlaubt die Koordination von Terminen für die ganze Gruppe.

Die Erstellung einer Office 365-Gruppe kann an verschiedenen Stellen durchgeführt werden. Administratoren können Gruppen über die Office-365-Admin-Umgebung, in Azure Active Directory (AAD) oder mit der PowerShell erstellen.

Microsoft Teams bietet den Vorteil, dass verschiedene Kollaborationsdienste gemeinsam zur Verfügung stehen. Dazu gehören Dateiablage, Notizbuch, Planer und PowerBI. Diese Bereiche stehen über Office 365-Gruppen zur Verfügung.

VMs per Skript sichern

Neben dem HTLM5-vSphere-Client können Sie VMware-Umgebungen auch über die PowerShell verwalten, überwachen und auch sichern. Dazu benötigen Sie die PowerShell-Erweiterung PowerCLI. Zusätzlich bietet VMware kostenlose Skripte für die Verwaltung oder für das Anzeigen von Informationen, die auch bei der Datensicherung helfen können.

Auch Dritthersteller bieten kostenlose Erweiterungen für die PowerCLI oder kostenlose Skripte, welche die Verwaltung und Sicherung von VMs in vSphere erleichtern. Die aktuelle Version der PowerCLI laden Sie im Download-Center bei VMware herunter.

Mit „Connect-VIServer“ wird eine Verbindung zum Host oder einem vCenter-Server aufgebaut. Der Befehl „Connect-VIServer -Server <IP-Adresse> -Protocol https -User <Benutzername> -Password <Kennwort>“ baut die Verbindung auf. „Get-VM“ zeigt Daten von VMs an. Durch dieses CMDlet können Sie auf die Schnelle testen, ob die PowerShell-Verbindung erfolgreich hergestellt wurde. Die hier angezeigten Server und VMs können Sie anschließend sichern oder wiederherstellen.

Sie können mit Skripten auch Snapshots erstellen, zum Beispiel mit dem CMDlet „New-Snapshot“. Ein Beispielbefehl sieht folgendermaßen aus:

“New-Snapshot -vm server1 -Memory:$false -confirm:$false -name „Ticket number 12345”

Natürlich lassen sich auch mehrere VMs bei der Erstellung eines Snapshots berücksichtigen:

„New-Snapshot -vm server1,server2,server3 -Memory:$false -confirm:$false -name „Ticket number 12345“

Natürlich stellt das Erstellen von Snapshots keine richtige Sicherung einer VM dar. Aber auch für das Sichern von VMs lassen sich Skripte nutzen. Ein Beispiel dafür ist das Skript „GhettoVCB“. Das Skript bietet keine grafische Oberfläche, wie die Vielzahl an Tools, mit denen sich VMs sichern lassen, sondern richtet sich vor allem an Administratoren, die Server per Skript sichern wollen.

.  Sie können mit „Export-VM“ auch mehrere VMs auf einmal exportieren. Dazu können Sie zum Beispiel mit „Get-VM“ eine Liste der VMs abfragen und diese dann an „Export-VM“ weitergeben. Alternativ können Sie auch einfach mit „Get-VM“ die VMs anzeigen und dann einzelne VMs exportieren:

Get-VM

Export-VM w2k19 -Path F:\Backups

Wollen Sie alle VMs exportieren, verwenden Sie im Skript das Pipe-Zeichen:

Get-VM | Export-VM -Path F:\Backups

Sie können exportierte VMs mit „Import-VM“ importieren. Das Exportieren können Sie mit einem PowerShell-Skript durchführen. In diesem Fall können Sie das Skript in der Aufgabenplanung hinterlegen.

Eine weitere Möglichkeit, um VMs in Hyper-V zu skripten besteht darin das kostenlose „Hyper-V Virtual Machine Backup Utility“ (https://gallery.technet.microsoft.com/scriptcenter/PowerShell-Hyper-V-Backup-7d444752) aus dem Microsoft Script Center zu verwenden.

Virtuelle Server gruppieren

Die Verwaltung von Gruppen findet vor allem in der PowerShell statt. Dazu stehen die folgenden CMDlets zur Verfügung:

  • New-VMGroup
  • Get-VMGroup
  • Remove-VMGroup
  • Add-VMGroupMember
  • Remove-VMGroupMember
  • Rename-VMGroup

Haben Sie Gruppen erstellt, können Sie jederzeit VMs zur Gruppe hinzufügen, oder VMs aus den Gruppen entfernen. Um eine Gruppe zu erstellen verwenden Sie zum Beispiel:

New-VMGroup -Name JoosGroup -GroupType VMCollectionType

Um VMs einer Gruppe hinzuzufügen, arbeiten Sie am besten mit einer Variablen. Im ersten Schritt erstellen Sie eine Variable mit der Gruppe, der Sie eine VM hinzufügen wollen:

$VMG1 = Get-VMGroup -Name JoosGroup

Die einzelnen VMs nehmen Sie auch als Variable hinzu:

$VM1 = Get-VM -Name Essentials

Danach können Sie die VM der Gruppe hinzufügen:

Add-VMGroupMember -VMGroup $VMG1 -VM $VM1

Die Gruppenmitgliedschaft können Sie wiederum mit der Option „groups“ anzeigen lassen, wenn Sie zum Beispiel das CMDlet get-vm verwenden:

Get-VM | ft Name, state, groups -AutoSize

VMs können Mitglied in mehreren Gruppen sein. Außerdem können Sie auch Gruppen verschachteln. Dazu müssen Sie Gruppen mit der Option „ManagementCollectionType“ erstellen.

Hyper-V-VMs exportieren

Der Befehl zum Exportieren steht über das Kontextmenü von virtuellen Server zur Verfügung. In Windows Server 2012 funktioniert diese Technik nur dann, wenn der virtuelle Server nicht gestartet ist. Das ist in Windows Server 2012 R2 und Windows Server 2019 anders. Sie können hier auch im laufenden Betrieb durchführen.  Der Exportvorgang umfasst die .vhd(x)-Dateien, Prüfpunkte und die Einstellungen des virtuellen Servers. Die Größe der Exportdateien entspricht der Größe der Quelldateien.

Wollen Sie einen virtuellen Computer importieren, steht der Befehl Virtuellen Computer importieren im Aktions-Bereich des Hyper-V-Managers zur Verfügung. Über den Assistenten wählen Sie den Ordner aus, in dem sich die Exportdatei befindet, und erhalten im nächsten Fenster Informationen zum Servernamen angezeigt. Auf der nächsten Seite wählen Sie die Optionen aus, um den Server zu importieren.

Virtuelle Server können Sie mit „Import-VM“ importieren und mit „Export-VM“ exportieren. Diese beiden CMDlets sind für das Erstellen von Skripten also besonders hilfreich.  Sie können mit „Export-VM“ auch mehrere VMs auf einmal exportieren. Dazu können Sie zum Beispiel mit „Get-VM“ eine Liste der VMs abfragen und diese dann an „Export-VM“ weitergeben. Alternativ können Sie auch einfach mit „Get-VM“ die VMs anzeigen und dann einzelne VMs exportieren:

Get-VM

Export-VM w2k19 -Path F:\Backups

Wollen Sie alle VMs exportieren, verwenden Sie im Skript das Pipe-Zeichen:

Get-VM | Export-VM -Path F:\Backups

Sie können exportierte VMs mit „Import-VM“ importieren. Das Exportieren können Sie mit einem PowerShell-Skript durchführen. In diesem Fall können Sie das Skript in der Aufgabenplanung hinterlegen.

Neues Projekt zur Abwärmenutzung in Rechenzentren

Server in Rechenzentren erzeugen hohe Mengen an Abwärme, die bisher mit hohem Energieaufwand aus dem Gebäude abgeführt und an die Umwelt abgegeben wird. Viel mehr Sinn würde es machen, diese Abwärme zu nutzen. Das dies nicht geschieht, liegt aus Sicht der Rechenzentrumsbetreiber vor allem an drei Gründen. Zum einen ist die Nutzung der Abwärme in Deutschland oft zu teuer. Zum zweiten findet sich oft kein Abnehmer für die Abwärme in der Umgebung des Rechenzentrums. Und zum dritten ist das Niveau der Abwärme mit etwa 30 bis 40°C oft zu niedrig, um sie einer sinnvollen Nutzung zukommen zu lassen (Grafik).  

In dem neuen Forschungsprojekt wird genau an dieser Stelle angesetzt. Ziel ist es, eine wirtschaftlich attraktive Nutzung von Abwärme in Rechenzentren zu ermöglichen. Mit Hilfe der von der Thomas Krenn AG entwickelten Hot Fluid Computing-Technologie wird die Abwärme der Server mit Wasser abgeführt und kann auf hohem Temperaturniveau (> 55°C) zum Zwecke der Gebäudeheizung oder für Brauchwassererwärmung zur Verfügung gestellt werden. Im Rahmen des Projektes wird diese Technologie aber auch genutzt, um in einem standardisiertem Rechenzentrum („Private Datacenter“ von dc-ce RZ-Beratung und Tobol) mit Hilfe einer Adsorptionskältemaschine von InvenSor Kälteleistung zu erzeugen. Die Kombination aus Abwärme und Adsorptionskälte erlaubt es, die Serverabwärme zum kühlen zu nutzen. Gekühlt werden können z.B. die im Rechenzentrum vorhandenen  Speichersysteme, Netzwerkkomponenten oder Unterbrechungsfreien Stromversorgungen.  Durch die Kombination der drei Ansätze „Private Datacenter“, „Hot Fluid Computing“ und „Adsorptionskältemaschine“ soll eine Effizienzsteigerung von mindestens 300% gegenüber konventionellen Rechenzentren erreicht werden. Das neue Konzept wird zum einen unter Laborbedingungen an der TU Berlin (Hermann Rietschel Institut) und zum anderen unter Praxisbedingungen bei Noris Networks umgesetzt und demonstriert.

HotFlAd wird im Rahmen der Förderinitiative „EnEff.Gebäude.2050 – Innovative Vorhaben für den nahezu klimaneutralen Gebäudebestand 2050“ vom Bundesministerium für Wirtschaft und Energie gefördert.

In Kritischen Infrastrukturen ist Meldepflicht Selbstschutz

Die gesetzliche Pflicht, Störungen in den Netzwerken kritischer Infrastrukturen zu melden, wird oft als bürokratischer Aufwand wahrgenommen. Der vorgeschriebene Informationsaustausch zwischen kritischen Infrastrukturen und dem Bundesamt für Sicherheit in der Informationstechnik (BSI) birgt ohne Zweifel Aufwände und Unklarheiten. Jedoch überwiegt der Mehrwert, der sich aus der Schwarmintelligenz ergibt. Je mehr Akteure über Gefährdungen berichten, desto mehr Akteure können sich gegen diese auch aktiv vorbereiten, bevor Störungen entstehen. So wird Meldepflicht zum Selbstschutz.

Der Mehrwert kann jedoch nur entstehen, wenn über den Tellerrand der gängigen Monitoring- und Sicherheitssysteme geschaut wird. Genau hier setzt das Prinzip des Defense-In-Depth an, das die gängigen Lösungen (Firewalls, Virenscanner etc.), die mittlerweile als Standard in jeder Kritischen Infrastruktur angenommen werden können, um Abwehrmechanismen erweitert, die auch das Unbekannte sichtbar machen.

Dass bislang unbekannte Angriffs- und Störungsmuster in Zukunft eine entscheidende Rolle bei der Gefährdungslage spielen, zeigten nicht zuletzt die mehrstufigen, lange Zeit verborgen agierenden Kampagnen Industroyer und Dragonfly 2.0. Während mit Dragonfly 2.0 Angreifer über Monate bis Jahre Kritische Infrastrukturen auch in Deutschland ausspioniert haben, legte Industroyer 2016 die Stromversorgung Kiews für mehrere Stunden lahm.

Auf der Suche nach dem Unbekannten

Genau hier liegt auch die größte Unklarheit für die Informationssicherheitsbeauftragten in kritischen Infrastrukturen. Das IT-Sicherheitsgesetz (und damit das EnBW, AtG und BSIG) fordert eine Meldung von »erheblichen Störungen der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit ihrer informationstechnischen Systeme, Komponenten oder Prozesse, die zu einem Ausfall oder einer Beeinträchtigung der Funktionsfähigkeit der von ihnen betriebenen Kritischen Infrastrukturen führen können oder geführt haben.«

Die Formulierung birgt zwei Unschärfen, mit denen Betreiber zu kämpfen haben:

  1. Wie sollen Störungen erkannt werden, die erst langfristig zu einer Beeinträchtigung führen könnten, zum Beispiel Advanced Persistent Threats?
  2. Wie kann bewertet werden, ob die Beeinträchtigungen durch eine Störung erheblich sein könnten?

Auf der FAQ-Seite des BSI findet sich zur ersten Frage lediglich der Hinweis: »Werden Angriffe auf die Kritische Infrastruktur unter Verwendung von neuartigen, außergewöhnlichen, zielgerichteten oder aus technischer Sicht bemerkenswerten Angriffsverfahren entdeckt, muss davon ausgegangen werden, dass eine Einwirkung auf die Kritische Infrastruktur möglich ist, sobald sich die Angreifer dazu entschließen«.

Auch bei der Frage, was »erheblich« bedeutet, sind Informationssicherheitsbeauftragte weitestgehend auf sich gestellt: »Eine eindeutige, umfassend geltende Antwort, wann eine Störung erheblich ist, ist nicht möglich. Stattdessen ist es erforderlich, dass die Verantwortlichen in KRITIS-Unternehmen Einzelfallentscheidungen treffen«.

Aus unseren Erfahrungen des Monitorings von Leitsystemen und Netzleittechnik mittels industrieller Anomalieerkennung wissen wir, dass weder versteckte Angriffe noch offene Sicherheitslücken eindeutig erkannt und eingeschätzt werden. Hinzu kommt, dass die Entwicklungen der Digitalisierung und des Smart Grid zu immer komplexeren Kommunikationsstrukturen führen, die neben Sicherheitsgefährdungen auch die Wahrscheinlichkeit technischer Fehlerzustände erhöhen.

Wer entscheiden will, muss sehen können

Betreiber benötigen somit Werkzeuge, die zwei Dinge ermöglichen:

  1. Vorgänge erkennen, die durch gängige Sicherheitslösungen mit Blacklisting- oder Whitelistingansatz übersehen werden.
  2. Vorgänge dahingehend bewerten, ob diese (erhebliche) Beeinträchtigungen hervorrufen könnten.

Netzleittechnik und Leitsysteme sind von einer deterministischen Kommunikationsstruktur geprägt. Dadurch können zum Beispiel mit einer industriellen Anomalieerkennung alle Vorgänge erkannt werden, die in irgendeiner Form vom deterministischen Grundmuster abweichen. Ein gutes Monitoringsystem erkennt bei den sicherheitsrelevanten Vorfällen u.a. neue:

  • Netzteilnehmer oder Kommunikationsbeziehungen;
  • Verbindungen zum Internet;
  • Protokolle;
  • Befehlsstrukturen sowie Netzwerkscans.

Hinzu kommen sowohl bestehende CVE-Sicherheitslücken an Geräten und Software, als auch Netzstörungen, die keine IT-Sicherheitsvorfälle sind, aber an das BSI gemeldet werden müssen. Zu letzteren gehören Konfigurations- und Kommunikationsfehler sowie andere technische Fehlerzustände, die sich beispielsweise aus der Abnahme der Netzwerkqualität ergeben. Gefährdungen jeglicher Form werden somit in ihrem frühesten Stadium erkannt und in Echtzeit gemeldet.

Die Bewertung der Vorfälle wird durch die industrielle Anomalieerkennung über verschiedene Stufen ermöglicht. Zum einen wird jede Meldung in Sicherheit oder Netzwerkqualität kategorisiert. Des Weiteren erhält jede Meldung eine Risikobewertung in Abhängigkeit von Kommunikationsvorgang und betroffenen Komponenten. Schlussendlich wird jede Meldung inklusive der Rohdaten als frei exportierbares PCAP gespeichert. Somit ist eine umgehende forensische Analyse auf einer vollständigen, nachvollziehbaren Datenlage für alle Stakeholder möglich. Informationssicherheitsbeauftragte können damit auf jede potentielle Gefährdung reagieren, bevor es zur Beeinträchtigung kommt.

Unternehmenssicherheit: Insider Threats erfolgreich abwehren

Moderne Systeme für Dynamic Data Protection helfen dabei, Daten vor Verlust und Diebstahl verlässlich zu schützen. Sie ermöglichen flexible und dynamische Sicherheitsmechanismen auf Basis eines individuellen Risiko-Scores. Auf diese Weise lässt sich die höchstmögliche Produktivität der Mitarbeiter beibehalten und ein maximaler Schutz der Daten sicherstellen.

Das größte Risiko für die Datensicherheit in Unternehmen kommt von innen – durch so genannte Insider Threats. Dabei lassen sich verschiedene Arten von Bedrohungen unterscheiden: Häufig begünstigen Mitarbeiter unwissentlich oder unbeabsichtigt die Abwanderung sensibler Unternehmensdaten. Beispielsweise können durch die arglose Mitnahme und fahrlässige Verwendung von firmeninternen USB-Sticks oder anderen Datenträgern betriebliche Informationen in fremde, unberechtigte Hände gelangen. Ein weiterer Risikofaktor ist der absichtliche Datendiebstahl durch Firmenangehörige: In diesem Fall handeln die Täter mit Vorsatz oder kriminellem Motiv und nehmen einen Schaden für das Unternehmen durch die Veruntreuung von Daten bewusst in Kauf. Eine dritte Kategorie von Bedrohungen sind kompromittierte Anwender. Dabei haben sich Kriminelle Zugang zu den Anmeldedaten eines Mitarbeiters verschafft und missbrauchen diese für Angriffe.

Eine Möglichkeit zur Abwehr der Risiken bieten Lösungen für Data Loss Prevention (DLP). Sie beinhalten herkömmliche Funktionen für Identitätsmanagement, Monitoring, Verschlüsselung sowie Zugriffskontrolle. Zudem steuern und überwachen sie Nutzer-Aktivitäten und bieten Mechanismen, um Datenströme im Unternehmensnetzwerk zu filtern und zu schützen. Konventionelle DLP-Systeme sind aber in der Regel sehr starr und bieten nicht die nötige Dynamik, um auf die verschiedenen Spezies von Insider Threats adaptiv zu reagieren. Die Lösungen fokussieren häufig nur den reinen Infrastrukturschutz oder die Abwehr von externen Gefahren. Dabei nutzen sie meist statische Auswertungen, die sich nicht flexibel an verschiedene Arten von Benutzern und Transaktionen anpassen und dadurch zusätzliche Sicherheitslücken verursachen. So verwenden solche Systeme für alle User immer die gleichen Policies und Richtlinien, verbieten von vornherein bestimmte Aktionen und schränken dadurch die Produktivität der Mitarbeiter erheblich ein. Überdies senden die meisten DLP-Lösungen an die Sicherheitsverantwortlichen in Unternehmen eine riesige Anzahl von teilweise unnötigen Alerts, auf die reagiert werden muss. Dies erhöht den Administrationsaufwand und verursacht zusätzliche Kosten.

Sicherheit im Einklang mit Produktivität und Effizienz

Einen weitaus effektiveren Schutz vor Insider Threats bieten moderne Lösungen für Dynamic Data Protection (DDP). Sie schneiden interne Sicherheitsrichtlinien ohne Zutun eines Administrators automatisch und adaptiv auf alle Nutzer oder Geräte zu. Dadurch können Unternehmen die Sicherheit ihrer Nutzer und Daten lückenlos mit den Anforderungen an Produktivität und Effizienz in Einklang bringen. Das Besondere: Flexibel und individuell passen DDP-Systeme die Reaktion auf einen Sicherheitsvorfall anhand des jeweiligen Risikos an. Auf diese Weise wird der momentane Sicherheitslevel automatisch und situativ an die jeweiligen Anforderungen angeglichen. Dabei besteht die Möglichkeit, dynamisch und je nach Rolle oder Verhalten eines Mitarbeiters spezielle Policies zu generieren.

Ein Beispiel: Eine bestimmte Person darf interne Daten auf einen USB-Stick kopieren und diesen mit nach Hause nehmen, um dort beispielsweise an einer Firmenpräsentation weiterzuarbeiten. Handelt es sich jedoch um kritische oder sensible Unternehmensdaten, besteht ein höheres Risiko. In diesem Fall regelt eine Richtlinie, dass der Mitarbeiter die Daten nur verschlüsselt kopieren darf. Ein weiteres Szenario beschreibt noch höhere Sicherheitsanforderungen: Hat ein Betriebsangehöriger bereits ein auffälliges Verhalten gezeigt – zum Beispiel durch einen versuchten Zugriff auf Daten, für die er nicht berechtigt ist – ist höchste Vorsicht geboten. Dann sollte eine entsprechende Policy ihm die Mitnahme von Daten komplett verbieten.

Risiko-Score resultiert aus Nutzerverhalten

Grundlage der Erkennungsmechanismen ist die Technologie „User and Entity Behaviour Analytics“ (UEBA). Die DDP-Lösung beobachtet dabei das Verhalten der Nutzer, definiert daraus automatisch einen bestimmten Risiko-Score und passt die Berechtigungen des Betroffenen adaptiv an die jeweiligen Risiken an. Beschäftigte mit geringem Risikofaktor verfügen dann über mehr Rechte und können dadurch produktiver arbeiten. Besonders wichtig ist es dabei auch, bestimmte Verhaltensänderungen eines Mitarbeiters zu erkennen. Greift er beispielsweise von einem anderen Ort als üblich auf Daten zu oder meldet er sich von einem bisher nicht genutzten Gerät an, wird ein erhöhtes Risiko festgestellt. Das DDP-System ist hierbei in der Lage, die jeweiligen Datenpunkte zu identifizieren und zu korrelieren. So lassen sich potenzielle Probleme und Bedrohungen frühzeitig erkennen und gezielt Gegenmaßnahmen einleiten. Beim Einsatz einer solchen Lösung ist jedoch das berechtigte Interesse von Mitarbeitern auf Privatsphäre gegenüber des zu erwartenden Schadens abzuwägen.

Dabei wird der Risiko-Score herangezogen, um die jeweilige Berechtigung des Users passgenau zu definieren, um also den Datenzugriff lediglich zu überwachen und zuzulassen, ihn zu verschlüsseln oder vollständig zu blockieren. So werden beispielsweise die Security-Experten im Unternehmen in hohem Maße entlastet. Diese können sich durch den hohen Automatisierungsgrad und die adaptiven, risikobasierten Anpassungen ganz auf relevante, auffällige Aktivitäten konzentrieren. Zudem lässt sich die benötigte Zeit für die verlässliche Erkennung von Risiken und Bedrohungen auf nur wenige Sekunden reduzieren.

 

Fazit

Insider Threats zählen zu den größten Risiken für die Sicherheit von Unternehmensdaten. Herkömmliche Security-Tools wie etwa DLP-Systeme reichen meist nicht mehr aus, um die Bedrohungen effektiv abzuwehren. Hilfreicher sind moderne Dynamic-Data-Protection-Lösungen, die auf einem risikoadaptiven Ansatz basieren. Sie richten sich nicht nach starren Policies, sondern passen sich dynamisch an das Verhalten der User und die damit verbundenen Risiken an. Dies wirkt sich positiv auf die Produktivität aus und gewährleistet gleichzeitig den optimalen Schutz der Daten.

Bereinigen der Metadaten von Active Directory

Für diese Bereinigung benötigen Sie wiederum das Befehlszeilentool Ntdsutil, das Sie bereits beim Verschieben der FSMO-Rollen kennen gelernt haben. Wenn Sie das Computerobjekt eines Domänencontrollers aus der OU „Domain Controller“ entfernen, bereinigen die verbliebenen Domänencontroller ebenfalls das Active Directory.

Es ist aber sicherer, wenn Sie die Metadaten zumindest überprüfen, und Reste der alten Domänencontroller entfernen. Um die Metadaten von Active Directory zu bereinigen, starten Sie zunächst Ntdsutil in der Eingabeaufforderung von Active Directory. Gehen Sie wie in den folgenden Schritten beschrieben vor:

  1. Geben Sie nach dem Start von Ntdsutilden Befehl metadata cleanup 
  2. Geben Sie im Anschluss daran connections
  3. Geben Sie den Befehl connect to server <Domänencontroller> Verwenden Sie am besten einen globalen Katalog und führen Sie diese Maßnahmen in einer Terminalsitzung auf dem Server aus.
  4. Geben Sie dann einmal den Befehl quit ein, um wieder zum Menü metadata cleanup zurückzukehren.
  5. Als Nächstes geben Sie select operation target
  6. Es folgt der Befehl list domains. Damit werden alle Domänen der Gesamtstruktur angezeigt.
  7. Geben Sie danach den Befehl select domain <Nummer der Domäne> Wählen Sie als Nummer die Domäne aus, von der Sie den Domänencontroller entfernen wollen.
  8. Geben Sie als Nächstes list sites Daraufhin werden alle Standorte der Gesamtstruktur angezeigt.
  9. Wählen Sie den Standort aus, von dem Sie einen Domänencontroller entfernen wollen. Verwenden Sie dazu den Befehl select site <Nummer des Standorts>.
  10. Nachdem Sie den Standort ausgewählt haben, geben Sie den Befehl list servers in site Es werden alle Server in diesem Standort angezeigt.
  11. Dann müssen Sie mit select server <Nummer des Servers> den Server angeben, den Sie aus dem Active Directory entfernen wollen.
  12. Nachdem Sie den Server ausgewählt haben, geben Sie quit ein, damit Sie wieder zum Menü metadata cleanup
  13. Geben Sie nun den Befehl remove selected server Es folgt eine Warnmeldung, in der Sie das Entfernen des Servers bestätigen müssen. Nach der Bestätigung dieser Meldung wird der Server aus dem Active Directory entfernt.
  14. In Ntdsutil werden die einzelnen Vorgänge beim Entfernen des Servers angezeigt.
  15. Im Anschluss können Sie Ntdsutil mit quit Die Active Directory-Metadaten sind bereinigt.

Nachdem die Metadaten von Active Directory bereinigt wurden, sollten Sie noch die Einträge im DNS bereinigen. Entfernen Sie alle SRV-Records, in denen noch der alte Server steht, aus der DNS-Zone der Domäne. Gehen Sie bei der Entfernung vorsichtig vor und löschen Sie keine Daten von anderen Domänencontrollern. Entfernen Sie auch alle Hosteinträge des Servers.

Herabstufen eines Domänencontrollers

Um einen Domänencontroller herunterzustufen, verwenden Sie am besten die PowerShell und das Cmdlet Uninstall-ADDSDomainController. Sie müssen noch das lokale Kennwort des Administrators über den Befehl festlegen. Dieses müssen Sie als SecureString in der PowerShell definieren. Die Syntax dazu lautet:

Uninstall-ADDSDomainController -LocalAdministratorPassword (Read-Host -Prompt „Kennwort“ -AsSecureString)

Mit Get-Help Uninstall-ADDSDomainController erhalten Sie mehr Informationen zu dem Befehl. Um zuvor den Vorgang zu testen, verwenden Sie Test-ADDSDomainControllerUninstallation. Um ausführliche Informationen zu erhalten, verwenden Sie:

Test-ADDSDomainControllerUninstallation | select -expandproperty message

Mit der Option -LastDomainControllerInDomain können Sie auswählen, ob es sich bei diesem Domänencontroller um den letzten seiner Domäne handelt.

In diesem Fall würde nicht nur der Domänencontroller aus der Gesamtstruktur entfernt, sondern die ganze Domäne. Haben Sie Ihre Auswahl getroffen, beginnt der Assistent mit der Herabstufung des Domänencontrollers.

Sobald Active Directory vom Server entfernt wurde, können Sie diesen neu starten. Nach der Herabstufung eines Domänencontrollers wird dieser als Mitgliedsserver in die Domäne aufgenommen. Wenn auf dem Server Applikationen installiert waren, zum Beispiel Exchange, stehen diese nach dem Neustart weiterhin zur Verfügung.

Auch wenn ein herabgestufter Domänencontroller im Anschluss noch als Mitgliedsserver verwendet werden kann, sollten Sie sicherheitshalber das Computerkonto aus der Domäne entfernen und das Betriebssystem neu auf dem Server installieren, um Altlasten zu entsorgen.

Auch den Servernamen sollten Sie ändern, wenn aus dem Namen hervorgeht, dass es sich um einen Domänencontroller gehandelt hat.

Wenn Sie einen Domänencontroller, der die Verbindung mit dem Active Directory verloren hat, nicht neu installieren wollen, können Sie Active Directory trotz fehlender Verbindung entfernen. Verwenden Sie in diesem Fall noch die Option -force.

Nach der erzwungenen Entfernung von Active Directory ist der Domänencontroller allerdings kein Mitgliedsserver mehr, sondern ein alleinstehender Server. Sie können sich daher an diesem Server nicht mehr bei der Domäne anmelden.

Wollen Sie danach noch die Binärdateien von Active Directory entfernen, verwenden Sie entweder den Server-Manager das Windows Admin Center, oder die PowerShell und den Befehl:

Uninstall-WindowsFeature AD-Domain-Services