Windows- und Linux-Härtung reduziert unnötige Dienste, begrenzt Rechte und setzt geeignete Sicherheitskonfigurationen durch. Ein brauchbarer Härtungsplan beschreibt aber auch, für welche Systeme ein Profil gilt, wie seine Verträglichkeit geprüft wird und wie die Administration bei einer fehlgeschlagenen Änderung handlungsfähig bleibt.
Dieser Leitfaden führt von der Bestandsaufnahme zu freigegebenen Profilen und einer kontrollierten Einführung. Er enthält ein ausgefülltes Beispiel für einen Büroarbeitsplatz und einen Linux-Anwendungsserver. Herstellerempfehlungen sind dabei technische Bezugspunkte; aus ihnen folgen keine pauschalen gesetzlichen Fristen oder identischen Pflichtkonfigurationen für jedes deutsche Unternehmen.
1. Härtung, Aktualisierung und Wiederherstellung unterscheiden
Ein aktuelles Betriebssystem kann unnötige Fernzugänge erlauben. Ein stark eingeschränktes System kann trotzdem eine ungepatchte Schwachstelle enthalten. Härtung und Sicherheitsupdates ergänzen sich daher. Auch die Wiederherstellung bleibt eine eigene Aufgabe: Eine Änderung, die einen Dienst sicherer konfiguriert, muss dessen gesicherte Wiederaufnahme nicht automatisch gewährleisten.
Bei personenbezogenen Daten verlangt Artikel 32 DSGVO geeignete technische und organisatorische Maßnahmen unter Berücksichtigung des Risikos und des Stands der Technik. Die Verordnung nennt keine allgemeine Zahl von Tagen, innerhalb derer jeder Patch einzuspielen ist. Besondere Branchenpflichten, vertragliche Zusagen und konkrete Gefährdungen sind gesondert zu berücksichtigen.
Ein Härtungsprofil übersetzt die getroffene Schutzentscheidung in Einstellungen. Die Informationssicherheitsrichtlinie legt die übergeordneten Zuständigkeiten fest. Der Betriebsplan beschreibt Durchführung, Nachweis und Behandlung von Abweichungen. Diese Dokumente sollen zusammenpassen, ohne dieselbe Konfigurationsliste mehrfach auseinanderlaufend zu speichern.
2. Geräte nach ihrer Aufgabe gruppieren
Erfassen Sie Betriebssystem, Version, Edition, Supportstatus, Aufgabe, Betreiber und Anbindung an zentrale Verwaltung. Ergänzen Sie erreichbare Dienste, privilegierte Zugänge und geschäftskritische Abhängigkeiten. Nutzen Sie dafür die Karte der IT-Systemlandschaft.
Ein gewöhnlicher Büroarbeitsplatz, ein öffentlich erreichbarer Anwendungsserver und ein Identitätssystem brauchen unterschiedliche Profile. Auch innerhalb einer Plattform kann ein Spezialgerät andere Anforderungen haben. Verhindern Sie deshalb, dass eine für Testrechner erstellte Richtlinie unbemerkt auf produktive Server verteilt wird.
Bei zentraler Anmeldung ergänzt die SSO-Prüfung das Geräteprofil um Attributfreigaben und das Verhalten bestehender Sitzungen nach einem Rechteentzug.
Dokumentieren Sie vor der Änderung den tatsächlich wirksamen Zustand. Eine Einstellung in einer Verwaltungsoberfläche kann durch eine andere Richtlinie überschrieben werden. Das Team muss prüfen können, welche Konfiguration am Zielsystem ankommt und welche Geräte seit längerer Zeit keinen Kontakt mehr zur Verwaltung hatten.
3. Ein passendes Herstellerprofil als Ausgangspunkt wählen
Die Microsoft Security Baselines bündeln empfohlene Einstellungen und deren Sicherheitsbedeutung. Wählen Sie die passende Plattformversion und dokumentieren Sie die Herkunft des verwendeten Pakets. Die Veröffentlichung eines Profils bedeutet nicht, dass jede enthaltene Einstellung ohne Prüfung zu jeder Fachanwendung passt.
Für Linux ist die tatsächlich verwendete Distribution maßgeblich. Die RHEL-10-Dokumentation zur Härtung behandelt unter anderem kryptografische Richtlinien und die Prüfung von Konfigurationen mit geeigneten Profilen. Eine Anleitung für RHEL darf nicht ungeprüft als identischer Befehlssatz für eine andere Distribution dienen.
Notieren Sie im Profil die ausgewählte Referenzversion, den betroffenen Systemtyp und bewusste Abweichungen. „Nach Hersteller gehärtet“ ist für eine spätere Prüfung zu unbestimmt. Ein allgemeiner Prüfbericht ersetzt ebenfalls keine Prüfung, ob die gewählten Kontrollen für den tatsächlichen Dienst sinnvoll und wirksam sind.
4. Ausgefülltes Windows-Arbeitsplatzprofil
Das folgende Beispiel beschreibt einen fiktiven verwalteten Büroarbeitsplatz mit zentraler Anmeldung. Es ist ein Arbeitsplan, keine ungeprüft importierbare Konfigurationsdatei.
| Kontrollbereich | Entscheidung im Beispiel | Abnahme |
|---|---|---|
| Benutzerrechte | Alltagsarbeit ohne lokale Administratorrechte; administrative Tätigkeiten getrennt | Standardbenutzer kann eine privilegierte Änderung nicht ohne vorgesehenen Freigabeweg durchführen |
| Lokale Wiederherstellung | Individuell verwaltetes Administratorkennwort; Abruf nur durch berechtigte Personen | Berechtigter Notfallabruf funktioniert, unberechtigter Zugriff wird verweigert |
| Netzverbindungen | Host-Firewall aktiv; eingehende Ausnahmen nur für freigegebene Dienste | Fachanwendung funktioniert; nicht benötigter Fernzugriff bleibt geschlossen |
| Datenträgerschutz | Geeignete Verschlüsselung mit getrennt geschütztem Wiederherstellungsweg | Wiederherstellungsschlüssel ist für befugte Stellen erreichbar und für Unbefugte gesperrt |
| Anwendungskontrolle | Regeln zunächst in geeignetem Beobachtungsmodus prüfen, danach begrenzt durchsetzen | Fachliche Kernabläufe und Aktualisierung funktionieren nach Aktivierung |
| Verwaltung | Profilzuordnung und tatsächliche Anwendung werden kontrolliert | Zielgerät meldet den erwarteten Zustand; Abweichungen erhalten einen Bearbeiter |
Windows LAPS kann lokale Administratorkennwörter automatisch verwalten und sichern. Welcher Speicherort und welche Funktionen verfügbar sind, hängt unter anderem vom Einbindungszustand und der Plattform ab. Prüfen Sie Abrufrechte und die konkrete Absicherung; die bloße Aktivierung garantiert keine angemessene Rechteverteilung. Kennwörter dürfen nicht aus dem Abruf in allgemein lesbare Tickets übernommen werden.
Die Passwortrichtlinie und Kontowiederherstellung ergänzt dieses Profil. Beachten Sie besonders verlorene Faktoren, ausgeschiedene Beschäftigte und Administratorkonten, die nicht über den zentralen Anmeldedienst laufen.
5. Ausgefülltes Linux-Serverprofil
Das zweite Beispiel betrifft einen fiktiven RHEL-Anwendungsserver. Er stellt einen definierten Dienst bereit; Administration erfolgt über einen vorgesehenen Verwaltungsweg. Andere Plattformen benötigen ihre eigene geprüfte Umsetzung.
| Kontrollbereich | Entscheidung im Beispiel | Abnahme |
|---|---|---|
| Pakete und Dienste | Nur erforderliche Komponenten; ungenutzte Dienste entfernen oder deaktivieren | Anwendung, Sicherung und Überwachung funktionieren weiterhin |
| Administration | Persönliche Konten mit begrenzten administrativen Befugnissen; kein allgemeiner gemeinsamer Alltagszugang | Erforderliche Wartung gelingt; überflüssige privilegierte Aktionen werden verweigert |
| Netz | Nur freigegebene Verbindungen und Verwaltungsquellen | Erlaubte Kommunikation funktioniert in beide benötigten Richtungen |
| Prozessbegrenzung | SELinux im vorgesehenen durchsetzenden Betrieb; Anwendungsregeln gezielt korrigieren | Erforderliche Zugriffe erlaubt, unzulässige Zugriffe verweigert und nachvollziehbar |
| Daten und Geheimnisse | Nur notwendige Zugriffe auf Konfiguration, Schlüssel und Anwendungsdaten | Anwendung läuft ohne unnötige Leserechte anderer Konten |
| Nachweis | Sicherheitsereignisse an die vorgesehenen Stellen übertragen | Ereignis und Ausfall des Übertragungswegs werden erkannt |
Die Red-Hat-Dokumentation unterscheidet bei SELinux durchsetzenden, permissiven und deaktivierten Betrieb. Im permissiven Modus werden Zugriffsverweigerungen protokolliert, aber nicht tatsächlich erzwungen. Er kann der Fehleranalyse dienen und ist nicht gleichwertig mit dem empfohlenen durchsetzenden Produktionsbetrieb. Eine nur vorübergehend gesetzte Laufzeiteinstellung bleibt zudem nicht zwangsläufig nach einem Neustart bestehen.
Wenn eine Anwendung blockiert wird, untersuchen Sie Kennzeichnungen, Pfade und die tatsächliche benötigte Operation. Eine pauschale Abschaltung der Schutzfunktion oder eine weit gefasste Erlaubnis kann die Ursache verdecken. Änderungen sollten auf die erforderliche Anwendung begrenzt und anschließend sowohl funktional als auch hinsichtlich des Schutzes geprüft werden.
6. Pilotierung mit einem echten Rückfallweg verbinden
Wählen Sie Pilotgeräte nach den tatsächlich unterschiedlichen Arbeitsabläufen aus. Ein einzelner IT-Testrechner bildet nicht unbedingt Druck, Fachsoftware, Mobilbetrieb und externe Anmeldung ab. Legen Sie fest, welche Beobachtung zum Stopp der Verteilung führt und wer darüber entscheiden kann.
Ein ausgefüllter Einführungsvermerk könnte lauten: „Profil W-01 wird zunächst einer begrenzten Gruppe aus Verwaltung und Außendienst zugewiesen. Die Gruppe prüft Anmeldung, Fachanwendung, Dokumentenaustausch und Gerätewechsel. Bei Ausfall eines Kernablaufs stoppt die weitere Zuweisung. Der Betrieb kann über den vorbereiteten Verwaltungsweg die letzte freigegebene Richtlinie wiederherstellen und prüft danach die tatsächliche Rückkehr zum vorherigen Zustand.“
Eine Rücknahme braucht mehr als die Absicht, im Notfall alles wieder auszuschalten. Prüfen Sie, ob die Administration nach einer verschärften Firewall- oder Anmelderegel das System noch erreichen kann. Manche Änderungen lassen sich nicht durch Entfernen der Richtlinienzuweisung rückgängig machen. Der konkrete Rückfallweg gehört deshalb in die Vorprüfung.
Beziehen Sie den Backup- und Wiederherstellungsplan ein, wenn Änderungen Daten oder zentrale Systemfunktionen betreffen. Eine vorhandene Sicherung ist erst dann belastbar, wenn der benötigte Wiederherstellungsablauf tatsächlich bekannt und überprüft ist.
7. Updates und Abweichungen nach Risiko priorisieren
Bewerten Sie Schwachstellen anhand der betroffenen Version, Erreichbarkeit, bekannten Ausnutzung und möglichen Folgen. Ein hoher abstrakter Schweregrad ist relevant, aber nicht die einzige Information. Bei aktiv ausgenutzter Schwachstelle auf einem erreichbaren System können sofortige Zwischenmaßnahmen erforderlich sein, bevor ein vollständiger Patchzyklus abgeschlossen werden kann.
Eine Abweichung muss ein konkretes System, einen Grund, Ersatzmaßnahmen und ein Ablauf- beziehungsweise Überprüfungsdatum haben. „Die Anwendung braucht das“ ist ohne technische Klärung zu schwach. Dokumentieren Sie, wer die Änderung der Anwendung oder ihre Ablösung verfolgt, damit aus einer Übergangslösung kein unbeachteter Dauerzustand wird.
Verknüpfen Sie die wichtigsten Ereignisse mit dem Sicherheitslogkonzept. Die bloße Sammlung vieler Logs liefert noch keine Bearbeitung von Warnungen. Zuständigkeiten und eine nachvollziehbare Reaktion gehören zur Betriebsaufnahme.
8. Den wirksamen Zustand regelmäßig prüfen
Vergleichen Sie freigegebene Profile mit tatsächlich erreichten Einstellungen und erklären Sie Abweichungen. Eine Kennzahl wie „95 Prozent konform“ kann täuschen, wenn gerade die besonders kritischen Systeme zu den verbleibenden fünf Prozent gehören. Berichten Sie deshalb neben der Quote auch Umfang, Risiken und offene Entscheidungen.
Prüfen Sie nach relevanten Versionswechseln erneut, ob Einstellungen noch unterstützt werden und dieselbe Wirkung haben. Produktnamen oder alte Standardwerte sollten nicht jahrelang ungeprüft in einer Freigabe stehen. Bewahren Sie die geprüfte Profilversion und die Ergebnisse nachvollziehbar auf, damit ein späteres Datenschutz-Audit den tatsächlichen Stand beurteilen kann.
Häufige Fragen
Gibt es ein einziges Härtungsprofil für Windows und Linux? Nein. Schutzziele können gemeinsam sein, die Umsetzung hängt aber von Plattform, Version und Aufgabe ab. Auch Server und Arbeitsplatz benötigen unterschiedliche Entscheidungen.
Muss jede kritische Schwachstelle innerhalb einer festen DSGVO-Frist behoben sein? Die DSGVO nennt keine universelle Patchfrist. Die konkrete Gefährdung und gegebenenfalls andere verbindliche Anforderungen bestimmen den notwendigen Umgang.
Reicht ein erfolgreicher Konfigurationsscan? Er liefert einen wichtigen technischen Nachweis innerhalb seines Prüfumfangs. Fachliche Funktionsfähigkeit, Wiederherstellung, Ausnahmen und nicht erfasste Systeme müssen zusätzlich betrachtet werden.