Infrastruktur absichern 2026: eine praktische Checkliste

Infrastruktur 2026 abzusichern heißt, DNS, TLS, Server und Monitoring als eine zusammenhängende Angriffsfläche zu betrachten statt als vier getrennte Aufgaben. Die Grundanforderungen haben sich verschoben: Zero-Trust-Zugriffsmodelle sind heute Standard, TLS 1.0/1.1 sind tot, DNSSEC wird erwartet statt optional behandelt, und Post-Quanten-Kryptografie ist von der Forschung in veröffentlichte NIST-Standards übergegangen. Diese Checkliste geht durch, worauf es wirklich ankommt, sortiert nach Wirkung.

Bei der Identität anfangen, nicht beim Netzwerkperimeter

Das alte Modell – allem innerhalb der Firewall vertrauen – funktioniert nicht mehr, wenn Teams verteilt arbeiten und Workloads sich über mehrere Clouds erstrecken. NIST SP 800-207 definiert Zero-Trust-Architektur rund um eine Kernidee: niemals implizites Vertrauen aufgrund des Netzwerkstandorts. Jede Anfrage wird pro Sitzung bewertet, anhand von Identität, Gerätezustand und Kontext.

Praktische Schritte, die dich schon sehr weit bringen:

• Erzwinge Multi-Faktor-Authentifizierung (MFA) für jedes Konto mit Admin-, Root- oder DNS-Verwaltungsrechten – ohne Ausnahmen für „nur interne“ Konten.
• Ersetze langlebige statische Zugriffsschlüssel durch kurzlebige, eng begrenzte Zugangsdaten (temporäre Tokens über STS-artige Mechanismen), wo immer dein Cloud-Anbieter das unterstützt.
• Setze das Least-Privilege-Prinzip über eng gefasste IAM-Rollen um statt über breite Admin-Richtlinien – eine Deploy-Pipeline braucht keinen vollen Kontozugriff.
• Segmentiere den Zugriff nach Workload, nicht nach Netzwerkzone. Ein kompromittierter Webserver sollte keinen Weg zu deiner DNS- oder Abrechnungskonsole haben.

WarningTLS 1.0 und TLS 1.1 wurden mit RFC 8996 offiziell abgekündigt und sind in allen großen Browsern deaktiviert. Wenn irgendetwas in deinem Stack sie noch aushandelt, behandle das als aktive Schwachstelle, nicht als Kompatibilitätseinstellung.

DNS absichern – vor allem anderen

DNS ist der Teil deiner Infrastruktur, den Angreifer zuerst ins Visier nehmen, denn eine gekaperte Domain verschafft ihnen alles, was davon abhängt – E-Mail, SSL-Ausstellung und Traffic. Zwei Maßnahmen zählen 2026 am meisten:

1. DNSSEC (RFC 4033/4034/4035) signiert deine Zone kryptografisch, damit Resolver prüfen können, dass Einträge unterwegs nicht manipuliert wurden. DNS-Traffic wird dadurch nicht verschlüsselt – dafür gibt es DNS-over-HTTPS (RFC 8484) und DNS-over-TLS (RFC 7858) –, aber Cache-Poisoning- und Spoofing-Angriffe werden damit wirksam gestoppt.
2. CAA-Einträge (Certification Authority Authorization) legen fest, welche Zertifizierungsstellen Zertifikate für deine Domain ausstellen dürfen. Ohne einen solchen Eintrag kann jede öffentliche CA ein Zertifikat für deinen Namen ausstellen, wenn sie getäuscht oder kompromittiert wird.

domain.com. CAA 0 issue "letsencrypt.org"
domain.com. CAA 0 iodef "mailto:security@domain.com"

Ergänze außerdem Schutzmaßnahmen auf Registrar-Ebene: Aktiviere Registry Lock oder Transfer Lock, nutze für den Registrar-Zugang eine eigene (nicht geteilte) E-Mail-Adresse und schalte MFA beim Registrar ein – nicht nur beim Hosting. Einen vollständigen Überblick über die Eintragstypen und ihr Zusammenspiel findest du in unserem Leitfaden zu DNS-Eintragstypen. Die aktuelle Konfiguration jeder Domain kannst du mit dem kostenlosen DNS-Lookup-Tool prüfen.

Zertifikatsausstellung und -erneuerung automatisieren

Abgelaufene Zertifikate gehören nach wie vor zu den häufigsten selbst verschuldeten Ausfällen – und sie lassen sich vollständig vermeiden. TLS 1.3 (RFC 8446) ist die Baseline, die du einsetzen solltest: Es streicht veraltete Cipher, schreibt Forward Secrecy vor und wird von den meisten modernen Load Balancern und Reverse Proxys direkt unterstützt.

TipPrüfe deine Domain nach jeder Zertifikatsänderung mit dem kostenlosen SSL-Check-Tool – es verifiziert die vollständige Kette, nicht nur das Leaf-Zertifikat, und genau dort verstecken sich die meisten Fehlkonfigurationen.

Wenn du zwischen kostenlosen automatisierten und kostenpflichtigen Zertifikaten abwägst, zeigt unser Vergleich Let's Encrypt vs. kommerzielle SSL-Zertifikate, wann was sinnvoll ist. In jedem Fall gilt: Automatisiere die Erneuerung – manuelle Zertifikatsrotation skaliert nicht über eine Handvoll Domains hinaus und ist die am einfachsten zu beseitigende Fehlerquelle überhaupt.

Server und Container härten

Ob Bare Metal, VMs oder Kubernetes – es gelten dieselben Grundlagen:

• Deaktiviere anonymen oder nicht authentifizierten Zugriff auf Verwaltungs-APIs (Kubernetes-API-Server, Docker-Daemon-Socket, Cloud-Metadaten-Endpunkte).
• Betreibe Container ohne Root-Rechte und wende in Kubernetes-Umgebungen ein restriktives Pod-Security-Standard-Profil an.
• Patche nach Zeitplan, nicht reaktiv – ungepatchte CVEs in exponierten Diensten sind nach wie vor die Hauptursache für kompromittierte Server.
• Schließe jeden Port, den du nicht aktiv nutzt. Eine vergessene Firewall-Regel ist eine Tür, die du unverschlossen gelassen hast.

Supply-Chain-Sicherheit nicht vernachlässigen

Ein wachsender Anteil der Sicherheitsvorfälle entsteht in Build-Pipelines und Abhängigkeiten von Drittanbietern, nicht in deinem eigenen Code. Zwei Praktiken gelten inzwischen als Basis:

• SBOMs (Software Bill of Materials) im SPDX- oder CycloneDX-Format liefern dir ein maschinenlesbares Verzeichnis aller Abhängigkeiten eines Builds – unverzichtbar, wenn eine CVE veröffentlicht wird und du in Minuten statt Tagen wissen musst, ob du betroffen bist.
• SLSA (Supply-chain Levels for Software Artifacts) definiert aufsteigende Stufen für Build-Integrität und Herkunftsnachweis – von einfacher Versionskontrolle bis hin zu manipulationssicheren, vollständig verifizierbaren Builds.

Für den Einstieg braucht es bei beiden keinen großen Plattformumbau: Pinne Versionen deiner Abhängigkeiten, signiere Build-Artefakte und erzeuge im Rahmen deiner CI ein SBOM.

Die Migration zur Post-Quanten-Kryptografie im Blick behalten

NIST hat 2024 seine ersten Standards für Post-Quanten-Kryptografie verabschiedet: FIPS 203 (ML-KEM, Schlüsselkapselung), FIPS 204 (ML-DSA, Signaturen) und FIPS 205 (SLH-DSA, hashbasierte Signaturen). Die meisten CAs und Browser verlangen noch keine PQC-Zertifikate, aber hybrider Schlüsselaustausch taucht bereits in einigen TLS-Implementierungen auf. Migrieren musst du heute noch nicht – du solltest aber wissen, welche deiner Systeme ein Update brauchen, sobald CAs PQC-gestützte Zertifikate anbieten.

Alles überwachen – und sofort wissen, wenn etwas ausfällt

Sicherheitsmaßnahmen nützen nur, wenn du erfährst, dass sie versagen. Zertifikatsablauf, Änderungen an DNS-Einträgen und Ausfallzeiten brauchen aktives Monitoring – keine manuelle Prüfung einmal im Quartal.

Unser Leitfaden zum Website-Monitoring erklärt, wie Uptime-, Performance- und SSL-Checks zusammenspielen, und mit dem kostenlosen Is-it-down-Tool prüfst du schnell, ob wirklich ein Ausfall vorliegt, bevor du jemanden alarmierst.

Alles zusammenführen

Keine dieser Maßnahmen wirkt isoliert – eine signierte DNS-Zone mit abgelaufenem Zertifikat ist trotzdem eine kaputte Website, und ein gehärteter Server hinter einer unüberwachten Domain ist trotzdem nur einen Hijack von der Katastrophe entfernt. Genau in die Lücke zwischen DNS, Zertifikaten, Servern und Monitoring fallen die meisten Sicherheitsvorfälle, weil niemand das Gesamtbild verantwortet – deshalb lohnt sich die Verwaltung aus einer einzigen Ansicht.

Sieh dir an, wie die Infrastrukturmanagement-Funktionen von InfraNest DNS, SSL, Server und Monitoring in einem Dashboard zusammenführen, damit dir nichts von dieser Checkliste durchrutscht.