Härtung: Baselines, Vertrauensgrenzen und Admin-Kontrollen

Härtung ist die kontrollierte Überführung eines Systems in einen dokumentierten, begründeten und überprüfbaren Sollzustand. Sie beschränkt Funktionen, Zugänge und Vertrauensbeziehungen auf das betriebliche Minimum, ohne den vorgesehenen Dienst unkontrolliert zu beschädigen. Das Ergebnis ist keine möglichst lange Liste aktivierter Sicherheitsoptionen, sondern eine Architektur, in der jede erreichbare Schnittstelle, jedes Privileg und jeder Datenfluss einen benannten Zweck, einen Eigentümer und einen Nachweis besitzt. NIST beschreibt Server Security entsprechend als Auswahl, Umsetzung und laufende Pflege geeigneter Kontrollen; CIS Control 4 verlangt sichere Konfigurationen für Assets und Software (NIST SP 800-123, CIS Control 4: Secure Configuration).

Ein Produktdefault ist dabei weder automatisch unsicher noch automatisch die richtige Produktionsbaseline. Hersteller müssen breite Funktions- und Kompatibilitätsbereiche abdecken. Der Betreiber kennt dagegen Exponierung, Schutzbedarf, Abhängigkeiten, Recovery-Fähigkeit und akzeptierte Restrisiken. Eine Baseline verbindet deshalb Herstellerempfehlungen, eine passende CIS- oder BSI-Referenz und die eigene Architekturentscheidung. Abweichungen werden nicht stillschweigend beibehalten, sondern mit Ursache, Risiko, kompensierender Kontrolle, Eigentümer und Ablaufdatum dokumentiert. CIS Benchmarks sind konsensbasierte Konfigurationsempfehlungen; das BSI trennt allgemeine Serveranforderungen von mailbezogenen Anforderungen (CIS Benchmarks, BSI SYS.1.1 Allgemeiner Server, BSI APP.5.3 Allgemeiner E-Mail-Client und -Server).

Härtung beginnt mit dem realen Dienst und seinen Administrationswegen, nicht mit einer beliebigen Liste von Registrywerten. Zuerst werden Komponenten, Identitäten, Daten und Netzwerkpfade inventarisiert; daraus entstehen Baseline, Ausnahmen und überprüfbare Kontrollen.

Von der Checkliste zum Kontrollflächenmodell

Für Admins ist eine nach Kontrollflächen gegliederte Prüfung belastbarer als eine einzige Host-Checkliste. Das folgende Modell fasst Kontrollen aus NIST SP 800-53 zusammen: Konfigurationsmanagement und Least Functionality, Zugriff und Authentisierung, Kommunikationsschutz, Systemintegrität, Audit sowie Supply-Chain- und Recovery-Kontrollen. Es ist ein Prüfmodell, keine zusätzliche Norm (NIST SP 800-53 Rev. 5, NIST SP 800-53 Rev. 5, PDF).

NIST Zero Trust ergänzt eine wichtige Grenze: Ein Benutzer, Dienst oder Gerät erhält nicht allein deshalb Vertrauen, weil es im internen Netz steht oder der Organisation gehört. Authentisierung und Autorisierung werden vor dem Zugriff auf eine Ressource ausgewertet. Segmentierung bleibt nützlich, ersetzt aber keine Identität, Policy und laufende Entscheidung (NIST SP 800-207).

Technologiestack als Härtungsinventar

Härtung besitzt keinen eigenen Programmiersprachen- oder Produktstack. Sie wird auf den tatsächlich betriebenen Technologiestack angewendet. Das Inventar umfasst deshalb mindestens Firmware und Hypervisor, Betriebssystem oder Containerbasis, Laufzeit und Programmiersprache, Web- und Mailserver, Bibliotheken und Parser, Datenbank, Queue und Object Store, Identitäts- und Schlüsselkomponenten, Managementprotokolle sowie Logging- und Updatepfade. NIST CM-8 verlangt ein Inventar der Systemkomponenten; CM-7 verbindet dieses Inventar mit der Beschränkung auf notwendige Funktionen (NIST SP 800-53 Rev. 5).

Für jede Schicht werden Hersteller, Herkunft, Supportstatus, aktive Module, Privilegien, Listener, Egressziele, Konfigurationsquelle, Patchweg und Recoveryobjekt festgehalten. Nur so lässt sich eine Empfehlung wie «unnötige Dienste deaktivieren» auf einen konkreten Prozess und dessen Abhängigkeiten anwenden, ohne den Mailflow oder die Wiederherstellbarkeit zu beschädigen.

Vertrauensgrenzen einer Messaging-Plattform

Eine Messaging-Plattform besitzt mehrere technisch verschiedene Eintrittswege. Sie dürfen nicht mit einer einzigen Regel «nur authentisierte Verbindungen» behandelt werden:

• Internet-Relay: Ein öffentlich erreichbarer MTA nimmt auf SMTP Port 25 Nachrichten von nicht vorab bekannten MTAs entgegen. Hier begrenzen Empfängerprüfung, Relay-Policy, Protokollzustände, Ressourcenlimits, Reputation und Inhaltskontrollen das Risiko; eine Benutzeranmeldung ist nicht das allgemeine Vertrauensmodell.
• Message Submission: Benutzer und Anwendungen übergeben neue Nachrichten als identifizierte Absender. Submission trennt diese Rolle vom Relay; Authentisierung, Autorisierung, Rate Limits und TLS gehören zur Policy.
• Mailzugriff: IMAP, POP oder HTTP greifen auf vorhandene Mailboxdaten zu. RFC 8314 betrachtet Klartext für Submission und Mailzugriff als veraltet und bevorzugt implizites TLS.
• Interne Servicepfade: Gateways, Verzeichnisse, Datenbanken, Objektstores, Queues und Scanner sprechen als Dienste miteinander. Netzwerkstandort allein ist kein Identitätsnachweis; jede Verbindung braucht einen minimalen, gerichteten Daten- und Berechtigungspfad.
• Management und Updates: Admin-GUI, API, SSH, Remoting, Backup und Softwarebezug besitzen einen höheren Schadensradius als ein normaler Clientpfad und gehören in eine eigene Management- und Vertrauenszone.

NIST SP 800-177 behandelt Domainauthentisierung, TLS und Inhaltskryptografie als ergänzende Sicherheitsmechanismen rund um das weiterhin verwendete SMTP. RFC 8314 trennt Relay bewusst von Submission und Access. Daraus folgt: Härtung muss pro Rolle prüfen, wer eine Verbindung initiieren darf, welche Identität sie trägt, welche Daten sie verarbeitet und wohin sie weiter kommunizieren darf (NIST SP 800-177 Rev. 1, RFC 8314, RFC 5321).

Das Inventar zeigt, was geschützt werden muss. Eine Baseline übersetzt es in konkrete Einstellungen, die versioniert, getestet und bei begründeten Ausnahmen nachvollziehbar geändert werden.

Baseline-Lifecycle und kontrollierte Abweichung

Eine wirksame Baseline durchläuft einen Lebenszyklus:

1. Inventarisieren: Produkt, Rolle, Softwarestand, Module, Listener, Konten, Datenflüsse, Schlüssel und Abhängigkeiten erfassen.
2. Referenz wählen: Herstellerbaseline, CIS Benchmark, BSI-Baustein und gesetzliche Anforderungen auf die konkrete Rolle abbilden.
3. Tailoring: Nicht anwendbare Regeln entfernen, strengere Regeln ergänzen und Abweichungen risikobasiert begründen.
4. Pilotieren: Funktion, Performance, Mailflow, Monitoring, Backup und Disaster Recovery in einer repräsentativen Umgebung prüfen.
5. Deklarativ ausrollen: GPO, Configuration Management, Image, Policy-as-Code oder Hersteller-API statt manueller Einzeländerungen verwenden.
6. Kontinuierlich prüfen: Drift, neue Konten, Listener, Pakete, Zertifikate, Regeln und Baselineänderungen erkennen.
7. Ausser Betrieb nehmen: Zugang, DNS, Zertifikate, Schlüssel, Daten, Backups und Monitoring kontrolliert entfernen.

Microsofts Security Compliance Toolkit kann empfohlene Windows-Baselines speichern, analysieren, vergleichen, bearbeiten und als GPO anwenden. Es ersetzt das Tailoring nicht: Eine Baseline wird zuerst in einer Pilotgruppe auf Funktion und Nebenwirkungen geprüft. Gleiches gilt für CIS- und BSI-Empfehlungen (Microsoft Security Compliance Toolkit, CIS Benchmarks FAQ).

Least Functionality: Dienste, Ports und Software

NIST-Kontrolle CM-7 verlangt, ein System auf geschäftlich notwendige Fähigkeiten zu konfigurieren und Funktionen, Ports, Protokolle, Software oder Dienste zu verbieten beziehungsweise einzuschränken. Die technische Frage lautet nicht «Ist Port 443 sicher?», sondern: Welcher Prozess lauscht auf welcher Adresse, für welche Rolle, aus welcher Zone und mit welchem Patch- und Identitätsmodell? (NIST SP 800-53 Rev. 5, CM-7).

Unnötige Web-UIs, Debug-Endpunkte, Discovery-Protokolle, lokale Datenbanklistener und Legacy-Managementdienste werden deaktiviert. Benötigte Dienste binden möglichst nur an die vorgesehenen Interfaces. Ein MTA darf öffentlich auf SMTP lauschen, seine Datenbank aber nicht. Ein Admin-API-Port kann notwendig sein, gehört jedoch nicht automatisch ins Internet. CISA empfiehlt für Kommunikationsinfrastruktur, unbenötigte oder unverschlüsselte Dienste wie Telnet, FTP, TFTP, HTTP und ältere SNMP-Varianten abzuschalten und öffentlich erreichbare Dienste fortlaufend zu inventarisieren (CISA: Enhanced Visibility and Hardening Guidance).

Listener und aktive Dienste inventarisieren

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess
Get-Service | Where-Object Status -eq Running |
  Sort-Object Name

ss -lntup
systemctl list-units --type=service --state=running

Get-NetTCPConnection und ss zeigen lokale Listener und Prozesse. Get-Service und systemctl zeigen aktive Dienste. Der Soll/Ist-Vergleich braucht anschliessend eine freigegebene Port- und Dienstmatrix; ein unbekannter Listener ist ein Befund, aber noch keine Ursachenanalyse.

Nach dem Entfernen unnötiger Funktionen bleiben die Konten und Dienste, die tatsächlich handeln dürfen. Ihre Rechte, Anmeldewege und Secrets bestimmen den grössten Teil der administrativen Angriffsfläche.

Identitäten, Konten und Least Privilege

Konten werden nach Rolle getrennt: normale Benutzeridentität, persönliche Adminidentität, nicht-interaktives Dienstkonto und streng kontrolliertes Notfallkonto. Geteilte Admin-Logins verhindern belastbare Attribution. Dauerhaft hochprivilegierte Alltagskonten vergrössern den Schadensradius von Phishing, Browser- und Clientkompromittierungen. CIS Control 5 umfasst Benutzer-, Admin- und Dienstkonten; CIS Control 6 die Vergabe, Pflege und Entziehung ihrer Credentials und Privilegien (CIS Control 5: Account Management, CIS Control 6: Access Control Management).

Zentrale Identität verbessert Joiner/Mover/Leaver-Prozesse, ersetzt aber keinen lokalen Notfallpfad. Ein LDAP-, Kerberos- oder SSO-Ausfall darf den autorisierten Recovery-Zugriff nicht unmöglich machen. Break-Glass-Konten sind deshalb eine bewusst kleine Ausnahme: offline dokumentiert, stark geschützt, nicht für Alltag verwendet, bei Nutzung sofort alarmiert und regelmässig getestet. Dienstidentitäten erhalten keine interaktive Anmeldung und nur die Rechte, Netzwerkziele und Secrets ihrer Aufgabe. Wo möglich, werden kurzlebige Tokens, Managed Identities oder Zertifikate statischen Passwörtern vorgezogen; ihr Lifecycle und ihre Recovery bleiben Teil des Betriebs.

MFA reduziert das Risiko gestohlener Passwörter, ist aber kein Ersatz für minimale Rechte und sichere Recovery. NIST Zero Trust verlangt eine Zugriffentscheidung für Subjekt und gegebenenfalls Gerät vor der Sitzung; Netzstandort oder Besitz allein genügt nicht (NIST SP 800-207).

Lokale und privilegierte Konten prüfen

Get-LocalUser | Select-Object Name, Enabled, LastLogon, PasswordExpires
Get-LocalGroupMember -Group Administrators

getent passwd
getent group sudo wheel

Get-LocalUser und Get-LocalGroupMember lesen lokale Windows-Konten und Gruppenmitgliedschaften. getent fragt die konfigurierten Name-Service-Datenbanken ab und kann deshalb lokale sowie zentral aufgelöste Konten zeigen. Ein Review muss zusätzlich tatsächliche Rollen im Produkt, API-Tokens, SSH-Schlüssel, Zertifikate und Cloud-IAM erfassen.

Managementebene und Administrationspfade

Die Managementebene kann Konfiguration, Schlüssel, Routing, Updates und Logs verändern und verdient eine strengere Grenze als der Nutzdatenpfad. CISA empfiehlt ein Out-of-Band-Managementnetz, das physisch oder logisch vom operativen Datenfluss getrennt ist, Default-Deny-Regeln, dedizierte Admin-Arbeitsplätze und zentrale AAA-Protokollierung. Laterale Managementverbindungen zwischen Geräten sollen ebenfalls begrenzt werden (CISA: Enhanced Visibility and Hardening Guidance).

Für Messaging-Systeme bedeutet das:

• Admin-GUI, API, SSH und Remoting sind nur aus definierten Adminzonen oder über einen kontrollierten Bastion-Pfad erreichbar.
• Management- und Mailflow-Zertifikate, Konten und Firewall-Regeln werden getrennt geführt.
• Ausgehende Verbindungen der Managementebene sind auf Update-, Identitäts-, Zeit-, Log- und Backupziele beschränkt.
• Konfigurationsänderungen benötigen persönliche Identität, möglichst MFA, Audit und bei hohem Risiko Vier-Augen-Freigabe.
• Ein Notfallpfad funktioniert ohne die reguläre Identity- oder Managementplattform, wird aber nicht als verdeckter Dauerzugang betrieben.

SSH ist nur ein Transport für Administration; seine Sicherheit hängt von Authentisierung, erlaubten Benutzergruppen, Schlüsselalgorithmen, Forwarding, Dateirechten und Zielrechten ab. Effektive Serverkonfiguration statt nur die Textdatei zu prüfen, erkennt Includes und Defaults.

Effektive SSH-Serverkonfiguration ausgeben

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Server*'
& "$env:WINDIR\System32\OpenSSH\sshd.exe" -T

sshd -T

Get-WindowsCapability zeigt die installierte OpenSSH-Komponente; Microsoft dokumentiert Pfade und Besonderheiten der sshd_config. sshd -T gibt die wirksame Konfiguration aus. Optionen dürfen nicht blind nach Internet-Checklisten gesetzt werden: Verfügbarkeit des Notfallzugangs, verwendete Schlüsseltypen und Automatisierung gehören in den Test.

Netzwerkpfade: Default Deny mit expliziter Richtung

Eine Firewall-Regel wird als gerichteter Vertrag dokumentiert: Quelle, Ziel, Protokoll/Port, Initiator, Identität, Verwendungszweck, Eigentümer und Ablaufdatum. «Mailserver darf ins Internet» ist keine technische Spezifikation. Ein eingehender SMTP-Listener benötigt andere Egress-Ziele als ein Malware-Sandbox-Worker oder die Admin-API. Egress-Filter begrenzen Command-and-Control, Exfiltration und unkontrolliertes Nachladen; sie müssen DNS, Zeit, Zertifikatsprüfung, Updates und Zustellziele bewusst berücksichtigen.

Segmentierung reduziert den Bewegungsraum nach einer Kompromittierung. Sie ist besonders wichtig zwischen Internet-Edge, Mailverarbeitung, Mailbox-/Datenspeicher, Verzeichnis, Management, Backup und Monitoring. NIST Zero Trust warnt zugleich davor, Netzwerkposition als alleinige Vertrauensgrundlage zu verwenden. CISA empfiehlt für Managementpfade Default Deny und eine vom Kundendatenverkehr getrennte Zone (NIST SP 800-207, CISA: Enhanced Visibility and Hardening Guidance).

Host-Firewall und Regelrichtung prüfen

Get-NetFirewallProfile |
  Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction
Get-NetFirewallRule -Enabled True |
  Select-Object DisplayName, Direction, Action, Profile

nft list ruleset

Get-NetFirewallProfile und Get-NetFirewallRule zeigen Windows-Profile und aktive Regeln. nft zeigt die nftables-Regeln inklusive Chains und Richtung. Die Ausgabe wird gegen die freigegebene Datenflussmatrix geprüft; eine Default-Deny-Policy ohne benötigte DNS-, Zeit- oder Zertifikatsziele ist kein erfolgreicher Härtungszustand.

Mailprotokolle und Transportvertrauen

Relay, Submission und Access benötigen unterschiedliche TLS- und Authentisierungsregeln. Für Submission und Zugriff empfiehlt RFC 8314 TLS 1.2 oder höher und bevorzugt implizites TLS; Klartextzugriff soll nicht weiter angeboten werden. Für SMTP-Relay beschreibt STARTTLS dagegen eine hopweise Aushandlung. Ohne zusätzliche Policy kann ein sendender MTA bei fehlendem TLS weiter in Klartext zustellen. DANE und MTA-STS schaffen unterschiedliche, explizitere Transportpolicies (RFC 8314, RFC 3207, RFC 7672, RFC 8461).

SPF, DKIM und DMARC authentisieren Domänenbezüge und Policy, nicht Benutzerkonten oder den Inhalt als solchen. S/MIME und OpenPGP schützen Nachrichtenteile, ändern aber nichts an einem unsicheren Adminzugang oder einer kompromittierten Schlüsselablage. Eine Härtungsprüfung hält diese Sicherheitsleistungen getrennt und kontrolliert ihre Abhängigkeiten: DNS, Zertifikate, Schlüssel, Zeit, Reports und Ausnahmeregeln. NIST SP 800-177 ordnet genau diese ergänzenden Mechanismen um SMTP und DNS ein (NIST SP 800-177 Rev. 1).

Erreichbarkeit und TLS-Verhalten prüfen

Test-NetConnection mx.example.ch -Port 25 -InformationLevel Detailed
curl.exe --verbose --ssl-reqd smtp://mx.example.ch:25

nc -vz mx.example.ch 25
openssl s_client -starttls smtp -connect mx.example.ch:25 \
  -servername mx.example.ch -verify_return_error

Test-NetConnection und nc prüfen den TCP-Pfad. curl und openssl s_client zeigen STARTTLS, Zertifikatskette und Fehler. Erst MTA-Policy und Logs beantworten, ob bei einem Fehler verzögert, abgewiesen oder auf Klartext zurückgefallen wird.

Anwendung, Daten, Parser und Schlüssel

Mailserver verarbeiten absichtlich nicht vertrauenswürdige, komplexe Formate. MIME-Nachrichten, Archive, Dokumente, Bilder und HTML erreichen Parser, Scanner, Konverter, Vorschauen und Sandboxes. Härtung begrenzt deshalb nicht nur Netzwerkports, sondern auch Prozessrechte, Dateisystemzugriff, temporären Speicher, CPU/RAM/Dateigrösse, Rekursion, Ausführbarkeit und Egress der Analysekomponenten. Ein Scanner braucht Zugriff auf ein Prüfobjekt, aber nicht automatisch auf alle Mailboxen, Admin-Secrets oder die Management-API.

Queues und temporäre Verzeichnisse enthalten vertrauliche Inhalte. Dateirechte, Verschlüsselung, Lösch- und Retentionregeln sowie Debug-Dumps werden ausdrücklich geprüft. Logs sollen Zustände und Entscheidungen nachvollziehbar machen, aber keine Passwörter, Tokens, privaten Schlüssel oder unnötigen Nachrichteninhalt erfassen. Schlüssel werden nach Zweck getrennt: TLS, DKIM, S/MIME/OpenPGP, JWT/API und Backup-Verschlüsselung besitzen verschiedene Lebenszyklen, Berechtigungen und Recovery-Regeln. NIST SP 800-53 verbindet Least Privilege, Systemintegrität, Kommunikationsschutz und Audit; BSI APP.5.3 konkretisiert den Schutzbedarf für E-Mail-Client und -Server (NIST SP 800-53 Rev. 5, BSI APP.5.3 Allgemeiner E-Mail-Client und -Server).

Patches, Images und Lieferkette

Patchmanagement ist präventive Wartung, kein sporadischer Notfall. NIST definiert den Prozess als Identifikation, Priorisierung, Bezug, Installation und Verifikation von Patches, Updates und Upgrades. Für exponierte Mail- und Managementkomponenten müssen Schwachstelleninformation, erreichbare Angriffsfläche, aktive Ausnutzung, Datenkritikalität und verfügbare Kompensation die Priorität beeinflussen (NIST SP 800-40 Rev. 4).

Der Updatepfad ist selbst eine Vertrauensgrenze. Pakete, Images, Container, Plugins, Virensignaturen und Appliance-Firmware werden aus authentisierten Quellen bezogen und mit Hersteller-Signatur oder veröffentlichtem Hash geprüft. Abhängigkeiten und Repositorywechsel gehören ins Inventar. NIST SP 800-161 behandelt Risiken von Produkten und Diensten, deren Entwicklung, Integration und Bereitstellung der Betreiber nur eingeschränkt einsehen oder kontrollieren kann (NIST SP 800-161 Rev. 1).

Ein Härtungsupdate wird in einer repräsentativen Stufe getestet: Start, Mailflow, Queue, TLS, Verzeichnis, Policy, Monitoring, Backup und Rollback. «Nicht patchen, weil Mail kritisch ist» tauscht ein bekanntes Betriebsrisiko gegen ein wachsendes Sicherheitsrisiko. Der bessere Entwurf schafft Redundanz, Wartungsfenster, reproduzierbare Builds und getestete Rückfallwege.

Artefaktintegrität und sicherheitsrelevante Ereignisse

Get-FileHash .\mail-gateway-update.bin -Algorithm SHA256
Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=(Get-Date).AddHours(-4)} |
  Select-Object TimeCreated, Id, ProviderName, Message

sha256sum mail-gateway-update.bin
journalctl --since '-4 hours' --priority=notice..alert

Get-FileHash und sha256sum vergleichen ein Artefakt mit einem erwarteten Hash aus einer authentisierten Herstellerquelle. Get-WinEvent und journalctl lesen Ereignisse; produktive Erkennung benötigt zusätzlich korrekte Auditpolicy, zentrale Sammlung, Zeitsynchronisation und definierte Alarme.

Eine gehärtete Konfiguration bleibt nur dann wirksam, wenn Änderungen, fehlgeschlagene Kontrollen und Abweichungen sichtbar werden. Deshalb gehören Logging und Drift-Erkennung zum Betrieb und nicht erst zur Nachkontrolle.

Logging, Telemetrie und Drift

Ein gehärteter Zustand ist ohne Beobachtung nicht dauerhaft. Relevante Signale sind unter anderem:

• erfolgreiche und fehlgeschlagene Anmeldungen, MFA- und Break-Glass-Nutzung;
• Konto-, Rollen-, Token-, Zertifikats- und Schlüsseländerungen;
• Konfigurationsänderungen und Abweichungen von der Baseline;
• neue Listener, Dienste, Pakete, Tasks, Container oder ausgehende Ziele;
• Firewall-Drops, unerwartete Egress-Verbindungen und Managementzugriffe;
• TLS-, DNS-, SMTP-Policy-, Queue- und Mailauthentifizierungsfehler;
• deaktivierte Sensoren, Loglücken, Speicherengpässe und Zeitabweichung.

Logs werden zentral und zugriffsgeschützt gesammelt, damit ein kompromittierter Host seine Spuren nicht einfach zusammen mit dem Systemzustand entfernt. CIS Control 8 fordert einen Logmanagementprozess, ausreichenden Speicher, standardisierte Zeit, detaillierte und zentralisierte Auditlogs sowie Reviews. Ein Alarm gilt erst als implementiert, wenn ein kontrolliertes Ereignis ihn auslöst, die zuständige Stelle ihn sieht und ein Runbook zur Reaktion führt (CIS Control 8: Audit Log Management).

Drift-Erkennung vergleicht den tatsächlichen Zustand mit der versionierten Baseline. Der Vergleich umfasst mehr als Dateihashes: effektive Konfiguration, Konten, Gruppen, IAM-Rollen, Zertifikate, Firewallregeln, Listener, Dienste, installierte Pakete, Images, geplante Jobs und Anbieterpolicy. Notfalländerungen werden nachgeführt oder automatisch zurückgenommen; andernfalls wird der «temporäre» Ausnahmezustand zum neuen, undokumentierten Default.

Technische Entwicklung

Saltzer und Schroeder formulierten 1975 grundlegende Schutzprinzipien wie kleine und einfache Mechanismen, sichere Defaults, vollständige Autorisierungsprüfung, Trennung von Privilegien und Least Privilege. Ihr Ausgangspunkt war nicht ein bestimmtes Betriebssystem, sondern die Architektur kontrollierter Informationsfreigabe in Mehrbenutzersystemen (Saltzer/Schroeder: Basic Principles of Information Protection).

Mit verbreiteten Netzwerkservern verlagerte sich Härtung zusätzlich auf entfernte Dienste, Protokolle, Patching, Audit und sichere Konfigurationspflege. NIST SP 800-123 fasste diese Serverpraxis 2008 systematisch zusammen. Konsensbasierte CIS Benchmarks, BSI-Grundschutz-Bausteine und Herstellerbaselines machten sichere Sollkonfigurationen reproduzierbarer und vergleichbar (NIST SP 800-123, CIS Benchmarks FAQ).

Cloud-, SaaS-, API- und Hybridarchitekturen schwächten später die Annahme eines klaren internen Perimeters. NIST SP 800-207 beschrieb 2020 Zero Trust als ressourcenorientierte Architektur ohne implizites Vertrauen aus Netzstandort oder Eigentum. Parallel wurden Softwarelieferkette, Imageherkunft und automatisierte Baseline-Drift zu eigenen Kontrollflächen. Moderne Härtung verbindet deshalb klassische Host-Minimierung mit Identität, Service-zu-Service-Policy, deklarativer Konfiguration, Lieferkettennachweisen, Telemetrie und getesteter Recovery (NIST SP 800-207, NIST SP 800-161 Rev. 1).

Admin-Checkliste

Härtung ist erst abgeschlossen, wenn die gewählten Massnahmen im normalen Betrieb und im Recoveryfall überprüfbar sind. Die Checkliste verbindet deshalb Konfiguration, Zuständigkeit und Nachweis.

• Rolle, Schutzbedarf, Datenflüsse und Vertrauensgrenzen des Systems sind dokumentiert.
• Hersteller-, CIS- und BSI-Empfehlungen wurden auf eine versionierte Baseline abgebildet.
• Jede Abweichung besitzt Begründung, kompensierende Kontrolle, Eigentümer und Ablaufdatum.
• Listener, Dienste, Pakete, Module und ausgehende Ziele sind auf das notwendige Minimum reduziert.
• Benutzer-, Admin-, Dienst- und Break-Glass-Identitäten sind getrennt und regelmässig geprüft.
• Adminzugänge verwenden persönliche Identität, MFA, minimale Rechte und zentrale Auditierung.
• Managementebene und produktiver Mailflow liegen in getrennten, restriktiven Zonen.
• Relay, Submission, Access und interne Servicepfade besitzen eigene TLS-, Auth- und Rate-Limit-Policies.
• Parser, Scanner, temporäre Daten, Queues, Schlüssel und Secrets haben minimale Prozess- und Dateirechte.
• Patches und Images stammen aus authentisierten Quellen; Herkunft und Integrität werden verifiziert.
• Baseline-, Mailflow-, Backup- und Rollbacktests laufen vor dem breiten Rollout.
• Logs sind zentral, zeitlich konsistent, gegen Änderung geschützt und mit getesteten Alarmen verbunden.
• Drift von Konten, Konfiguration, Regeln, Diensten, Zertifikaten und Software wird automatisch erkannt.
• Recovery und Notfallzugang wurden unter den gehärteten Bedingungen praktisch getestet.