IT-Sicherheit
Netzwerkdiagramme zeigen einen geplanten Zustand. Für eine technische Begutachtung ist entscheidend, welche Dienste, Ports, Identitäten und Pfade im relevanten Systemstand tatsächlich erreichbar waren und welche Kontrollschichten den Zugriff begrenzten.
Kurzantwort
Die Prüfung verbindet Inventar, DNS, Routing, Firewalls, Load Balancer, Cloud-Regeln und anwendungsnahe Zugriffskontrollen. Erreichbarkeit wird aus definierten Perspektiven gemessen und mit dem dokumentierten Sollzustand verglichen. Dabei wird zwischen Netzwerksegmentierung, Identitätskontrolle und tatsächlicher Dienstexposition unterschieden.
Vom Untersuchungsstand zur nachvollziehbaren technischen Schlussfolgerung
1. Systemgrenzen und Beobachtungsperspektiven festlegen
Eine Aussage wie „intern“ oder „nicht öffentlich“ ist ohne Perspektive unpräzise. Zunächst werden Internet, Partnernetze, VPN, Administrationsnetze, Cloud-VPCs und lokale Segmente als mögliche Ausgangspunkte getrennt.
Bei hybriden Umgebungen können DNS, Routing und Security Groups je nach Netzpfad unterschiedliche Ergebnisse erzeugen. Die Prüfung dokumentiert daher, von wo aus eine Erreichbarkeit gemessen oder aus Konfigurationen abgeleitet wurde.
2. Tatsächlich exponierte Dienste inventarisieren
Öffentliche IP-Adressen, Load Balancer, Reverse Proxies, API-Gateways und Portfreigaben werden mit laufenden Diensten abgeglichen. Entscheidend ist nicht nur die offene Transportverbindung, sondern welcher Anwendungspfad dahinter erreichbar ist.
Veraltete Testsysteme, temporäre Administrationsports oder direkt adressierbare Backends können außerhalb der geplanten Architektur liegen. Solche Schattenpfade werden separat dokumentiert und nicht mit dem regulären Frontdoor-Pfad vermischt.
3. Segmentierung und Netzregeln technisch nachvollziehen
Firewalls, Security Groups, Netzwerk-ACLs und Service-Mesh-Regeln bilden unterschiedliche Kontrollschichten. Für die Bewertung wird ermittelt, welche Regel letztlich einen konkreten Pfad erlaubt oder blockiert.
Eine Segmentierung ist nur so belastbar wie die tatsächlich wirksame Konfiguration. Breite CIDR-Freigaben, überlappende Regeln oder alternative Routen können einen geplanten Schutzbereich faktisch erweitern.
4. Identitäts- und anwendungsbezogene Kontrollen ergänzend prüfen
NIST Zero Trust verschiebt den Fokus von einer pauschalen Vertrauensannahme des Netzes auf Ressourcen, Nutzer, Geräte und explizite Authentisierung und Autorisierung. Für die Begutachtung bedeutet das: Eine erreichbare Verbindung kann technisch akzeptabel sein, wenn der Zugriff dahinter wirksam identitätsgebunden kontrolliert wird.
Umgekehrt darf eine starke Anwendungsauthentisierung nicht als Ersatz für jede Netzbegrenzung missverstanden werden. Die Kontrollschichten werden getrennt erfasst, damit ihre jeweilige Wirkung und mögliche Umgehungspfade nachvollziehbar bleiben.
5. Soll-Dokumentation gegen Mess- und Konfigurationsbefund stellen
Architekturdiagramme und Sicherheitskonzepte sind Referenzquellen, keine Messwerte. Abweichungen werden daher nicht allein aus einem alten Diagramm abgeleitet, sondern mit aktuellen Konfigurationen, DNS-Auflösung, Routen und kontrollierten Verbindungstests abgeglichen.
Bei zeitbezogenen Fragestellungen müssen historische Regelstände berücksichtigt werden. Infrastructure-as-Code-Repositories, Cloud-Auditlogs oder Konfigurationssnapshots können helfen, eine frühere Exposition zu rekonstruieren.
6. Aussagebereich und nicht geprüfte Pfade offenlegen
Ein Portscan aus dem Internet beschreibt nur die Sicht dieser Quelle zu diesem Zeitpunkt. Er kann keine internen Ost-West-Pfade, Identitätsregeln oder zeitweise aktivierte Freigaben vollständig abdecken.
Die Schlussfolgerung benennt deshalb Perspektiven, getestete Protokolle, Stichtag und Konfigurationsquellen. So bleibt klar, ob eine Aussage auf aktiver Messung, Konfigurationsanalyse oder dokumentierter Architektur beruht.
Bei Cloud-Umgebungen ist die Bezeichnung „private“ nicht automatisch gleichbedeutend mit „nicht erreichbar“. Peering, private Endpoints, NAT, Tunnel und zentrale Transitnetze können zusätzliche Pfade schaffen, die in einer isolierten Betrachtung einzelner Security Groups nicht sichtbar sind.
Für Kubernetes- und Service-Mesh-Umgebungen können Ingress, Network Policies, Sidecars und anwendungsbezogene Policies gemeinsam relevant sein. Die technische Untersuchung sollte deshalb das reale Kommunikationsmodell abbilden, statt nur einen einzelnen Netzwerkfilter zu prüfen.
Bedeutet ein geschlossener Port, dass ein Dienst sicher ist?
Nein. Ein geschlossener oder gefilterter Port beschreibt nur einen bestimmten Netzwerkpfad und Messzeitpunkt.
Andere Schnittstellen, interne Pfade oder anwendungsbezogene Schwachstellen können weiterhin relevant sein.
Sicherheit wird deshalb nicht aus einem einzelnen Scanergebnis abgeleitet, sondern aus dem untersuchten Zusammenspiel der Kontrollen.
Ist die Untersuchung für diesen Themenbereich technisch nachvollziehbar?
- Sind Netz-, Cloud- und Vertrauensgrenzen für den relevanten Systemstand dokumentiert?
- Sind öffentliche und interne Dienste mit ihren tatsächlichen Endpunkten und Ports inventarisiert?
- Wurde die Erreichbarkeit aus klar benannten Beobachtungsperspektiven geprüft?
- Sind Firewall-, Security-Group-, Routing- und anwendungsbezogene Regeln getrennt nachvollzogen?
- Sind Authentisierung und Autorisierung von reiner Netzwerksegmentierung unterschieden?
- Wurden Soll-Diagramme mit beobachtbarer Konfiguration oder Messung abgeglichen?
- Sind nicht geprüfte interne oder zeitabhängige Pfade als Aussagegrenze benannt?
Konstruiertes Beispiel
Ein Backend ist laut Architekturdiagramm nur über einen API-Gateway erreichbar. Die technische Prüfung zeigt zusätzlich eine direkt adressierbare Cloud-IP, die aus einem Partnernetz erreichbar ist. Der Befund beschreibt diesen alternativen Pfad und prüft separat, ob dort dieselben Authentisierungsregeln greifen.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- NIST-Architektur NIST SP 800-207 Zero Trust Architecture zur ressourcen- und identitätsbezogenen Zugriffskontrolle. Quelle öffnen.
- NIST-Cloud-Modell NIST SP 800-207A für granulare Zugriffskontrolle in cloud-nativen Multi-Cloud-Umgebungen. Quelle öffnen.
- Kontrollrahmen NIST SP 800-53 Rev. 5 mit System and Communications Protection sowie Access Control. Quelle öffnen.
- Eigene Methodik Quellen und Methodik der Wissensplattform. Quelle öffnen.
Weiterführende Beiträge
- Sicherheitskonfiguration und Zugriffsrechte
- Schwachstellen technisch untersuchen
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich IT-Sicherheit
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
IT-Sicherheitsgutachten ansehen