Ein kompromittierter Server ist selten das Ende eines Angriffs. Wenn dieser Server jedes andere Gerät im Netzwerk erreichen kann, kann ein Eindringling ihn als Ausgangspunkt nutzen, um Zugangsdaten zu stehlen, Ransomware einzusetzen, Anwendungen zu verändern oder Backup-Systeme anzugreifen. Netzwerksegmentierung verringert den möglichen Schadensumfang, indem sie kontrolliert, welche Systeme miteinander kommunizieren dürfen und warum.
Segmentierung ist weder ein einzelnes Produkt noch eine einzelne Einstellung. Sie ist eine Design-Disziplin, die VLANs, Subnetze, Sicherheitszonen, Routing, Firewall-Richtlinien, Identitätskontrollen und Überwachung miteinander verbindet. Das Ziel ist einfach: Ein Webserver sollte keine beliebigen Verbindungen zu Laptops von Mitarbeitern initiieren können, eine Datenbank sollte nicht aus dem öffentlichen Internet erreichbar sein, und ein Produktionsserver sollte nicht automatisch administrativen Zugriff auf die Backup-Infrastruktur besitzen.
Für Agenturen und kleine Unternehmen muss ein sinnvolles Design nicht kompliziert sein. Es muss jedoch die tatsächliche Funktionsweise der Systeme abbilden, überall dort standardmäßig den Zugriff verweigern, wo dies praktikabel ist, und regelmäßig getestet werden. Segmentierung sollte außerdem eine isolierte und wiederherstellbare Backup-Strategie ergänzen. Sie kann nicht garantieren, dass ein Angriff eingedämmt wird, und sie kann keine Daten wiederherstellen, die ein Angreifer verschlüsselt oder gelöscht hat.
Wovor schützt Netzwerksegmentierung?
Netzwerksegmentierung teilt die Infrastruktur in getrennte Bereiche auf und platziert kontrollierte Grenzen zwischen ihnen. Diese Grenzen können mit physischen Netzwerken, VLANs, gerouteten Subnetzen, virtuellen Firewalls, Host-Firewalls oder einer Kombination dieser Maßnahmen umgesetzt werden.
Der wichtigste Sicherheitsvorteil besteht darin, laterale Bewegungen zu begrenzen. Laterale Bewegung bezeichnet den Prozess, mit dem sich ein Angreifer von einem zunächst kompromittierten System zu weiteren Systemen innerhalb der Umgebung bewegt. Ein öffentlich erreichbarer Webserver kann beispielsweise über ein nicht gepatchtes Framework kompromittiert werden. Anschließend sucht der Angreifer nach Datenbankzugangsdaten, Management-Schnittstellen, Dateifreigaben, Domänendiensten, Hypervisoren und Backup-Konsolen. Jeder erreichbare Dienst stellt eine weitere Gelegenheit dar.
Ein flaches Netzwerk erleichtert diesen Prozess. In einem flachen Design können Server, Arbeitsplatzrechner, Drucker, Hypervisoren und Verwaltungstools in einem großen IP-Bereich liegen. Die Netzwerkreichbarkeit wird häufig als Berechtigung behandelt. Sobald ein Angreifer eingedrungen ist, kann er die Umgebung scannen, sich mit Diensten verbinden, die nie öffentlich vorgesehen waren, und schwache interne Kontrollen ausnutzen.
Segmentierung ändert diese Standardannahme. Systeme werden entsprechend ihrer Rolle und Gefährdung in Zonen eingeordnet, und der Datenverkehr zwischen den Zonen wird ausdrücklich kontrolliert. Ein kompromittierter Webserver kann weiterhin gefährlich sein, sollte aber nur die Verbindungen besitzen, die er zum Bereitstellen der Anwendung benötigt. Er sollte weder das Managementnetzwerk scannen noch eine Verbindung zu jedem Server über Remote Desktop und SSH herstellen können.
Teams, die zu Netzwerksegmentierung und Serversicherheit gegen laterale Bewegungen recherchieren, finden viele mögliche Architekturen. Entscheidend ist nicht, ein Diagramm blind zu kopieren. Das Design muss den tatsächlichen Anwendungsabhängigkeiten, Verwaltungsprozessen und Wiederherstellungsanforderungen folgen.
VLANs, Subnetze und Sicherheitszonen sind verwandt, aber unterschiedlich
VLANs ermöglichen logische Trennung
Ein virtuelles LAN oder VLAN trennt Geräte auf Layer 2, selbst wenn sie dieselbe physische Switching-Hardware verwenden. Ein Unternehmen könnte beispielsweise Büroarbeitsplätze in einem VLAN, Produktionsserver in einem zweiten und Management-Schnittstellen in einem dritten VLAN platzieren. VLANs reduzieren den Broadcast-Bereich und schaffen klare Punkte, an denen Datenverkehr geroutet werden muss.
VLANs allein sind keine Sicherheitsgrenze. Wenn ein Router, ein Layer-3-Switch oder eine Firewall sämtlichen Datenverkehr zwischen den VLANs erlaubt, ist die Trennung überwiegend administrativer Natur. Der Sicherheitswert entsteht durch die Prüfung und Kontrolle des Datenverkehrs, wenn dieser die Grenze überschreitet.
Subnets definieren geroutete Netzwerke
Jedes VLAN besitzt üblicherweise ein eigenes IP-Subnetz. Ein Server-Subnetz kann beispielsweise einen privaten Adressbereich verwenden, während das Management-Subnetz einen anderen nutzt. Subnetze machen Routen und Firewall-Richtlinien verständlicher, aber getrennte IP-Bereiche verhindern die Kommunikation nicht automatisch. Routing und Zugriffskontrolllisten bestimmen weiterhin, was erlaubt ist.
Sicherheitszonen beschreiben Vertrauen und Gefährdung
Eine Sicherheitszone ist ein Richtlinienkonzept. Sie fasst Systeme mit einem ähnlichen Gefährdungsgrad oder Sicherheitszweck zusammen. Eine typische kleine Umgebung kann folgende Zonen umfassen:
- Internet- oder Edge-Zone: Firewalls, Reverse Proxies, Load Balancer und andere Systeme, die direkt externen Netzwerken ausgesetzt sind.
- Webzone: Öffentlich erreichbare Webserver, die Anfragen aus dem Internet oder von einem Edge-Proxy annehmen.
- Anwendungszone: Anwendungsdienste, die nur Anfragen von freigegebenen Web- oder Integrationssystemen akzeptieren sollten.
- Datenbankzone: Datenbankserver, die nur von bestimmten Anwendungsdiensten und über genehmigte Administrationswege erreichbar sein sollten.
- Managementzone: Jump Hosts, Überwachungskonsolen, Konfigurationssysteme, Hypervisor-Verwaltung und andere administrative Schnittstellen.
- Backupzone: Backup-Agenten, Repositories, Managementsysteme und Wiederherstellungsinfrastruktur, getrennt von Produktions-Workloads.
- Benutzerzone: Mitarbeitergeräte, Drucker und andere Bürogeräte, die typischerweise eine andere Zugriffsrichtlinie als Server benötigen.
Diese Zonen können physisch, virtuell oder bei einem Anbieter gehostet sein. Entscheidend ist, dass der Datenverkehr zwischen ihnen einen Richtliniendurchsetzungspunkt passiert und ausreichend protokolliert wird, um unerwartetes Verhalten zu untersuchen.
Das Design an Kommunikationsanforderungen ausrichten
Der beste Ausgangspunkt ist keine Liste von VLAN-Nummern, sondern ein Inventar der Dienste und ihrer Kommunikationsanforderungen. Erfassen Sie für jeden Server, was er bereitstellt, wer ihn nutzt, welche Ports erforderlich sind, ob die Kommunikation in eine oder beide Richtungen initiiert wird und was geschieht, wenn die Abhängigkeit nicht verfügbar ist.
Stellen Sie Fragen wie:
- Muss die Webschicht die Anwendungsschicht erreichen, oder kann ein interner Reverse Proxy diese Aufgabe übernehmen?
- Benötigt der Anwendungsserver direkten Datenbankzugriff und auf welchem Datenbankport?
- Welche Systeme benötigen DNS, Zeitsynchronisierung, Identitäts- oder Zertifikatsdienste?
- Fragt die Überwachung Server ab, oder senden Agenten Daten an einen Monitoring-Collector?
- Welche Administratoren benötigen SSH-, Remote-Desktop-, Konsolen- oder Hypervisor-Zugriff?
- Benötigt ein Server überhaupt ausgehenden Internetzugriff und falls ja, zu welchen Zielen?
- Welche Backup-Verbindungen werden vom Produktionsserver, vom Backup-Server oder von beiden initiiert?
Dokumentieren Sie die Antworten in einer Kommunikationsmatrix. Eine einfache Matrix kann Quellzone, Zielzone, Protokoll, Port, Zweck, Richtung, Verantwortlichen und Prüfdatum aufführen. So vermeiden Sie einen häufigen Fehler: ein gesamtes Subnetz freizugeben, obwohl eine Anwendung nur eine einzelne Verbindung benötigt.
Anwendungsabhängigkeiten sollten überprüft und nicht angenommen werden. In der Herstellerdokumentation steht möglicherweise, dass ein Dienst einen Port verwendet, während die tatsächliche Bereitstellung zusätzlich auf DNS, einem Identitätsanbieter, einem Lizenzdienst, einem SMTP-Relay oder einer Cloud-API beruht. Beginnen Sie mit einer vorsichtigen Richtlinie, beobachten Sie legitimen Datenverkehr und ergänzen Sie eng definierte Regeln mit einem eindeutig verantwortlichen Besitzer.
Ein praktisches Schichtenmodell für Agenturen und kleine Unternehmen
Eine kleine Agentur kann Kundenwebsites, interne Anwendungen, Datenbanken und Verwaltungstools auf einer überschaubaren Zahl physischer oder virtueller Server hosten. Möglicherweise gibt es kein eigenes Netzwerk-Sicherheitsteam. Ein sinnvolles Design kann die wichtigsten Risiken dennoch trennen, ohne ein unüberschaubares Labyrinth zu schaffen.
Webschicht
Die Webschicht enthält Systeme, die nicht vertrauenswürdige Anfragen verarbeiten. Diese Server sollten als stärker gefährdet behandelt werden, da sie Dienste dem Internet aussetzen. Erlauben Sie eingehenden Datenverkehr nur für die erforderlichen Webprotokolle, normalerweise über eine Firewall, einen Reverse Proxy oder eine Load-Balancing-Schicht. Der administrative Zugriff sollte über den Managementweg erfolgen, nicht über die öffentliche Schnittstelle.
Ein Webserver muss normalerweise Verbindungen zur Anwendungsschicht initiieren, genehmigte Updates abrufen oder ausgewählte externe Dienste kontaktieren. Er sollte keinen uneingeschränkten Zugriff auf das Datenbanknetzwerk, interne Dateifreigaben, Mitarbeitergeräte oder Hypervisor-Schnittstellen besitzen. Wenn der Server nur statische Inhalte bereitstellt, können seine erlaubten Ziele noch stärker eingeschränkt werden.
Anwendungsschicht
Die Anwendungsschicht führt Geschäftslogik, APIs, Hintergrundprozesse und Integrationsdienste aus. Sie sollte Datenverkehr nur von definierten Webservern, vertrauenswürdigen Integrationen oder, sofern erforderlich, internen Benutzern akzeptieren. Der ausgehende Zugriff sollte auf die Datenbanken, Warteschlangen, Identitätsdienste und externen APIs beschränkt sein, die die Anwendung tatsächlich verwendet.
Gehen Sie nicht davon aus, dass die Platzierung von Anwendungs- und Datenbankservern in separaten VLANs ausreicht. Die Firewall sollte nur das von der Anwendung benötigte Datenbankprotokoll und den entsprechenden Port von den spezifischen Anwendungsadressen erlauben. Der administrative Datenbankzugriff sollte einen separaten Managementweg und eine stärkere Authentifizierung verwenden.
Datenbankschicht
Datenbanken enthalten einen hohen Wert auf engem Raum und sollten der praktisch geringsten Netzwerkreichbarkeit unterliegen. Sie sollten keine Verbindungen aus dem Internet oder aus allgemeinen Benutzernetzwerken akzeptieren. In vielen Umgebungen sollte nur eine kleine Gruppe von Anwendungsservern eine Verbindung zum Datenbankdienst herstellen dürfen.
Datenbankserver benötigen möglicherweise DNS, Zeitsynchronisierung, Überwachung und Backup-Konnektivität. Diese Anforderungen sollten als separate Regeln umgesetzt und nicht in einer weit gefassten Erlaubnisregel gebündelt werden. Unterstützt die Datenbank-Engine Verschlüsselung bei der Übertragung und starke Authentifizierung, sollten Sie diese Kontrollen als zusätzliche Schutzschicht verwenden. Netzwerksegmentierung reduziert die Erreichbarkeit; sie macht eine erlaubte Verbindung nicht automatisch vertrauenswürdig.
Überwachungs- und Protokollierungsschicht
Überwachungssysteme benötigen Einblick, aber Einblick bedeutet keinen uneingeschränkten Zugriff. Wenn Monitoring-Agenten Daten an einen Collector senden, erlauben Sie die ausgehende Agentenverbindung zu diesem Collector. Fragt der Collector Systeme ab, erlauben Sie nur die erforderlichen Abfrageprotokolle aus dem Monitoring-Subnetz.
Protokolle sollten an einen Ort gesendet werden, den ein Angreifer nach der Kompromittierung eines Produktionsservers nicht leicht verändern kann. Beschränken Sie, wer die Monitoring-Plattform administrieren darf, schützen Sie ihre Zugangsdaten separat und alarmieren Sie bei Änderungen an Firewall-Regeln, privilegierten Konten und der Backup-Konfiguration. Überwachung sollte helfen, sowohl Angriffe als auch Segmentierungsfehler zu erkennen.
Managementschicht
Die Managementschicht ist einer der sensibelsten Bereiche der Umgebung. Sie kann Jump Hosts, Fernverwaltungstools, Hypervisor-Konsolen, Konfigurationsmanagement, Verzeichnisdienste, die Verwaltung von Netzwerkgeräten und Sicherheitsplattformen enthalten.
Management-Schnittstellen sollten nicht direkt dem Internet ausgesetzt werden. Administratoren sollten sich über einen kontrollierten Fernzugangsdienst und gegebenenfalls über einen gehärteten Jump Host verbinden. Der Jump Host sollte nur über eine begrenzte Menge erlaubter Ziele verfügen und nicht zum gewöhnlichen Surfen oder für E-Mails verwendet werden.
Firewall-Regeln standardmäßig auf Verweigern setzen
„Deny by Default“ bedeutet, dass Datenverkehr blockiert wird, sofern ihn keine spezifische Regel erlaubt. Das ist sicherer, als zunächst einen weit gefassten internen Zugriff zu erlauben und gefährliche Ausnahmen später entfernen zu wollen. Außerdem wird die beabsichtigte Architektur im Regelsatz sichtbar.
Eine nützliche Firewall-Regel sollte fünf Fragen beantworten:
- Welche Quelladressen, Identitäten oder Zonen sind beteiligt?
- Welches Zielsystem oder welcher Dienst wird benötigt?
- Welches Protokoll und welcher Port sind erlaubt?
- Ist die Verbindung eingehend, ausgehend oder bidirektional?
- Wer ist für die Regel verantwortlich, warum existiert sie und wann sollte sie überprüft werden?
Bevorzugen Sie spezifische Serveradressen oder eng gefasste Adressgruppen gegenüber gesamten Subnetzen. Verwenden Sie benannte Dienstobjekte statt weit gefasster Portbereiche. Vermeiden Sie Regeln wie „jede Quelle zu jedem Ziel“, sofern es nicht einen eindeutig dokumentierten, vorübergehenden Grund und ein Ablaufdatum gibt.
Die Reihenfolge der Regeln ist wichtig. Eine weit gefasste Erlaubnisregel oberhalb einer einschränkenden Regel kann das beabsichtigte Design unbemerkt aushebeln. Verwenden Sie ausdrückliche Verweigerungsregeln, wenn sie die Transparenz erhöhen, und protokollieren Sie abgelehnten Datenverkehr gezielt. Die Protokollierung jedes Pakets kann ein kleines Team überfordern, aber wiederholte abgelehnte Verbindungsversuche zwischen sensiblen Zonen können Scans, Malware oder eine fehlerhafte Anwendungsabhängigkeit aufdecken.
Firewall-Regeln sollten wie Infrastruktur verwaltet werden und nicht informell unter Zeitdruck bearbeitet werden. Führen Sie ein Änderungsprotokoll, nutzen Sie für sensible Richtlinien eine Prüfung durch eine zweite Person und entfernen Sie temporäre Zugriffe nach Abschluss der Arbeiten. Unterstützt die Plattform dies, integrieren Sie Regeländerungen in das Konfigurationsmanagement und bewahren Sie frühere Versionen für ein Rollback auf.
Ost-West-Datenverkehr kontrollieren, nicht nur den Internetverkehr
Nord-Süd-Datenverkehr fließt zwischen der internen Umgebung und dem Internet. Ost-West-Datenverkehr fließt zwischen internen Systemen. Die traditionelle Perimetersicherheit konzentriert sich oft auf Nord-Süd-Datenverkehr und nimmt an, dass das interne Netzwerk vertrauenswürdig ist. Diese Annahme scheitert, wenn ein Angreifer einen Server kompromittiert, Zugangsdaten eines Administrators stiehlt oder ein infiziertes Gerät mit dem Büronetzwerk verbindet.
Ost-West-Kontrollen sollten den Datenverkehr zwischen folgenden Bereichen abdecken:
- Webservern und Anwendungsservern
- Anwendungsservern und Datenbanken
- Produktionsservern und Management-Schnittstellen
- Servern und Benutzerarbeitsplätzen
- Virtuellen Maschinen auf demselben Host oder Cluster
- Produktionssystemen und Backup-Repositories
- Monitoring-Collectoren und überwachten Geräten
Host-basierte Firewalls fügen eine weitere Schutzschicht hinzu. Sie sind besonders nützlich, wenn Workloads einen virtuellen Switch gemeinsam nutzen oder Datenverkehr nicht durch eine zentrale physische Firewall läuft. Eine Host-Firewall kann lokale Dienste beschränken und Verbindungen blockieren, die niemals erforderlich sein sollten, selbst wenn eine Netzwerkrichtlinie versehentlich zu weit gefasst ist.
Mikrosegmentierung kann diesen Ansatz erweitern, indem Richtlinien auf einzelne Workloads oder Identitäten statt nur auf VLANs angewendet werden. Kleine Organisationen benötigen nicht immer eine spezialisierte Mikrosegmentierungsplattform. Sorgfältig verwaltete Host-Firewalls, Sicherheitsgruppen, Dienstidentitäten und lokale Richtlinien können eine wirksame Trennung bieten, wenn sie dokumentiert und gepflegt werden.
Administration und Produktionsdatenverkehr trennen
Administrativer Zugriff verdient einen eigenen Weg, weil Administratorenzugangsdaten viele Systeme gleichzeitig öffnen können. Werden Benutzer-, Anwendungs- und Managementdatenverkehr in einem Netzwerk kombiniert, ist es schwieriger, legitime Administration von Aktivitäten eines Angreifers zu unterscheiden.
Ein sichereres Modell sieht vor, dass sich Administratoren über ein Fernzugangs-Gateway oder VPN verbinden, sich mit individuellen Konten authentifizieren und, sofern möglich, eine Multifaktor-Authentifizierung verwenden. Von dort aus erreichen sie einen gehärteten Jump Host oder eine Managementzone. Der Jump Host verbindet sich anschließend mit genehmigten Serverschnittstellen. Direkter Zugriff von einem nicht verwalteten Laptop auf jeden Server sollte vermieden werden.
Administrative Kontrollen sollten Folgendes umfassen:
- Separate benannte Administratorkonten statt gemeinsam genutzter privilegierter Zugangsdaten
- Multifaktor-Authentifizierung für Fernzugriff und privilegierte Systeme
- Berechtigungen nach dem Prinzip der geringsten Rechte und entsprechend der Rolle
- Kurzlebigen oder Just-in-Time-Zugriff für sensible Aufgaben, sofern unterstützt
- Beschränkungen, welche Quellnetzwerke SSH, Remote Desktop und Management-APIs erreichen dürfen
- Zentrale Protokollierung von Authentifizierungen und privilegierten Aktivitäten
- Sichere Speicherung und regelmäßige Erneuerung von Dienstzugangsdaten
Übersehen Sie nicht die Out-of-Band-Administration. Hypervisor-Verwaltung, Remote-Konsolen-Controller, Speichersysteme und Netzwerkgeräte sollten sich in der Managementzone befinden, nicht im selben Segment wie gewöhnliche Workloads. Wird ein Produktionsserver kompromittiert, sollte der Angreifer nicht automatisch einen Weg zu der Plattform erhalten, die alle virtuellen Maschinen steuert.
Das Backup-Netzwerk unabhängig halten
Backups werden häufig angegriffen, nachdem ein Angreifer die Produktion erreicht hat. Wenn Backup-Konsole, Repository und Produktionsserver dieselben Zugangsdaten und uneingeschränkten Netzwerkzugriff teilen, kann Ransomware möglicherweise Wiederherstellungspunkte löschen, bevor die Live-Systeme verschlüsselt werden.
Trennen Sie Backup-Datenverkehr und -Verwaltung nach Möglichkeit vom gewöhnlichen Produktionsdatenverkehr. Ein Backup-Netzwerk kann dedizierte VLANs, Firewall-Regeln, eingeschränkte Routen, separate Dienstkonten und einen Repository-Zugriff umfassen, der aus Benutzer- oder Webzonen nicht verfügbar ist.
Segmentierung sollte zwei verschiedene Fragen beantworten. Erstens: Kann das Backup-System die benötigten Daten erfassen oder empfangen? Zweitens: Kann ein kompromittierter Produktionsserver die gespeicherten Wiederherstellungspunkte ändern, löschen oder verwalten? Die erste Verbindung kann notwendig sein; die zweite sollte streng eingeschränkt werden.
Netzwerkkontrollen sind nur ein Teil der Backup-Resilienz. Backups sollten verschlüsselt werden, bevor sie die vom Kunden kontrollierte Umgebung verlassen, wobei der Verschlüsselungsschlüssel beim Kunden und nicht beim Backup-Anbieter liegen sollte. Sie sollten getrennt von der Produktion gespeichert und für die Dauer des Aufbewahrungszeitraums gegen Löschung oder Änderung geschützt werden.
Wenn ein kompromittierter Server Produktionssysteme erreicht und versucht, Wiederherstellungsoptionen zu zerstören, bietet ein isolierter, verschlüsselter und unveränderlicher Dienst wie Safenix Offsite-Backup für Geschäftsserver eine zusätzliche Wiederherstellungsgrenze. Safenix schützt vom Kunden kontrollierte Server; es ist kein Backup-Konzept für Websites auf Shared Hosting.
VPS- und gehostete Webinfrastrukturen sorgfältig betrachten
Segmentierung ist komplizierter, wenn die Infrastruktur bei einem Anbieter gehostet wird, da der Kunde möglicherweise weder die physischen Switches noch das vorgelagerte Netzwerk kontrolliert. Das Design sollte zwischen Kontrollen unterscheiden, die der Kunde innerhalb der VPS- oder Cloud-Umgebung konfigurieren kann, und Kontrollen, die die Hosting-Plattform bereitstellen muss.
Verwenden Sie auf Kundenseite, sofern verfügbar, separate virtuelle Netzwerke, Sicherheitsgruppen, Host-Firewalls und private Schnittstellen. Beschränken Sie öffentliche Schnittstellen auf die erforderlichen Dienste. Platzieren Sie Datenbanken und Management-Endpunkte in privaten Netzwerken und setzen Sie sie nicht nur aus Bequemlichkeit öffentlichen IP-Adressen aus.
Fragen Sie den Anbieter, wie die Netzwerkisolierung funktioniert, ob privater Datenverkehr gefiltert wird, wie Firewall-Richtlinien angewendet werden und ob der Managementzugriff von Kunden-Workloads getrennt ist. Prüfen Sie außerdem, wie der Anbieter mit Snapshots, Images und Backups umgeht. Ein Snapshot, der über dieselbe kompromittierte Steuerungsebene erreichbar ist, stellt möglicherweise keine unabhängige Wiederherstellungskopie dar.
Für Organisationen, die VPS und gehostete Webinfrastrukturen mit getrennten Sicherheitszonen nutzen, gelten praktisch dieselben Fragen wie in einem Serverraum: Welches System kann eine Verbindung initiieren, welcher Dienst ist exponiert, wer darf ihn verwalten und wie würde der Zugriff während eines Vorfalls entzogen? Ein gehosteter Standort macht Segmentierung nicht überflüssig. Er verändert, welche Kontrollen verfügbar sind und wer sie betreibt.
Shared Hosting erfordert besondere Sorgfalt bei der Beschreibung von Verantwortlichkeiten. Ein Kunde kann möglicherweise Anwendungseinstellungen oder eine Firewall auf Kontoebene konfigurieren, erhält dadurch aber keine Kontrolle über das Servernetzwerk des Anbieters oder benachbarte Konten. Safenix schützt vom Kunden kontrollierte Geschäftsserver und sollte nicht als Backup-Dienst für eine Website auf Shared Hosting dargestellt werden.
Häufige Fehler bei der Segmentierung
VLANs erstellen, ohne Richtlinien durchzusetzen
Getrennte VLANs mit uneingeschränktem Inter-VLAN-Routing erzeugen den Anschein einer Segmentierung, ohne den beabsichtigten Schutz zu bieten. Prüfen Sie den tatsächlichen Weiterleitungspfad und die Firewall-Richtlinie. Stellen Sie sicher, dass Datenverkehr den Prüfpunkt nicht über eine alternative Schnittstelle, eine Bridge oder einen nicht verwalteten Switch umgehen kann.
Aus Bequemlichkeit das gesamte Subnetz freigeben
Wenn eine Anwendung eine Datenbank erreichen muss, ist es schneller, das gesamte Web-Subnetz freizugeben, als die genaue Quelle zu ermitteln. Dadurch kann jedoch jeder kompromittierte oder falsch konfigurierte Host in diesem Subnetz die Datenbank erreichen. Verwenden Sie stattdessen Adressgruppen und dienstspezifische Regeln.
Temporäre Ausnahmen bestehen lassen
Notfallzugriff wird häufig dauerhaft. Jede temporäre Regel sollte einen Verantwortlichen, einen Grund, ein Erstellungsdatum und ein Ablaufdatum besitzen. Überprüfen Sie abgelaufene Regeln im normalen Betrieb und nicht erst nach einem Vorfall.
Gemeinsam genutzte Zugangsdaten verwenden
Gemeinsame Administrator- und Dienstzugangsdaten erschweren die Zuordnung von Aktivitäten und machen es für einen Angreifer einfach, sich zwischen Systemen zu bewegen. Verwenden Sie individuelle Konten für Personen, separate Dienstidentitäten für Anwendungen und eindeutige Zugangsdaten für Backup- und Managementsysteme.
Management-Schnittstellen in Produktionsnetzwerken platzieren
Servermanagement-Ports, Hypervisor-Konsolen und Speicherverwaltung sollten von gewöhnlichen Benutzergeräten oder öffentlich erreichbaren Workloads nicht erreichbar sein. Ein Managementnetzwerk ist nur dann nützlich, wenn auch der Zugriff darauf eingeschränkt wird.
Nicht-Server-Geräte vergessen
Drucker, Kameras, Gebäudesysteme und kostengünstige Netzwerkgeräte werden häufig schlechter gewartet als Server. Sie sollten keinen uneingeschränkten Zugriff auf sensible Infrastruktur besitzen. Platzieren Sie sie in einer geeigneten Gerätezone und erlauben Sie nur die erforderlichen Dienste.
Ausnahmen nicht dokumentieren
Nicht dokumentierte Regeln werden zu dauerhaften Annahmen. Wenn ein Techniker das Unternehmen verlässt oder eine Anwendung geändert wird, weiß niemand, warum eine Verbindung existiert oder ob sie entfernt werden kann. Dokumentation ist Teil der Kontrolle und keine bloße administrative Zierde.
So testen Sie, ob die Segmentierung funktioniert
Ein Design ist durch ein Netzwerkdiagramm nicht bewiesen. Testen Sie die Durchsetzungspunkte von denselben Stellen aus, die ein Angreifer nutzen könnte. Führen Sie einen genehmigten Testplan, damit Scans und Verbindungsversuche die Produktion nicht beeinträchtigen.
Erlaubte Pfade testen
Prüfen Sie von jeder Quellzone aus, ob erforderliche Dienste erreichbar sind. Testen Sie das genaue Protokoll und den genauen Port und nicht nur, ob das Ziel auf Ping reagiert. Bestätigen Sie, dass Anwendungstransaktionen, Überwachung, Administration und Backup-Aufträge über die vorgesehenen Wege funktionieren.
Verbotene Pfade testen
Versuchen Sie, von Webservern aus Management-Schnittstellen zu erreichen, von Benutzernetzwerken aus Datenbanken, von Anwendungsservern aus nicht zugehörige Produktionssysteme und von gewöhnlichen Servern aus Backup-Administrationsports zu verbinden. Diese Tests sollten fehlschlagen. Eine erfolgreiche Verbindung muss untersucht werden, auch wenn der Dienst keine Daten preisgibt.
Aus der Perspektive eines kompromittierten Hosts testen
Verwenden Sie ein kontrolliertes Testkonto oder eine genehmigte Sicherheitsprüfung, um einen Angreifer zu simulieren, der Zugriff auf einen Server erlangt hat. Prüfen Sie, ob diese Position Netzwerkerkennung, Credential-Dienste, Fernverwaltung, Dateifreigaben oder den Zugriff auf andere Zonen ermöglicht. Suchen Sie nach Wegen, die übersehen wurden, weil die ursprüngliche Dokumentation den vorgesehenen statt des tatsächlichen Datenverkehrs beschrieb.
Protokolle und Warnmeldungen prüfen
Stellen Sie sicher, dass abgelehnte Verbindungen mit einem nützlichen Detailgrad sichtbar sind. Warnmeldungen sollten ungewöhnliche Scans, wiederholte Zugriffsversuche auf sensible Zonen und Änderungen an Sicherheitsrichtlinien erkennen. Sorgen Sie dafür, dass Protokolle an einem Ort aufbewahrt werden, den ein kompromittierter Server nicht löschen kann.
Ausfälle und Wiederherstellung testen
Firewalls, Switches und VPN-Gateways können ausfallen oder falsch konfiguriert werden. Prüfen Sie, wie sich die Umgebung bei einem Geräteausfall, einer Richtlinienbereitstellung oder dem Verlust des primären Managementwegs verhält. Stellen Sie sicher, dass der Notfallzugriff kontrolliert und dokumentiert ist, statt auf einem undokumentierten Umgehungsweg zu beruhen.
Testen Sie nach größeren Änderungen erneut: Neue Anwendungen, Servermigrationen, VLAN-Neuplanungen, Anbieterwechsel und Firewall-Upgrades können die Erreichbarkeit verändern. Automatisierte Richtlinienvalidierung und regelmäßige Schwachstellen-Scans können helfen, sollten aber die menschliche Prüfung geschäftlicher Abhängigkeiten unterstützen und nicht ersetzen.
Segmentierung und Reaktion auf Sicherheitsvorfälle
Während eines Vorfalls sollte die Segmentierung dem Team helfen, einen Server schnell zu isolieren, ohne das gesamte Unternehmen offline zu nehmen. Halten Sie vordefinierte Eindämmungsmaßnahmen für typische Situationen bereit. Dazu können das Deaktivieren eines Switch-Ports, das Entfernen eines Servers aus einem Produktions-VLAN, das Sperren eines Dienstkontos, die Einschränkung des ausgehenden Zugriffs einer Zone oder die Verlagerung der Administration auf einen Notfallweg gehören.
Führen Sie ein aktuelles Inventar von Assets und Abhängigkeiten. Wenn die Einsatzkräfte nicht wissen, welche Dienste von einem Server abhängen, isolieren sie ihn möglicherweise zu langsam oder verursachen unnötige Störungen. Erfassen Sie für wichtige Systeme den Geschäftsverantwortlichen, den technischen Verantwortlichen, die Zone, kritische Abhängigkeiten, die Backup-Richtlinie und die Wiederherstellungspriorität.
Incident-Playbooks sollten festlegen, wer Änderungen an Notfall-Firewallregeln genehmigen darf, wie Änderungen dokumentiert werden und wie die normale Richtlinie anschließend wiederhergestellt wird. Testen Sie die Playbooks. Eine Kontrolle, die nur in einem Dokument existiert, unter Druck aber nicht eingesetzt werden kann, bietet nur begrenzten Schutz.
Warum Segmentierung isolierte Backups nicht ersetzen kann
Segmentierung begrenzt die Erreichbarkeit, macht ein kompromittiertes System aber nicht sicher. Ein Angreifer kann eine erlaubte Anwendungsverbindung ausnutzen, den Arbeitsplatz eines Administrators kompromittieren, Zugangsdaten stehlen, eine Firewall-Ausnahme missbrauchen oder das Backup-System über legitime Managementwege angreifen. Malware kann Daten außerdem beschädigen, bevor der Backup-Auftrag ausgeführt wird.
Wiederherstellbarkeit erfordert mehr, als irgendwo eine Kopie zu besitzen. Die Kopie muss nach einer Produktionskompromittierung verfügbar, vor unbefugter Löschung geschützt, angemessen verschlüsselt, für den erforderlichen Zeitraum aufbewahrt und innerhalb der Wiederherstellungsziele des Unternehmens wiederherstellbar sein.
Safenix bietet Offsite-Backup für vom Kunden kontrollierte Geschäftsserver. Die Daten werden mit einem Schlüssel verschlüsselt, den Safenix niemals besitzt, in Deutschland gespeichert und für die Dauer des Aufbewahrungszeitraums unveränderlich gehalten. Dieses Modell ergänzt die Segmentierung: Netzwerkkontrollen verringern die Wahrscheinlichkeit, dass sich ein Vorfall ausbreitet, während eine unabhängige Wiederherstellungskopie dem Unternehmen hilft, in einen bekannten, intakten Zustand zurückzukehren, wenn Systeme oder lokale Backups beschädigt wurden.
Planen Sie die Backup-Verbindung als Teil der Architektur. Beschränken Sie, welche Hosts Backup-Daten senden dürfen, halten Sie die Backup-Administration von gewöhnlichen Produktionskonten getrennt und testen Sie Wiederherstellungen, statt nur zu prüfen, ob Aufträge Erfolg melden. Ein erfolgreicher Backup-Auftrag belegt, dass Daten kopiert wurden; eine erfolgreiche Wiederherstellung zeigt, dass diese Daten tatsächlich die Wiederherstellung unterstützen können.
Ein umsetzbarer Implementierungsplan
Kleine Teams können die Segmentierung schrittweise verbessern. Beginnen Sie mit den Systemen, die das größte Risiko und den größten Wert darstellen, statt sofort eine perfekte Neugestaltung anzustreben.
- Umgebung erfassen. Identifizieren Sie Server, virtuelle Maschinen, Benutzer, Netzwerkgeräte, Management-Schnittstellen, Datenbanken, Backup-Systeme und externe Abhängigkeiten.
- Gefährdung klassifizieren. Kennzeichnen Sie internetseitige, interne, sensible, administrative und für die Wiederherstellung wichtige Systeme. Ermitteln Sie, wo eine einzelne Kompromittierung die größten Auswirkungen hätte.
- Zonen definieren. Beginnen Sie mit praktischen Gruppen wie Edge, Web, Anwendung, Datenbank, Management, Benutzer und Backup. Teilen Sie Zonen nur dann weiter auf, wenn der Richtlinienunterschied die Betriebskosten rechtfertigt.
- Kommunikationsmatrix erstellen. Erfassen Sie erforderliche Quelle, Ziel, Protokoll, Port, Richtung, Verantwortlichen und Zweck.
- Die wichtigsten Grenzen zuerst durchsetzen. Trennen Sie öffentlich erreichbare Server von Datenbanken, Benutzer von Managementsystemen sowie Produktion von der Backup-Administration.
- Standardmäßige Verweigerungsregeln anwenden. Fügen Sie spezifische Ausnahmen für überprüfte Abhängigkeiten hinzu und protokollieren Sie wichtige abgelehnte Versuche.
- Identitäten härten. Entfernen Sie gemeinsam genutzte Zugangsdaten, aktivieren Sie Multifaktor-Authentifizierung für die Fernverwaltung und beschränken Sie privilegierten Zugriff auf den Managementweg.
- Testen und dokumentieren. Überprüfen Sie erlaubte und blockierte Pfade, protokollieren Sie die Ergebnisse und aktualisieren Sie das Asset- und Regelverzeichnis.
- Kontinuierlich prüfen. Überarbeiten Sie Richtlinien nach Anwendungsänderungen, Personalwechseln, Anbietermigrationen und Sicherheitsvorfällen.
Das Ziel besteht nicht darin, eine Umgebung zu schaffen, in der nichts kommunizieren kann. Ziel ist, sicherzustellen, dass jede wichtige Verbindung beabsichtigt, begrenzt und begründbar ist. Wenn ein Server kompromittiert wird, entscheiden diese Festlegungen darüber, ob der Vorfall eingedämmt bleibt oder zu einem infrastruktweiten Ausfall wird.