Zero-Trust-Sicherheit auf Bare-Metal-Servern

Warum herkömmliche Perimeter-Sicherheit bei dedizierter Infrastruktur nicht klappt

Ein typischer dedizierter Server steht hinter einer Firewall, die Datenverkehr von bestimmten Ports zulässt. Sobald der Datenverkehr den Server erreicht, kommunizieren interne Dienste oft ohne zusätzliche Authentifizierung miteinander. MySQL hört auf Port 3306 und nimmt Verbindungen aus dem lokalen Netzwerk an. Redis ist für jeden auf dem Server laufenden Prozess zugänglich. Der Anwendungscode läuft mit weitreichenden Dateisystemberechtigungen.

Das klappt super, bis irgendwas innerhalb der Sicherheitszone kaputt geht. Eine Web-Shell, die über ein anfälliges WordPress hochgeladen wurde, kann jetzt direkt auf MySQL zugreifen. Ein kaputter Anwendungsprozess kann Dateien von anderen Anwendungen lesen. Die Sicherheitszone hat gehalten, das Innere aber nicht.

Zero Trust löst das, indem es das Konzept des „vertrauenswürdigen Internen“ komplett streicht. Jede Zugriffsanfrage – egal ob von einem externen Nutzer oder einem internen Dienst – wird überprüft, genehmigt und protokolliert.

Identitätsbasierte Zugriffskontrolle für Dienste

Die Basis von Zero Trust auf Serviceebene ist, dass sich Services gegenseitig authentifizieren und nicht nur gegenüber externen Benutzern.

Datenbankzugriff: MySQL sollte keine Verbindungen von 127.0.0.1 ohne Anmeldedaten akzeptieren, die auf die minimal erforderlichen Berechtigungen beschränkt sind. Erstelle anwendungsspezifische Datenbankbenutzer, anstatt root zu verwenden:

— Erstell einen Benutzer für die Anwendung mit nur den notwendigen Berechtigungen.

Benutzer „appname”@„127.0.0.1” anlegen, mit dem Passwort „strong_random_password”.

GRANT SELECT, INSERT, UPDATE, DELETE ON appname_db.* TO 'appname'@'127.0.0.1';

FLUSH PRIVILEGES;

— Privilegien überprüfen

Zeig die Berechtigungen für „appname“@„127.0.0.1“ an.

Die Web-App verbindet sich als „appname“ und kann nur auf „appname_db“ zugreifen. Selbst wenn diese Zugangsdaten offengelegt werden, ist der Schaden auf eine Datenbank beschränkt.

Redis-Zugriff: Redis lässt standardmäßig alle Verbindungen ohne Authentifizierung auf localhost zu. Schalte die Authentifizierung in /etc/redis/redis.conf ein:

Du musst dein starkes Redis-Passwort eingeben.

Binde 127.0.0.1

Mit einem starken Passwort und einer Bindung nur an Loopback brauchen Redis-Verbindungen sowohl eine Nähe zum Netzwerk als auch die richtigen Anmeldedaten.

Netzwerksegmentierung mit Namespaces und VLANs

Für Umgebungen mit mehreren Anwendungen auf einem einzigen dedizierten Server bieten Linux-Netzwerk-Namespaces eine Isolierung auf Anwendungsebene, ohne dass separate Hardware nötig ist:

# Create an isolated network namespace for an application

ip netns add appname_ns

# Create a veth pair (virtual ethernet cable)

ip link add veth0 type veth peer name veth1

# Move one end into the namespace

ip link set veth1 netns appname_ns

# Configure addressing

ip addr add 192.168.100.1/30 dev veth0

ip netns exec appname_ns ip addr add 192.168.100.2/30 dev veth1

# Bring interfaces up

ip link set veth0 up

ip netns exec appname_ns ip link set veth1 up

Prozesse, die innerhalb des Namespace laufen, können nur die Netzwerkadressen erreichen, die extra für sie eingerichtet wurden. Sie können nicht direkt auf Datenbanken oder Dienste zugreifen, die mit dem Host-Netzwerk verbunden sind, ohne über ein kontrolliertes Gateway zu gehen.

Für eine einfachere Isolierung mehrerer Mandanten können nftables-Regeln Kommunikationsrichtlinien zwischen Anwendungen auf demselben Server durchsetzen:

# Only allow MySQL connections from the application's specific process user (via UID match)

nft add rule inet filter output skuid 1001 tcp dport 3306 accept

nft add rule inet filter output tcp dport 3306 drop

Dadurch können nur Prozesse, die als UID 1001 (der Anwendungsbenutzer) laufen, eine Verbindung zu MySQL herstellen – alle anderen Prozesse werden auf Kernel-Ebene blockiert.

Mikrosegmentierung für den Datenverkehr innerhalb des Servers

AppArmor (Ubuntu/Debian) und SELinux (RHEL/AlmaLinux/Rocky Linux) bieten obligatorische Zugriffskontrolle auf Kernel-Ebene und beschränken, auf welche Dateien, Netzwerkressourcen und Systemaufrufe ein Prozess zugreifen kann, unabhängig von den Unix-Berechtigungen.

Ein AppArmor-Profil für Nginx es nur auf die benötigten Ressourcen beschränkt:

/etc/apparmor.d/usr.sbin.nginx:

#include <tunables/global>

/usr/sbin/nginx {

  #include <abstractions/base>

  #include <abstractions/nameservice>

  capability net_bind_service,

  capability setuid,

  capability setgid,

  /var/www/** r,

  /etc/nginx/** r,

  /var/log/nginx/** w,

  /run/nginx.pid rw,

  # Deny everything else

  deny /home/** rwx,

  deny /root/** rwx,

  deny /etc/shadow r,

}

Wenn dieses Profil aktiv ist, kann ein Angreifer, selbst wenn er Code im Nginx ausführen kann, weder /etc/shadow lesen noch auf Benutzerverzeichnisse zugreifen oder außerhalb vonnginx schreiben. Der Kernel sorgt dafür, dass diese Einschränkungen gelten, egal was der Code des Angreifers versucht.

Die AppArmor-Dokumentation erklärt, wie man Profile entwickelt und welche Durchsetzungsmodi es gibt. Fang im Complain-Modus an (Verstöße werden protokolliert, aber nicht blockiert), um dein Profil zu checken, bevor du zum Enforce-Modus wechselst.

Zero-Trust-Zugriff für den administrativen Zugriff

Bei SSH-Zugängen Zero Trust anzuwenden heißt, dass man statische Anmeldedaten durch kurzlebige, identitätsgeprüfte Zertifikate ersetzt.

Die HashiCorp Vault SSH-Zertifizierungsstelle gibt SSH-Zertifikate raus, die nach einer einstellbaren Zeit ablaufen – 30 Minuten, 1 Stunde, 8 Stunden. Ein Techniker meldet sich mit seinen Zugangsdaten bei Vault an, bekommt ein kurzlebiges SSH-Zertifikat und nutzt es, um sich mit dem Server zu verbinden. Wenn das Zertifikat geklaut wird, läuft es bald ab. Wenn der Techniker die Firma verlässt, kann er durch den Entzug seines Vault-Zugangs sofort keine neuen Zertifikate mehr bekommen.

Die Dokumentation zur SSH-Geheimnis-Engine von Vault erklärt, wie man die serverseitige Überprüfung und die Ausstellung von Client-Zertifikaten einrichtet.

Für Teams, die noch nicht bereit sind, Vault einzusetzen, gibt's 'ne einfachere Zero-Trust-Verbesserung für SSH: IP-Zulassungslisten zusammen mit Zertifikatsrotation.

# In /etc/ssh/sshd_config

# Match only connections from corporate VPN or jump host IP

Match Address 10.0.0.0/8

  PasswordAuthentication no

  PubkeyAuthentication yes

Match Address *

  DenyUsers *

Protokollierung und ständige Überprüfung

Zero Trust ohne Protokollierung ist nur Wunschdenken. Jede Zugriffsentscheidung braucht einen Prüfpfad. Für einen dedizierten Server:

SSH-Zugriffsprotokollierung: Überprüfe die sshd-Protokolle in /var/log/auth.log (Debian) oder /var/log/secure (RHEL). Jeder Anmeldeversuch, egal ob erfolgreich oder nicht, wird mit der Quell-IP und dem Benutzernamen aufgezeichnet.

Protokollierung auf Anwendungsebene: Stell sicher, dass deine Anwendung nicht nur Anfragen, sondern auch die Aktionen von angemeldeten Benutzern protokolliert. Halte fest, wer jede Aktion durchgeführt hat, und nicht nur, dass die Aktion passiert ist.

Zentralisierte Protokollübertragung: Protokoll-Daten, die nur auf dem angegriffenen Server gespeichert sind, können von einem Angreifer gelöscht werden. Schick die Protokolle an einen Remote-Syslog-Empfänger oder einen Cloud-Protokollierungsdienst, auf den der Server nicht schreiben oder löschen kann.

Regelmäßige Zugriffsüberprüfung: Schau dir jeden Monat alle aktiven SSH-Schlüssel in /root/.ssh/authorized_keys und in ~/.ssh/authorized_keys von jedem Benutzer an. Lösche Schlüssel von ehemaligen Mitarbeitern, ehemaligen Auftragnehmern oder Systemen, die keinen Zugriff mehr brauchen.

Zero Trust ist ein fortlaufender Prozess, keine einmalige Implementierung

Die Unternehmen mit der besten Sicherheitslage bei dedizierter Infrastruktur haben Zero Trust nicht einfach so über Nacht eingeführt. Sie haben mit den risikoreichsten Zugangswegen angefangen – SSH, Datenbankverbindungen – und dort zuerst Identitätsprüfung und Protokollierung eingebaut. Dann haben sie sich nach innen vorgearbeitet und die Kommunikation zwischen Diensten sowie die Zugriffskontrollen auf Prozessebene verbessert.

Der Managed Service „Premier Care“ von InMotion umfasst die grundlegende Sicherheitskonfiguration, die für einen dedizierten Produktionsserver passt. Teams, die unter strengen Compliance-Anforderungen oder Bedrohungsmodellen arbeiten – Finanzdienstleistungen, Gesundheitswesen, regulierte Daten – legen in der Regel zusätzliche Zero-Trust-Kontrollen über diese Basis hinaus an.

Weiterführende Literatur: Best Practices für die Absicherung von Servern | DDoS-Schutzstrategien für dedizierte Infrastruktur