4crypto.eu
Kompetenz · Konfigurationshärtung · 2026

Hardening von Systemen und Geräten 2026: CIS, STIG und Defense in Depth

Autor: Dr. Adam Czubak Korrektorat: Alicja Czubak Lesezeit: 16 Min Aktualisiert: 2026-08-26

Hardening ist die systematische Verkleinerung der Angriffsfläche: Dienste abschalten, die niemand nutzt, Voreinstellungen verschärfen, Rechte auf das notwendige Minimum begrenzen und die Konfiguration an einen Bezugspunkt heranführen - meist an CIS Benchmarks [1], DISA STIG [2] oder den Katalog NIST SP 800-53 [3].

Der Unterschied zum Patchen ist grundlegend. Ein Patch beseitigt einen bestimmten Fehler und verliert seine Bedeutung, sobald der nächste auftaucht. Eine richtig gesetzte Konfiguration schneidet eine ganze Problemklasse auf einmal ab und wirkt weiter, auch gegen Schwachstellen, von denen noch niemand weiss. Deshalb ist Hardening in der Regel günstiger als ein weiteres Erkennungswerkzeug und dauerhafter als eine einmalige Patch-Kampagne.

In der Praxis sind fünf Ebenen zu erfassen: Server, Arbeitsplätze, Active Directory, Netzgeräte und - am häufigsten übersehen - Industrieanlagen und eingebettete Geräte, für die IEC 62443 [4] der Bezugspunkt ist. Dieser Artikel beschreibt, was Hardening ist und was nicht, wie ein Standard gewählt wird, was sich in jeder Ebene konkret ändert, warum ohne Automatisierung alles zurückfällt und aus welchen Vorschriften es folgt.

Hardening - was es ist und was nicht

Um den Begriff haben sich einige Missverständnisse gebildet, die man vorweg entschärfen sollte, denn jedes führt zu einer anderen Art vergeudeter Arbeit.

Hardening ist kein Projekt mit Enddatum. Die Konfiguration entfernt sich von selbst vom Bezugspunkt, ohne dass jemand böswillig handelt: Für einen Vorfall wird eine befristete Ausnahme eingerichtet, die niemand zurücknimmt, ein neuer Dienst kommt hinzu, jemand ändert in der Eile eine Einstellung. Ohne Messung dieser Abweichung befindet sich die Organisation nach einem Jahr in einem Zustand, über den sie nichts weiss.

Es ist auch kein Synonym für Patchen und kein Ersatz für Software zur Bedrohungserkennung. Ein EDR arbeitet im System und reagiert auf das, was bereits geschieht; Hardening verkleinert das, worauf ein Angreifer überhaupt einwirken kann. Beides ergänzt sich, ersetzt sich aber nicht.

Und es hat nichts mit Sicherheit durch Verschleierung zu tun. SSH von Port 22 auf 2222 zu verlegen verringert die Zahl der Protokolleinträge aus automatisierten Scans, mehr nicht - wer eine Minute in Aufklärung investiert, findet den Dienst genauso.

Was ist es also? Ein fortlaufender Prozess aus drei Bestandteilen: einem dokumentierten Bezugspunkt, der regelmäßigen Messung der Abweichungen davon und einem formalen Weg zur Genehmigung von Ausnahmen. Hinzu kommen standardisierte Systemabbilder, damit jeder neue Server bereits im Zielzustand startet, statt ihn von Hand zu erreichen.

Hardening und Erkennung ergänzen einander. Einige Techniken aus der Matrix MITRE ATT&CK [5] - T1059 Command and Scripting Interpreter, T1543 Create or Modify System Process, T1547 Boot or Logon Autostart Execution - lassen sich allein durch Konfiguration abschneiden, bevor ein EDR etwas zu erkennen hat. Jeder solche Fall ist ein Alarm, der nie entsteht, und eine Analystenentscheidung weniger.

Standards: CIS, STIG, NIST und wann welcher

Den Bezugspunkt muss niemand erfinden, denn es gibt drei anerkannte Sammlungen, die sich in Detailtiefe und Zweck unterscheiden.

CIS Benchmarks [1] sind außerhalb des Verteidigungssektors die häufigste Wahl. Das Center for Internet Security veröffentlicht Konfigurationsempfehlungen für mehr als 25 Produktfamilien, von Betriebssystemen über Datenbanken und Anwendungsserver bis zu Cloud, Netzgeräten und Containern. Jeder Benchmark hat zwei Stufen: L1 umfasst Einstellungen, die sich ohne Betriebsrisiko umsetzen lassen, L2 geht weiter, auf Kosten von Bequemlichkeit und Anwendungsverträglichkeit.

DISA STIG [2] stammt vom US-Verteidigungsministerium und ist deutlich strenger. In polnischen Verhältnissen greift man vor allem im Verteidigungssektor darauf zurück und dort, wo ein Auftraggeber es fordert.

NIST SP 800-53 [3] arbeitet auf einer anderen Ebene: Es ist ein Maßnahmenkatalog, in dem die Familie CM die Konfiguration betrifft. Er ist deutlich weniger detailliert als CIS oder STIG, bildet sich aber unmittelbar auf das NIST CSF [6] ab und eignet sich daher als verbindende Schicht. Für Server allein ist der ältere, aber weiterhin brauchbare Leitfaden NIST SP 800-123 [7] eine praktische Ergänzung.

Für eine typische Kommune mit einigen Dutzend Arbeitsplätzen und wenigen Servern sieht ein sinnvoller Satz so aus: Arbeitsplätze auf Stufe L1 mit ausgewählten L2-Einstellungen zu Festplattenverschlüsselung und Fernzugriff, Server und Domänencontroller auf L1 mit L2 dort, wo die Anwendungen es zulassen, Netzgeräte nach dem Benchmark des jeweiligen Herstellers und Active Directory nach den Konfigurationswerkzeugen von Microsoft, ergänzt um Rotation lokaler Kennwörter und ein Stufenmodell der Administration.

Die Wahl der Stufe ist eine Risikoentscheidung, keine Frage des Ehrgeizes. L2 überall anzuwenden endet meist gleich: Der Fachbereich meldet, dass etwas nicht mehr funktioniert, das Hardening wird vollständig zurückgenommen, und die Organisation landet unter dem Ausgangspunkt.

Was konkret gehärtet wird

Es sind sieben Ebenen, und jede hat andere Zuständige und andere typische Lücken.

  1. Betriebssystem. Abschalten überflüssiger Dienste, strengere Authentisierung einschließlich Mehr-Faktor-Authentisierung für administrative Konten, Rückzug veralteter Protokolle wie SMBv1 und NTLMv1, Kennwortrichtlinie und Begrenzung lokaler Administratorrechte.
  2. Active Directory - in polnischen Kommunen meist das schwächste Glied. Vier Dinge, in dieser Reihenfolge: ein Stufenmodell der Administration (Domänencontroller und kritische Systeme, Anwendungsserver, Arbeitsplätze; administrative Konten überschreiten keine Stufengrenze), Rotation der lokalen Administratorkennwörter, Begrenzung der Standardrechte gewöhnlicher Benutzer, insbesondere der Gruppe Authenticated Users auf den DNS-Partitionen und in SYSVOL, sowie strengere Kerberos-Einstellungen: keine Konten mit abgeschalteter Vorauthentisierung, kurze Ticketlaufzeiten, ausschließlich AES.
  3. Netz. Segmentierung in Zonen, Firewallregeln nach dem Prinzip Default Deny, Isolation der Arbeitsplätze untereinander, 802.1X-Authentisierung im Kabel- und Funknetz sowie Trennung der Verwaltungsschnittstellen vom Produktivverkehr, ohne Protokolle, die Kennwörter im Klartext übertragen.
  4. Arbeitsplätze. Steuerung der ausführbaren Anwendungen, Festplattenverschlüsselung, Mechanismen zur Begrenzung von Exploit-Wirkungen sowie Software zur Bedrohungserkennung mit Blockier- statt nur Meldepolitik.
  5. Anwendungen. Auf der Webserverseite: aktuelle TLS-Versionen, Sicherheitskopfzeilen und weniger preisgegebene Informationen. Auf der Datenbankseite: minimale Rechte für Anwendungskonten und Zugriffsprotokollierung. Davor meist eine Zwischenschicht mit Begrenzung der Anfragezahl.
  6. Cloud und externe Dienste. CIS Benchmarks für die jeweiligen Anbieter, Mehr-Faktor-Authentisierung, Protokollierung administrativer Ereignisse, minimale Rechte in der Identitätsverwaltung, Verschlüsselung als Voreinstellung und Regeln für bedingten Zugriff.
  7. Industrieanlagen. Nach IEC 62443 [4]: Trennung vom Büronetz durch eine Zwischenzone, eine strenge Liste zugelassenen Verkehrs, passive Überwachung statt aktiver Scans sowie ein eindeutiges Verfahren für den Fernzugriff über einen Sprungserver.

Die Reihenfolge zählt. Arbeitsplätze zu härten und zugleich ein ungepatchtes Randgerät stehen zu lassen ändert nichts - der Angreifer kommt dort herein, und die gesamte Arbeit im Inneren bleibt bedeutungslos.

Automatisierung - ohne sie hält nichts

Nach einigen Monaten entfernt sich die Konfiguration vom Bezugspunkt, wiederum ohne böse Absicht: befristete Ausnahmen aus einem Vorfall, neue Dienste, Änderungen in der Eile. Ohne Messung weiss niemand, wie weit.

Das Halten des Zustands beruht auf drei Mechanismen. Der erste ist Konfiguration als Code, in Ansible, Puppet, Chef oder in den systemeigenen Mechanismen von Windows. Das bringt Reproduzierbarkeit, eine Änderungshistorie im Repository und die Möglichkeit, Ist- und Sollzustand zu vergleichen.

Der zweite ist die fortlaufende Konformitätsmessung - tägliche oder wöchentliche Scans, die zeigen, welche Maschinen vom Bezugspunkt abgewichen sind. Dafür dienen Scanner mit eingebauten Auditprofilen und offene Implementierungen des SCAP-Protokolls.

Der dritte ist der reproduzierbare Bau von Systemabbildern, damit jede neue Inbetriebnahme im Zielzustand startet. Das ist der wirksamste Weg, weil er die Abweichung an der Quelle beseitigt, statt sie nachträglich zu korrigieren.

Ohne diese drei Bestandteile ist Hardening eine einmalige Aktion, deren Wirkung genau so schnell verfällt, wie sich die Umgebung ändert.

Die häufigsten Fehler

Aus unserer Auditpraxis wiederholen sich einige Muster.

  1. Keine Messung der Abweichungen. Die Konfiguration wurde irgendwann gesetzt und seither nicht geprüft. Das ist der häufigste und teuerste Fehler, weil er die gesamte frühere Arbeit entwertet.
  2. Die höchste Stufe überall. L2 unabhängig vom Kontext führt zu Konflikten mit Anwendungen und in der Folge zur vollständigen Rücknahme des Hardenings.
  3. Keine formalen Ausnahmen. Ziel ist keine hundertprozentige Konformität, sondern dokumentierte Abweichungen. Kann ein bestimmter Server eine Anforderung nicht erfüllen, gehört das festgehalten, samt kompensierender Maßnahme und Prüftermin.
  4. Gehärtetes Innere, offener Rand. Arbeitsplätze und Server benchmark-konform, an der Internetgrenze aber ein Gerät ohne Aktualisierung seit Jahren. Randgeräte sind gerade deshalb ein dankbares Ziel, weil sie selten in ein Wartungsfenster gelangen.
  5. Active Directory ohne Stufenmodell. Dasselbe Konto dient der Arbeit am Arbeitsplatz und der Verwaltung eines Domänencontrollers. Ein einziger erfolgreicher Zugangsdatendiebstahl genügt, um die gesamte Umgebung zu übernehmen. Ohne diese Trennung ist der Weg vom ersten übernommenen Arbeitsplatz zum Domänencontroller kurz, weil keine Rechtegrenze darauf liegt.
  6. Hardening ohne Überwachung. Mechanismen zur Integritätsprüfung und Richtliniendurchsetzung erzeugen Ereignisse, die niemand entgegennimmt. Siehe SOC 24/7.

Woraus die Pflicht folgt

Keine polnische Vorschrift verwendet das Wort "Hardening", doch mehrere verlangen genau das, was darunter verstanden wird.

Das polnische Cybersicherheitsgesetz [14] richtet seine Anforderungen seit der NIS2-Novelle, in Kraft seit dem 3. April 2026, nicht mehr an Betreiber wesentlicher Dienste, sondern an wesentliche und wichtige Einrichtungen. Sie führen ein Informationssicherheits-Managementsystem ein und darin - Artikel 8 Absatz 1 Nummer 2 - technische und organisatorische Maßnahmen, die dem eingeschätzten Risiko angemessen und verhältnismäßig sind. Hardening knüpft an mehrere Buchstaben zugleich an: Buchstabe b zur Sicherheit bei Beschaffung, Entwicklung, Wartung und Betrieb samt Tests, Buchstabe j zu grundlegender Cyberhygiene, Buchstabe k zu Kryptografie und Verschlüsselung sowie Buchstabe n zu Richtlinien der Zugriffskontrolle. Hinzu kommt Nummer 5 Buchstaben b und c, also regelmäßige Softwareaktualisierungen und Schutz vor unbefugter Veränderung. Ein Teil des öffentlichen Sektors geht einen eigenen Weg: Eine wichtige Einrichtung, die eine öffentliche Stelle ist, wendet statt Absatz 1 die Anforderungen aus Anhang 4 an (Artikel 8 Absatz 3).

Die NIS2-Richtlinie [8] ist die Quelle dieser Anforderungen. Dem Hardening am nächsten stehen Artikel 21 Absatz 2 Buchstabe e zur Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen einschließlich des Umgangs mit Schwachstellen sowie Buchstabe g zu grundlegender Cyberhygiene und Schulungen. Vorsicht bei einem verbreiteten Zitierfehler: Die Lieferkette ist Buchstabe d, und Buchstabe h betrifft Kryptografie, nicht Cyberhygiene.

Die polnische KRI-Verordnung [11] erfasst Stellen, die öffentliche Aufgaben wahrnehmen. Dem Hardening am nächsten liegt § 19 Absatz 2 Nummer 7 Buchstabe c, also Maßnahmen, die unbefugten Zugriff auf Ebene der Betriebssysteme, Netzdienste und Anwendungen verhindern. Ergänzend gelten Nummer 12 Buchstabe e zur Sicherheit von Systemdateien und Buchstabe h zur Prüfung der Übereinstimmung von IT-Systemen mit einschlägigen Normen und Sicherheitsrichtlinien - also unmittelbar die Messung der Abweichung vom Bezugspunkt. Siehe Artikel zu KRI.

Darüber hinaus legt DORA [9] in Artikel 9 Pflichten zu Schutz und Prävention für Finanzunternehmen fest, die DSGVO [10] nennt in Artikel 32 Absatz 1 Buchstabe a Pseudonymisierung und Verschlüsselung unter den technischen Maßnahmen, und IEC 62443-3-3 [4] bestimmt Systemanforderungen für industrielle Umgebungen. Dokumentarisch ergänzt häufig ISO/IEC 27001 [12], in der Abweichungen vom Bezugspunkt in der Erklärung zur Anwendbarkeit festgehalten werden.

Drei Entwicklungen verändern heute den Umfang des Begriffs.

Zero-Trust-Architektur, beschrieben in NIST SP 800-207, ist die natürliche Fortsetzung: Statt einzelne Systeme zu härten, prüft sie jede Anfrage unabhängig von ihrer Herkunft. Sie ersetzt Hardening jedoch nicht, sondern setzt es voraus - ein Zero-Trust-Modell auf Geräten in Werkskonfiguration hat nichts zu prüfen.

Härtung von Umgebungen für maschinelles Lernen ist ein Feld, das im vorigen Jahrzehnt gar nicht existierte. Hinzu kommen der Schutz von Trainingsdaten vor Vergiftung, die Absicherung der auslieferenden Schicht gegen Manipulation der Eingaben und die Kontrolle über das Modellrepository. Ein Teil davon fällt in die Pflichten des AI Act [13].

Confidential Computing, gestützt auf Isolationsmechanismen im Prozessor, erweitert den Schutz auf Daten während der Verarbeitung - bislang wurden sie im Ruhezustand und bei der Übertragung geschützt. Bedeutung hat das vor allem dort, wo sensible Daten in einer Umgebung verarbeitet werden, über die die Organisation keine volle Kontrolle hat.

Checkliste: zehn Bestandteile eines Hardening-Programms

Eine Liste zur vierteljährlichen Durchsicht, nicht zum einmaligen Abhaken.

  1. Bezugspunkt. Der gewählte Standard samt Begründung der Wahl und Versionierung - eine Änderung bedeutet eine neue Version und einen Eintrag in der Änderungshistorie.
  2. Abdeckung aller Ebenen. Jede der sieben Ebenen hat einen eigenen Bezugspunkt. Eine Ebene ohne ihn ist ein Risiko, das niemand eingeschätzt hat.
  3. Automatisierte Umsetzung. Konfiguration als Code für jede Ebene. Händisches Härten ist für einen einzelnen Server vertretbar, nicht für eine Flotte.
  4. Messung der Abweichungen. Regelmäßige Scans mit Vergleich zum Bezugspunkt und einer Schwelle, ab der ein Ticket entsteht.
  5. Formale Ausnahmen. Jede Abweichung nennt Anforderung, Grund, kompensierende Maßnahme, Prüftermin und Genehmigung.
  6. Rotation lokaler Kennwörter. Alle lokalen Administratorkonten mit eindeutigen, automatisch gewechselten Kennwörtern.
  7. Stufenmodell der Administration. Administrative Konten arbeiten nicht auf gewöhnlichen Arbeitsplätzen, und Konten mit den höchsten Rechten ausschließlich von dafür bestimmten Endgeräten.
  8. Mehr-Faktor-Authentisierung für Fernzugriff. Für alle Kanäle: Remotedesktop, SSH, VPN und Cloud-Verwaltungskonsolen.
  9. Netzgeräte. Verwaltung getrennt vom Produktivverkehr, Zugang ausschließlich per Schlüssel, keine Protokolle mit Klartextkennwörtern, Weiterleitung der Ereignisprotokolle an das Überwachungssystem und regelmäßige Aktualisierungen - besonders bei Randgeräten.
  10. Wiederherstellungstest. Hardening senkt die Wahrscheinlichkeit eines Problems, schließt es aber nicht aus. Sicherungskopie und Wiederherstellungsverfahren gehören mindestens vierteljährlich geprüft.

Häufig gestellte Fragen

Ist CIS Level 2 für eine Kommune übertrieben?

Für kritische Server (Domänencontroller, Dateiserver, Sicherung) nicht - L2 ist dort angemessen. Auf Arbeitsplätzen selektiv (L2 für Mehr-Faktor-Authentisierung, Festplattenverschlüsselung und Endgeräteschutz; L1 für den Rest). L2 flächendeckend für Fachanwender erzeugt meist Konflikte mit Tabellenmakros und Druckern.

Wie lange dauert das Hardening einer mittelgroßen Organisation?

Aus unserer Erfahrung: 40 bis 80 Stunden Erstumsetzung (Baseline, Konfiguration als Code, Active-Directory-Härtung, Golden Image) und 8 bis 16 Stunden im Monat Pflege (Korrektur von Abweichungen, neue Systeme, Ausnahmeprüfung). Ohne Automatisierung verdoppelt sich der Pflegeaufwand.

Kann Hardening Anwendungen stören?

Manchmal, besonders bei L2 und STIG. Das Vorgehen:

  1. Hardening in einer Testumgebung vor der Produktion.
  2. Protokollierung aller Anwendungsfehler nach dem Hardening.
  3. Formale Ausnahmen für die erkannten Konflikte, statt die gesamte Baseline zurückzunehmen.
Genügt die Rotation lokaler Administratorkennwörter statt einer PAM-Lösung?

Eindeutige, automatisch rotierte lokale Administratorkennwörter sind eine wichtige Schutzmaßnahme. Privileged Access Management-Plattformen wie CyberArk, BeyondTrust oder Microsoft PIM können Just-in-time-Zugriff, Genehmigungsabläufe, Sitzungsaufzeichnung und Anwendungszugriff ohne Offenlegung von Zugangsdaten ergänzen. Ob PAM erforderlich ist, hängt von Risikobewertung, Architektur sowie vertraglichen und regulatorischen Vorgaben ab; NIS2 und das polnische KSC-Gesetz schreiben kein bestimmtes PAM-Produkt vor.

Decken die CIS Benchmarks SCADA ab?

Teilweise. CIS bietet Benchmarks für Windows Server, und SCADA-Server laufen häufig unter Windows; die Sicherheit gerätespezifischer OT-Komponenten erfordert jedoch einen Ansatz für industrielle Steuerungssysteme. IEC 62443 [4] ist dafür eine weit verbreitete Referenz, aber nicht allgemein verpflichtend, sofern keine Rechts-, Vertrags- oder Sektorvorgabe sie verbindlich macht. CIS kann die IT- und HMI-Ebene unterstützen, während IEC 62443 Schutzmaßnahmen für SPS, RTU sowie industrielle Zonen und Conduits beschreibt.

Reichen Gruppenrichtlinien für das Hardening von Windows?

Gruppenrichtlinien und das Microsoft Security Compliance Toolkit können einen erheblichen Teil einer Windows-Baseline umsetzen; einen allgemeingültigen Abdeckungswert gibt es jedoch nicht. Er hängt von Betriebssystemversion, Benchmark-Profil und Architektur ab. Anwendungssteuerung, Endgeräteschutz, Cloud-verwaltete Einstellungen und Teile des Active-Directory-Hardening können PowerShell DSC, modernes Geräte-Management oder spezialisierte Werkzeuge erfordern.

Was unterscheidet Hardening von einer Security Baseline?

Eine Security Baseline ist eine konkrete Zielkonfiguration (etwa "CIS Windows 11 L1 Build 12345"). Hardening ist der Prozess der Umsetzung und Aufrechterhaltung dieser Baseline. Die Baseline ist ein Dokument, Hardening eine Praxis.

Wann erscheint ein CIS Benchmark für ein neu veröffentlichtes Betriebssystem?

Typischerweise drei bis sechs Monate nach der Freigabe. Prüfen Sie den CIS-Katalog, bevor Sie annehmen, dass ein Benchmark für eine Version bereits existiert - für ein frisch freigegebenes System gibt es ihn meist noch nicht. Die Übergangsstrategie:

  1. Verwenden Sie den CIS Benchmark der Vorgängerversion plus Microsoft Security Compliance Toolkit (Microsoft Security Baselines für Windows erscheinen schneller, meist etwa einen Monat nach der Freigabe).
  2. DISA STIG [2] - oft mit kürzeren Veröffentlichungszyklen als CIS.
  3. Bilden Sie ersatzweise auf die Maßnahmen aus NIST SP 800-53 Rev. 5 [3] ab.
Hardening stört Microsoft 365, Teams oder OneDrive - was tun?

Ein bekannter Konflikt - CIS L2 für Browser und Endgeräteschutz ist für die Web Apps von Microsoft 365 mitunter zu streng. Die Strategie:

  1. Microsoft Security Baselines statt CIS L2 für diese Anwendungen (Microsoft Security Compliance Toolkit). Sie sind besser auf die native Integration abgestimmt.
  2. Bedingter Zugriff in der Identitätsplattform statt Härtung im Browser - Durchsetzung von Mehr-Faktor-Authentisierung, Geofencing, Sperre von Legacy Auth (POP, IMAP, SMTP mit Basisauthentisierung).
  3. Cloud Access Security Broker plus Datenverlustprävention zur Durchsetzung der Informationsklassifizierung.
  4. Formale Ausnahmen in der Erklärung zur Anwendbarkeit (ISO 27001:2022 Abschnitt 6.1.3 [12]) für die konkret kollidierenden CIS-Kontrollen, jeweils mit dokumentierter kompensierender Maßnahme.
Womit beginnt die Härtung von Active Directory?

Eine praktische Reihenfolge (aus unseren Projekten und dem Fahrplan Securing Privileged Access von Microsoft):

  1. Rotation lokaler Administratorkennwörter - in der ersten Woche. Ohne sie sind die übrigen Schritte Security Theatre.
  2. Stufenmodell der Administration (Tier 0, 1, 2) - Trennung administrativer Konten von Arbeitsplätzen. NIST SP 800-53 Rev. 5 AC-6, AC-2 [3].
  3. Mehr-Faktor-Authentisierung für jedes Konto mit Zugriff auf Domänencontroller (dedizierte Administrationsarbeitsplätze, Windows Hello for Business, FIDO2-Hardwareschlüssel).
  4. Abschalten alter Protokolle: NTLMv1, SMBv1, LM-Hashes, Kerberos DES.
  5. Durchsicht des AdminSDHolder - prüfen Sie vierteljährlich, welche Konten das Attribut adminCount tragen, und entfernen Sie aus geschützten Gruppen jene, die dort nicht mehr hingehören. Das ist ein anderer Mechanismus als die Gruppe Protected Users, mit der er oft verwechselt wird.
  6. Härtung der Active-Directory-Rechte - Entfernen überzähliger Rechte von Authenticated Users auf den DNS-Partitionen und in SYSVOL.

Im Einklang mit dem CIS Microsoft Active Directory Benchmark [1] und dem Microsoft Security Compliance Toolkit. Ohne diese sechs Schritte ist der Weg vom ersten übernommenen Arbeitsplatz zum Domänencontroller kurz, weil keine Rechtegrenze darauf liegt.

Ist CIS Level 2 für Entwicklergeräte mit Administratorrechten sinnvoll?

Teilweise. Entwicklerinnen und Entwickler brauchen Rechteerhöhung für ihre Arbeit - Werkzeuge installieren, Container, Debugger. Ein tragfähiger Kompromiss:

  • CIS L1 als Basis (Festplattenverschlüsselung, Endgeräteschutz, kein SMBv1).
  • L2 selektiv: Mehr-Faktor-Authentisierung, Festplattenverschlüsselung vor dem Start, Auditprotokollierung, Sperre des Schlüsselexports.
  • Anwendungssteuerung im reinen Auditmodus für Entwicklergeräte (protokollieren, nicht blockieren).
  • Endpoint Privilege Management - Just-in-time-Rechteerhöhung statt dauerhafter Administratorrechte.

Im Einklang mit NIST SP 800-53 Rev. 5 AC-6 [3] (Least Privilege) - Rechte passend zur Rolle, aber nicht dauerhaft.

Womit beginnt das Hardening von Docker und Kubernetes?

Der CIS Docker Benchmark und der CIS Kubernetes Benchmark [1] sind der Standard. Den schnellsten Nutzen bringen:

  1. Image-Scans in CI/CD (Trivy, Snyk, Grype) - kein Image mit kritischer Schwachstelle gelangt in die Produktion.
  2. Distroless-Images oder mindestens eine minimale Basis (Alpine, Wolfi) - kleinere Angriffsfläche.
  3. Betrieb ohne Root-Rechte im Image (run as user > 0, bei Bedarf eines Ports unter 1024 mit der Capability NET_BIND_SERVICE).
  4. Schreibgeschütztes Root-Dateisystem (readOnlyRootFilesystem: true).
  5. NetworkPolicy in Kubernetes - Default Deny plus ausdrückliche Freigaben.
  6. Pod Security Standards (restriktives Profil in der Produktion).
  7. Falco oder Tetragon - Überwachung des Laufzeitverhaltens der Container (siehe SOC).

Brauchen Sie Beratung in diesem Bereich?

Eine kostenlose 30-60 minütige Beratung. Ohne Verpflichtungen. Wir besprechen Bedarf, Umfang und einen groben Zeitplan.

Anrufen: +48 691 122 312 office@4crypto.eu

Verwandte Inhalte

Weitere Kompetenzbereiche

Compliance und Regulierung

Bibliografie und Quellen

Alle zitierten Quellen sind öffentlich zugänglich. ISO/IEC-Normen, IETF-RFCs, EU-Richtlinien und nationale Rechtsakte verweisen auf die Originaldokumente.

  1. [1]guidelineCenter for Internet Security (2026). CIS Benchmarks. Zalecenia konfiguracyjne dla ponad 25 rodzin produktów - systemy operacyjne, chmura, sieć, bazy danych, kontenery. CIS · https://www.cisecurity.org/cis-benchmarks
  2. [2]guidelineDefense Information Systems Agency (DISA) (2024). Security Technical Implementation Guides (STIG). DISA Cyber Exchange · https://www.cyber.mil/stigs/
  3. [3]standardJoint Task Force (2020). NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. National Institute of Standards and Technology · DOI: 10.6028/NIST.SP.800-53r5
  4. [4]standardInternational Electrotechnical Commission (2018). IEC 62443 - Industrial communication networks - Network and system security. IEC · https://www.iec.ch/cyber-security
  5. [5]standardMITRE Corporation (2026). MITRE ATT&CK v19 (Enterprise, Mobile, ICS). Wydanie v19 z kwietnia 2026 r., aktualizacja v19.2 z 6 sierpnia 2026 r. MITRE · https://attack.mitre.org/
  6. [6]standardNational Institute of Standards and Technology (2024). NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, February 2024 · DOI: 10.6028/NIST.CSWP.29
  7. [7]standardScarfone, K., Jansen, W., Tracy, M. (2008). NIST SP 800-123: Guide to General Server Security. National Institute of Standards and Technology · DOI: 10.6028/NIST.SP.800-123
  8. [8]regulationParlament Europejski, Rada UE (2022). Dyrektywa (UE) 2022/2555 (NIS2) w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555
  9. [9]regulationParlament Europejski, Rada UE (2022). Rozporządzenie (UE) 2022/2554 (DORA) w sprawie operacyjnej odporności cyfrowej sektora finansowego. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022R2554
  10. [10]regulationParlament Europejski, Rada UE (2016). Rozporządzenie (UE) 2016/679 (RODO) w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych. Dziennik Urzędowy UE, L 119, 4.5.2016 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32016R0679
  11. [11]regulationRada Ministrów RP (2024). Rozporządzenie Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (KRI). Dz.U. 2024 poz. 773 · https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20240000773
  12. [12]standardInternational Organization for Standardization (2022). ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements. ISO/IEC · https://www.iso.org/standard/27001
  13. [13]regulationParlament Europejski, Rada UE (2024). Rozporządzenie (UE) 2024/1689 (AI Act) ustanawiające zharmonizowane przepisy dotyczące sztucznej inteligencji. Dziennik Urzędowy UE, L seria, 12.7.2024 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1689
  14. [14]regulationSejm RP (2018). Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Dz.U. 2018 poz. 1560; tekst jednolity Dz.U. 2026 poz. 20, ze zmianami Dz.U. 2026 poz. 252 (transpozycja NIS2, w mocy od 3 kwietnia 2026 r.), poz. 815 i poz. 1003. Tekst ujednolicony Kancelarii Sejmu, stan na 18 sierpnia 2026 r. · https://api.sejm.gov.pl/eli/acts/DU/2018/1560/text/U/D20181560Lj.pdf
4crypto.eu