Zonenarchitekturen: Notwendige Ordnungspolitik in Rechenzentrums- und Campus-Netzen

Kommentieren Drucken

Zonenarchitekturen dienen der sicherheitsorientierten Segmentierung von Netzen in Rechenzentrum (RZ) und Campus. Dabei kommen Techniken der logischen Netztrennung, der Kontrolle der Verkehrsflüsse an Netzübergängen sowie ggf. auch der Netzzugangskontrolle (Network Access Control, NAC) an Netzzugangspunkten zum Einsatz.

Solche Zonenarchitekturen verkomplizieren automatisch die Struktur der Netze und erhöhen den Betriebsaufwand erheblich. Ist ein solches Strukturierungsinstrument angesichts Virtualisierung und Cloud Computing überhaupt noch zeitgemäß? Interessanterweise ist die Antwort: Gerade dann! Sichere Virtualisierung erfordert beispielsweise eine sichere Trennung von produktivem und administrativem Netzverkehr, und Cloud Computing ist ohne mandantenfähige virtuelle Infrastrukturen nicht denkbar.

In diesem Artikel werden zunächst die grundlegenden Sicherheitsanforderungen diskutiert, die in der Praxis wesentlichen Architekturvarianten vorgestellt und typische Aspekte wie den Umgang mit Kurzschlüssen zwischen Sicherheitszonen betrachtet. Die Administration und Überwachung von Sicherheitszonen stellt dabei besondere Herausforderungen dar. Einführung und nachhaltige Umsetzung von einer Zonenarchitektur erfordern außerdem zwingend eine Anpassung und Erweiterung der IT-Prozesse.

1. Zonenarchitekturen als natürlicher Bestandteil der Enterprise Architecture

Manchmal muss es vielleicht erst zu Sicherheitsvorfällen kommen!

Erinnern wir uns kurz an typische, immer wieder auftretende Sicherheitsvorfälle:

  • Kundendaten im internen Netz eines Providers waren bis zur Beseitigung einer Sicherheitslücke in einer Web-Applikation ungeschützt vom Internet aus abgreifbar.
  • Durch den Anschluss eines Fremd-PCs eines Besuchers schaffte es ein Virus doch in das interne Netz und befiel PCs, die nicht mit einem (aktuellen) Virenschutz versehen werden konnten, da die PCs integriertes Element eines Geräts (z.B. in der Gebäudetechnik) waren, auf das die IT keinen direkten administrativen Zugriff hatte. Als Konsequenz fiel beispielsweise die Zutrittskontrolle zum und im Gebäude aus und Türen blieben verschlossen.
  • Ein Angreifer konnte durch einen Trojaner auf einem Mitarbeiter-PC (oder einfach als Innentäter) einen Zugriff auf kritische Daten einer Institution erlangen und diese Daten über den Internet-Zugang der Institution nach draußen schmuggeln.

Diese Liste lässt sich wahrscheinlich beliebig fortsetzen. Solchen Vorfällen ist jedoch oft gemeinsam, dass von einem System oder einem Netz eingeschränkter Vertrauenswürdigkeit auf ein schützenswertes System bzw. Netz zugriffen wird. In vielen Fällen ist dann der Grund des Sicherheitsvorfalls in der unzureichenden Trennung von Systemen eingeschränkter Vertrauenswürdigkeit von den anderen IT-Systemen zu finden. Nicht selten ist dann eine Feststellung z.B. bei einem Sicherheits-Audit, dass das Netz aus dem Blickwinkel der Informationssicherheit nicht geeignet strukturiert ist.

Übertragung von Konzepten der Perimeter-Sicherheit auf das Intranet
Wir haben uns natürlich daran gewöhnt, dass wir unsere IT-Infrastruktur gegenüber externen, nicht oder eingeschränkt vertrauenswürdigen Netzen abschotten müssen. Wir haben dabei akzeptiert, dass eine Perimeter-Sicherheit komplexe Sicherheitskonstrukte erfordert, die aus ggf. mehrstufigen Firewall-Systemen und Demilitarized Zones (DMZs) an und zwischen den Firewall-Stufen zur Aufnahme von Gateways, Proxies, etc. besteht.

Die Vielfalt der unterschiedlichen Nutzergruppen und der Dienste und Anwendungen im Intranet und der damit verbundenen höchst heterogenen Sicherheitsanforderungen im Intranet erfordert nun, dass wir verstärkt Konzepte der Perimeter-Sicherheit auch zur Strukturierung des Intranet heranziehen müssen.

Notwendigkeit virtueller Tresore
Die Absicherung kritischer Daten vor unberechtigtem Zugriff (und damit verbunden vor Abfluss und Verlust) ist stets eines der wesentlichen Ziele der Informationssicherheit.

Für virtuelle Wertsachen, d.h. Daten mit hohem Schutzbedarf insbesondere hinsichtlich Vertraulichkeit und Integrität gilt das gleiche wie für physische Wertsachen: Sie kommen in einen Tresor, d.h. in einen Sicherheitsbereich. Ein solcher virtueller Tresor wird primär auf einer Kombination von drei Säulen der Informationssicherheit aufgebaut (siehe Bild 1):

  • Netzbasierte Sicherheit
  • Plattformbasierte Sicherheit
  • Anwendungsbasierte Sicherheit

Dieser Artikel konzentriert sich auf die erste Säule der netzbasierten Sicherheit. Kernelemente sind dabei:

  • Segmentierung eines Netzes in unterschiedliche Sicherheitszonen
  • Kontrolle der Verkehrsflüsse zwischen Sicherheitszonen.
  • Authentisierung und Autorisierung für einen entsprechenden Zugang zu einer Sicherheitszone
  • Sichere Administration

Verankerung von Zonenarchitekturen in Standards zur Informationssicherheit
Die Forderung einer Zonierung ist auch in diversen Maßnahmenkatalogen zur Informationssicherheit entsprechend verankert. Schlägt man z.B. ISO 27001 (siehe [1]) im normativen Anhang A.11.4 „Zugangskontrolle für Netze“ auf, wird man über die Maßnahme A.11.4.5 „Trennung in Netzwerken“ stolpern: „Gruppen von Informationsdiensten, Benutzern und Informationssystemen müssen in Netzen getrennt gehalten werden.“

Diese kurze Formulierung hat es in sich, denn es wird klar und deutlich gemacht, dass auf Ebene des Netzes etwas geschehen muss. Diese Anforderung wird im Standard ISO 27002 (der als Best Practice für die Umsetzung von ISO 27001 zu verstehen ist) dann auch entsprechend konkretisiert. Die Umsetzung kann entweder mit den Mitteln einer Netztrennung und dem Einsatz einer Firewall am Netzübergang (jedoch grundsätzlich auch mit Access Control Lists, ACLs) oder durch kryptographische Techniken (z.B. VPN) erfolgen.

Maßnahme A.11.6.2 „Isolation sensibler Systeme“ von ISO 27001 fordert sogar verschärfend „Sensible Systeme müssen sich in einer dedizierten (isolierten) Umgebung befinden.“

Insgesamt kann also festgestellt werden, dass Zonenarchitekturen keinesfalls eine exotische Anforderung darstellen, sondern ein Standardelement moderner Unternehmensarchitekturen der IT sind.

2. Notwendige Bausteine einer Zonenarchitektur
Eine Zonenarchitektur muss zwingend einen modularen Bausteincharakter haben, denn es muss möglich sein, bei Bedarf flexibel im RZ neue Sicherheitszonen hinzufügen oder Server zu bestehenden Sicherheitszonen zuzuordnen. Aus dem Blickwinkel IT-Service muss es sogar möglich sein, für eine neue Sicherheitszone einen Bestellvorgang einzuleiten, der dann eine entsprechende Prozesskette in Bewegung setzt.

Terminologie: Ohne gemeinsame Sprache geht es nicht
Wie jede Architektur ist eine klare und konsequente Begriffsbildung für eine Zonenarchitektur entscheidend. Wie definiert sich der Begriff Sicherheitszone? Gibt es eine hierarchische Struktur oder eine logische Gruppierung von Sicherheitszonen an einem Standort einer Institution? Welche generellen Festlegungen zur Kommunikation zwischen Sicherheitszonen oder auf höheren Ebenen gibt es?

Folgende Festlegungen zu den grundlegenden Bausteinen einer Zonenarchitektur haben sich in der Praxis bewährt (was natürlich eine entsprechende andere, institutionsspezifische Anpassung keinesfalls ausschließt):

  • Eine netzbasierte Sicherheitszone (im Folgenden kurz Sicherheitszone) ist ein IP-Netzwerk, das aus Sicherheitsgründen von anderen Netzen getrennt wird.
  • Die Kommunikation in eine Sicherheitszone hinein oder aus einer Sicherheitszone heraus, wird durch Sicherheitsmaßnahmen kontrolliert. Hierzu werden die Sicherheitszonen durch Sicherheitselemente vernetzt.
  • Sicherheitselemente werden je nach Anforderung ausgewählt. Beispiele sind Firewall oder Intrusion Prevention System (IPS).
  • Innerhalb einer Sicherheitszone wird auf Ebene des Netzes die Kommunikation nicht eingeschränkt.
  • Ein Sicherheitselement kann an mehrere Sicherheitszonen angebunden werden und eine Sicherheitszone kann ebenso mit mehreren Sicherheitselementen verbunden werden.

Auf diese Weise stellt sich das Intranet letztendlich als Netzwerk von Sicherheitszonen dar.

Festlegungen zur logischen und physischen Trennung
Wenn Sicherheitszonen durch IP-Netze gebildet werden, muss geregelt werden, unter welchen Rahmenbedingungen eine physische Trennung notwendig ist und wann eine logische Trennung auf Ebene von Netz, Servern und Clients erlaubt ist.

In Rechenzentren ist es beispielsweise heute inzwischen sogar üblich – sofern im Einzelfall keine spezifischen Sicherheitsanforderungen dem widersprechen – lediglich DMZ-Bereiche physisch zu trennen und ansonsten eine logische Trennung auf Ebene der Server und Netze zu gestatten. Dies erfordert natürlich eine entsprechende Absicherung von Netz und Virtualisierungsplattform. Ähnlich geht man auch in Campus-Bereichen vor.

Für eine logische Trennung in Netzen kommen beispielsweise auf Layer 2 Virtual LAN (VLAN) in Frage und oberhalb von Layer 2 sind Multiprotocol Label Switching (MPLS) sowie Virtual Routing and Forwarding (VRF) zu nennen. Auf Ebene der Endgeräte sind Server-Virtualisierung und Virtual Desktop Infrastructure (VDI) relevante Techniken.

Netztechnischer Aufbau einer Sicherheitszone
Im einfachsten Fall besteht eine Sicherheitszone aus einem einzelnen VLAN. Eine Firewall, die als Sicherheitselement an die Sicherheitszone angeschlossen ist, würde dann als Default Gateway für die Endgeräte in der Sicherheitszone dienen. Wenn eine Sicherheitszone aus mehreren VLANs, d.h. IP-Subnetzen, besteht, kann mit VRF gearbeitet werden (siehe Abbildung 2).

Bei standortübergreifenden Sicherheitszonen können die Sicherheitszonen im WAN mit MPLS-VPNs oder bei Carrier Ethernet letztendlich wieder per VLANs getrennt werden.

Die Anschaltung von Sicherheitselementen zur Kontrolle der Kommunikation zwischen den Sicherheitszonen erfolgt dann redundant an zentraler Stelle z.B. an Core Switches im Data Center.

Bei Firewalls ist dabei festzulegen, ob mit statischem Routing oder einem dynamischen Routing-Protokoll wie OSPF gearbeitet wird. In letzterem Fall würde OSPF dann auch das Redundanzverfahren bilden. Während OSPF bei Firewalls am Perimeter eher unüblich ist, kann OSPF für eine interne Firewall in jedem Fall in Betracht gezogen werden, sofern im LAN mit OSPF gearbeitet wird, um eine Einheitlichkeit, eine einfachere Konfiguration und eine Active-Active-Konfiguration der Firewalls zu erreichen. Andernfalls kann – wie im Perimeter-Bereich üblich – mit den Mitteln einer First-Hop-Redundanz per VRRP (oder einem vergleichbaren Verfahren) eine Active-Passive-Firewall-Re-dundanz geschaffen werden.

Aufbau bzw. Unterstützung von netzbasierten Sicherheitszonen durch kryptographische Techniken
Bei netzbasierten Sicherheitszonen kommen kryptographische Techniken wie IPsec primär zur Kopplung von Netzen über nicht oder eingeschränkt vertrauenswürde Bereiche in Frage (Site-to-Site VPN).

Es gibt allerdings eine Technik, die für die Absicherung der Kommunikation auf Layer 2 entwickelt worden ist, und die sich sehr gut dafür eignet, mandantenfähige Netze mit kryptographischen Techniken (und damit Sicherheitszonen im oben beschriebenen Sinn) zu realisieren: IEEE 802.11AE MAC Security (kurz: MACsec).

MACsec ergänzt das MAC-Layer der Netzelemente eines LAN um eine Hop-by-Hop-Absicherung, die Daten-Vertraulichkeit, -Integrität, -Authentisierung für die verbindungslose Kommunikation in einem LAN schafft (siehe [2]). MACsec erweitert hierzu das Frame-Format auf Layer 2 um ein Feld für Kontrollinformationen und um eine kryptographische Prüfsumme zur Integritätsprüfung und Authentisierung der Daten. Eine Verschlüsselung ist dabei optional. Die Prüfsumme geht sowohl über die Nutzdaten als auch über die MAC-Adressen und die MACsec-Kontrolldaten. Hierdurch werden insbesondere MAC-Spoofing-Attacken in LAN und Carrier Ethernet wirkungslos.

Im Feld für die Kontrollinformationen kann auch die Zugehörigkeit eines Pakets zu einer Gruppe bzw. einer Sicherheitszone geschützt gegen Manipulationen und Spoofing kodiert werden. Auf diese Weise können auf einer gemeinsamen Layer-2-Infrastruktur unterschiedliche Sicherheitszonen sicher voneinander getrennt werden.

Bisher hat allerdings nur der Hersteller Cisco diese Technik implementiert (Cisco TrustSec), unterstützt diese Technik jedoch nicht in allen Switches. Es ist jedoch grundsätzlich trotzdem möglich sowohl im RZ als auch in der Fläche auf dem Campus eine durchgängige Sicherheit und Mandantenfähigkeit mit TrustSec zu schaffen (siehe auch Bild 3). In der Praxis wird diese Möglichkeit derzeit noch recht selten verwendet.

Regelung für den Umgang mit Bereichen mit hohem Schutzbedarf
Wenn auf Virtualisierungs-Hosts VMs mit hohem Schutzbedarf hinsichtlich Vertraulichkeit, Integrität oder Verfügbarkeit betrieben werden, müssen neben Standardmaßnahmen zusätzliche Sicherheitsmaßnahmen ergriffen werden, um dem hohen Schutzbedarf gerecht zu werden. Dies ist insbesondere der Fall, wenn die VMs auf einem Virtualisierungs-Host ein signifikant unterschiedliches Sicherheitsniveau haben.

In der Praxis hat sich hier folgende Vorgehensweise bewährt:

  1. Absicherung der Virtualisierungslösung: Basis ist neben der allgemeinen Schutzmaßnahmen für Server die Umsetzung der anwendbaren Maßnahmen des Grundschutzbausteins B 3.304 „Virtualisierung“ der BSI IT-Grundschutz-Kataloge (siehe [4]). Außerdem sind die entsprechenden herstellerspezifischen Standardmaßnahmen umzusetzen. Dies entspricht beispielsweise bei VMware dem Profile 3 des vSphere 5.1 Security Hardening Guide (siehe [5]).

    Um simultan Ressourcen für unterschiedliche Sicherheitszonen zur Verfügung zu stellen, muss die Virtualisierungslösung besonders gut gehärtet werden. Beispielsweise sollte für VMware bei einem hohen Schutzbedarf zusätzlich die Umsetzung des Maßnahmenkatalogs gemäß Profile 2 sowie im Hinblick auf Betriebstauglichkeit ausgewählter Maßnahmen des Profile 1 des vSphere 5.1 Security Hardening Guide (siehe [5]) erfolgen.

  2. VM-Normierung: Wesentliches Element einer praktikablen sicheren Server-Virtualisierung ist die Normierung von virtuellen Servern. Dies beinhaltet zunächst Konfigurationsvorgaben an das Betriebssystem auf den virtuellen Servern sowie die Festlegung der Anwendungsbereiche und der Dienste.
  3. VM-Maßnahmenbündel: Für jeden auf die beschriebene Weise normierten virtuellen Server wird ein Standardmaßnahmenbündel für den normalen Schutzbedarf (Mindesthärtung) sowie bei Bedarf ein hierauf aufbauendes erweitertes Maßnahmenbündel für den erhöhten Schutzbedarf festgelegt. Die wesentlichen Vorgaben werden dann als Konfigurationsrichtlinie für jedes Gastbetriebssystem festgelegt.

Eine ähnliche Vorgehensweise gilt auch für die Absicherung der Kommunikation im Netz. Hier ist insbesondere die Absicherung standortübergreifender Sicherheitszonen wichtig. Bei einem hohen Schutzbedarf hinsichtlich Vertraulichkeit oder Integrität muss die Kommunikation über WAN- oder auch Standleitungsstrecken außerhalb des geschützten LAN möglichst verschlüsselt werden. Neben IPsec kommen hier MACsec und proprietäre Verschlüsselungslösungen („Kryptoboxen“) in Frage.

Kontrolle der Kommunikation zwischen Sicherheitszonen
Je nach Sicherheitszone sind unterschiedliche Anforderungen der Kontrolle der Kommunikation zu berücksichtigen.

Einerseits können besonders schützenswerte Endgeräte in einer Sicherheitszone vor unkontrollierten Zugriffen aus der sonstigen IT-Infrastruktur abgeschottet werden („Trusted Zone“). Dann dient ein Sicherheitselement an der Grenze zur Sicherheitszone primär dem Schutz der Sicherheitszone. Andererseits kann eine Sicherheitszone auch zum Schutz der weiteren Infrastruktur vor Endgeräten in der Sicherheitszone dienen („Untrusted Zone“).

Es gibt durchaus Situationen, in denen beide Aspekte für eine Sicherheitszone Anwendung finden. Ein Beispiel kann eine Sicherheitszone „Produktion“ sein, welche die IT für die industrielle Fertigung an einem Werksstandort eines Unternehmens aufnimmt. Eine solche Zone muss vor unberechtigten Zugriffen von außen besonders geschützt werden, da ein Ausfall der Produktion sofort einen erheblichen finanziellen Schaden verursacht. Umgekehrt findet man in Produktionsbereichen meist eine ausgesprochen heterogene Endgerätelandschaft, d.h. unterschiedlichste Betriebssysteme und insbesondere Altlasten ohne aktuelle Patches und Virenschutz. Außerdem werden meist diverse Systeme von Fremdfirmen lokal und remote betrieben. Daher hat die restliche IT-Infrastruktur auch ein vitales Interesse an einem Schutz vor der Produktion.

Als Sicherheitselement wird man in vielen Fällen ein zentrales, entsprechend leistungsfähiges und hochverfügbares Firewall-Systemen verwenden (im Folgenden auch als Data Center Firewall bezeichnet), das oft um Intrusion-Prevention-Funktionen ergänzt wird.

Die dabei zu verwaltenden Regelwerke können eine erhebliche Komplexität annehmen, da im Gegensatz zum Einsatz am Perimeter hier die Firewall internen LAN- und WAN-Verkehr filtern muss, d.h. mit dem gesamten im Intranet verwendeten IP-Protokollapparat zurechtkommen muss. Dies beinhaltet möglicherweise neben der Filterung von Protokollen, die dynamisch Ports aushandeln (z.B. RTP), auch die Erkennung von Sitzungen, die auf Basis von UDP aufgebaut werden (z.B. Authentisierungen via RADIUS).

Um eine bessere und einfachere Kontrolle über die Kommunikation zu erlangen, kann der Einsatz einer Next Generation Firewall (NGFW) in Betracht gezogen werden. Eine NGFW ermöglicht dabei zusätzlich identitätsbasierte Regeln auf Ebene der Anwendungen (siehe [6]). Zwar haben praktisch alle Hersteller von Enterprise Firewalls NGFW-Funktionen im Portfolio, die genannten Funktionen müssen jedoch ausgiebig getestet werden. Beispielsweise erfordert die Zuordnung von IP-Paketen zu Identitäten ggf. eine trickreiche Anbindung an Verzeichnisdienste, wie Active Directory.

Da bei der Filterung der Kommunikation zwischen Sicherheitszonen oft nicht nur Client-Server-Verkehr, sondern auch Server-Server-Verkehr gefiltert werden muss, ist nicht nur die Gesamtdurchsatzleistung einer Firewall bzw. eines IPS entscheidend. Von besonderer Wichtigkeit ist auch die Leistung pro Flow bzw. pro Session. Dies muss bei Hersteller-Auswahl und Dimensionierung zwingend berücksichtigt werden, will man keine Katastrophe bei Produktivsetzung des Firewall-Systems riskieren.

Bei der Filterung der Kommunikation an den Netzübergängen ist die Verwendung verschlüsselter Protokolle zu beachten. Wenn es gewünscht ist, dass die Filterkomponenten (z.B. ein IPS) den verschlüsselten Verkehr analysieren, muss das Firewall-System um Verschlüsselungsendpunkte ergänzt werden, d.h. um entsprechende Proxies.

Insgesamt entsteht hier ein im Regelfall durchaus komplexes System.

Netzzugangskontrolle
An Sicherheitszonen im RZ werden meist nur Server angeschlossen. Diese Server befinden sich im RZ und daher in einem besonders geschützten und mit höchster Sorgfalt betriebenen Bereich. Es ist daher vielleicht nicht besonders wahrscheinlich, dass ein Server versehentlich oder mit Absicht an eine Sicherheitszone angeschlossen wird, zu der der Server nicht gehört.

In Campus-Bereichen ist die Situation meist anders.

Nehmen wir an, ein Client wird an einen aktivierten Netzwerk-Port angeschlossen, der einer Sicherheitszone zugeordnet ist. Dann ist ein Mechanismus wünschenswert, der an dem Port prüfen kann, ob das Endgerät tatsächlich auch zu dieser Sicherheitszone gehört. Nur wenn die Prüfung positiv ausfällt, sollte der gewünschte Zugang zur Sicherheitszone gewährt werden. Andernfalls sollte der Zugang abgewiesen oder nur ein (erheblich) eingeschränkter Zugang gewährt werden. Diese Authentisierung (d.h. Prüfung der Identität des Endgeräts bzw. des Nutzers des Endgeräts) sollte natürlich verlässlich sein, d.h. mit kryptographischen Mitteln erfolgen.

Analog könnte man fordern, dass für einen Client, der an einem Netzwerk-Port angeschlossen wird, im Rahmen der Authentisierung festgestellt wird, zu welcher Sicherheitszone das Gerät gehört, und nach erfolgreicher Authentisierung wird der Port dynamisch einem VLAN zugewiesen, das in das entsprechende Mandantennetz führt. Alternativ könnte hier auch mit ACLs gearbeitet werden, die am Netzwerk-Port dynamisch aktiviert werden.

Die Implementierung einer solchen Netzzugangskontrolle (Network Access Control, NAC) basiert meist auf dem Standard IEEE 802.1X (siehe [3]) in Kombination mit einer RADIUS-basierten MAC-Adress-Authentisierung und ggf. unter Nutzung eines sogenannten Captive Portal zur Browser-basierten Authentisierung z.B. von Gästen. In manchen Fällen kommen auch proprietäre NAC-Lösungen zum Einsatz.

Generell gilt jedoch, dass im kabelbasierten LAN NAC-Konzepte und deren Umsetzung sehr komplex und aufwendig sind (insbesondere im Vergleich zu WLAN).

NAC ist immer dann notwendig, wenn durch andere Mechanismen (z.B. räumliche Trennung in Verbindung mit einer Zutrittskontrolle) eine passende Zuordnung von Endgerät und Mandantennetz nicht angemessen zugesichert werden kann.

Bild 4 stellt die beschriebenen Elemente zum Aufbau von Sicherheitszonen im Zusammenhang dar.

3. Kurzschlussvermeidung
Sobald ein Endgerät Schnittstellen in unterschiedliche Sicherheitszonen hat, besteht das Risiko eines Kurzschlusses der Zonenarchitektur, da ein Angreifer potentiell nun dieses Endgerät missbrauchen kann, um an einem Sicherheitselement vorbei von einer Zone zu einer anderen Zone zu gelangen. Die Vermeidung von bzw. der Umgang mit möglichen Kurzschlüssen ist ein wesentlicher Aspekt einer Zonenarchitektur, wie die im Folgenden diskutierten Beispiele zeigen.

Server-Anbindung
Im Normalfall wird ein Server für die produktive Kommunikation an eine einzelne Zone angebunden.

Es wird jedoch immer wieder vorkommen, dass Server Schnittstellen in unterschiedliche Sicherheitszonen haben (Dual-Homed Server). Was beim Aufbau von DMZs für die Anbindung z.B. von Gateways üblich ist, birgt bei internen Sicherheitszonen, wie eben beschrieben, die Gefahr eines Kurzschlusses der Zonenarchitektur (Abbildung 5).

Hier ist stets eine Einzelfallbetrachtung nötig. Man kann jedoch grob folgende Anforderungen für den Anschluss von Servern an unterschiedliche Sicherheitszonen stellen:

  • Der Dual-Homed Server muss angemessen gehärtet sein. Der Härtungsgrad hängt vom Sicherheitsgefälle zwischen den Sicherheitszonen ab, an denen der Server angebunden ist.
  • Es muss (zumindest bei Bedarf) jede Weiterleitung von Information zwischen den verbundenen Sicherheitszonen über den Dual-Homed Server nachvollziehbar kontrolliert werden können.
  • Dual-Homed Server müssen auf Anwendungsebene die Kommunikation zwischen den Sicherheitszonen entkoppeln, insbesondere ist ein Routing zwischen den Sicherheitszonen über den Dual-Homed Server nicht gestattet.

Fortsetzung der Zonierung im Virtualisierungs-Host
In der Regel muss ein Virtualisierungs-Host (z.B. VMware ESX) Schnittstellen in unterschiedliche Sicherheitszonen erhalten. Die Segmentierung des Netzes in unterschiedliche Sicherheitszonen muss dann konsequent im Virtualisierungs-Host fortgesetzt und virtuelle Maschinen (VMs) auf dem Virtualisierungs-Host unterschiedlichen Zonen zugeordnet werden.

Hierzu wird auf dem Virtualisierungs-Host je Zone ein eigener virtualisierter Switch (vSwitch) konfiguriert und dem jeweiligen zonenspezifischen VLAN am Access Switch zugeordnet (Bild 6). Alternativ wird ein virtualisierter Switch verwendet, der unterschiedliche VLANs unterstützt und die virtuellen Ports für die VMs entsprechend ihrer Zonenzuordnung auf das jeweilige VLAN konfiguriert. Auf dem NIC des ESX-Host wird dann üblicherweise ein VLAN-Trunk konfiguriert.

Bei einem Cluster müssen die Sicherheitszonen entsprechend auf jedem Host des Cluster bereitgestellt werden und im Netz müssen die Zonen-VLANs entsprechend zur Verfügung stehen, wie in Bild 7 am Beispiel von VMware dargestellt.

Mainframe-Anbindung
Der Schutzbedarf des Mainframe ist bedingt durch die auf ihm verarbeiteten Daten meist zwingend als hoch einzustufen. Daher wird in der Praxis oft die Forderung gestellt, dass der Mainframe auf Grund seiner Kritikalität einer Sicherheitszone zugeordnet wird, die zumindest den Mainframe von Clients und eingeschränkt vertrauenswürdigen Servern abschottet.

Wenn unterschiedliche virtuelle Umgebungen auf dem Mainframe bestehen, müssen diese ggf. auch hinsichtlich der Zonenzugehörigkeit unterschieden werden. Der Mainframe kann also ggf. mehreren Sicherheitszonen zugeordnet werden. Dabei ist sicherzustellen, dass der Mainframe nicht als Router (z.B. OSPF Member) konfiguriert ist, was in der Praxis durchaus vorkommt, denn sonst würde der Mainframe die Sicherheitszonen per Routing kurzschließen können.

Load-Balancer-Anbindung
Es gibt – unabhängig von Zonenarchitekturen – unterschiedliche Anbindungsformen für einen Load Balancer (LB). Beispiele sind:

  • Network Address Translation (NAT): Beim Verwendung von NAT tauscht der LB lediglich die Ziel-IP-Adresse einer Client-Anfrage. Die Quell-IP des Clients bleibt unverändert. Dies funktioniert nur, wenn sichergestellt ist, dass die Antwort des Servers (die direkt an den Client gerichtet ist) den LB passiert, damit dieser die Quell-IP-Adresse des Antwortpakets auf seine eigene Adresse abändern kann. Dazu wird der LB als Default-Gateway vor die realen Server geschaltet. Dann kann der LB die IP-Adresse wieder tauschen und das Paket entsprechend routen.
  • Source-NAT (SNAT), auch Proxy-IP (PIP) genannt: LBs werden hier one-armed über ein einzelnes Interface angeschlossen, d.h. sie werden wie Server behandelt. Dabei tauscht der LB sowohl die Quell- als auch die Ziel-IP Adresse der Client-Pakete. Die Quell-IP des Clients wird durch die IP-Adresse des LB und die Ziel-IP-Adresse wird durch die Adresse des ausgewählten Servers ersetzt.

LBs in einer Zonenarchitektur könnten nun pro Sicherheitszone vorgesehen werden, was bei steigender Anzahl von Sicherheitszonen jedoch schnell die Grenzen der Wirtschaftlichkeit sprengt.

Daher ist es meist attraktiv zu überlegen, ob ein LB mehrere Sicherheitszonen versorgen darf. (siehe Bild 8) Damit gibt es zunächst wieder das bekannte Kurzschlussrisiko. Der LB muss also entsprechend gehärtet und durch sorgfältige Konfiguration muss das Risiko minimiert werden. Je nach Hersteller wird auch die Möglichkeit von virtuellen LBs (oder einer ähnlichen Funktion) angeboten. In diesem Fall kann ein virtueller LB pro Sicherheitszone vorgesehen werden. (siehe Bild 9).

Storage-Anbindung
Auch bei einer Anbindung an ein Storage Area Network (SAN) besteht grundsätzlich ein Kurzschlussrisiko, das allerdings durch eine geeignete Zonierung mit SAN-Bordmitteln erreicht werden kann. Bei SANs auf Basis von Fiber Channel (FC) besteht zusätzlich noch eine technologiebedingte starke Trennung zwischen IP-Netzen und SANs. Bei FC over Ethernet (FCoE) hängt das Risiko von der Netzkonfiguration ab. Werden Switches exklusiv für FCoE genutzt, ist man aus einer Sicherheitsperspektive wieder recht nah an FC herangerückt. Andernfalls müssen auf den Switches zusätzliche Sicherheitsmaßnahmen umgesetzt werden, um das Risiko zu minimieren.

Interessanter ist da schon die NAS-Anbindung. Wie bei der Betrachtung zum Thema Load Balancer ist der Einsatz eines NAS Filer pro Sicherheitszone in den meisten Fällen aus wirtschaftlichen Gründen nicht möglich. Wenn ein NAS Filer nun an mehrere Sicherheitszonen angeschlossen werden soll, muss der Filer sicherheitstechnisch zunächst wie ein Server behandelt werden und stellt natürlich ein Kurzschlussrisiko dar. Ein Filer muss daher entsprechend gehärtet werden. Sofern vom Hersteller unterstützt, sollte möglichst mit einem virtuellen Filer (vFiler) pro Sicherheitszone gearbeitet werden, wie in Bild 10 dargestellt.

4. Festlegung der Sicherheitszonen
Bei der Festlegung der initialen Sicherheitszonen einer Zonenarchitektur ist Vorsicht geboten. Im Sinne von „weniger ist mehr“ sollten nur die wirklich benötigten Sicherheitszonen angelegt und schrittweise mit Leben gefüllt werden. Es ist allerdings damit zu rechnen, dass bedarfsorientiert weitere Sicherheitszonen hinzuzufügen sind. Daher ist zu empfehlen, zur besseren Strukturierung unterschiedliche Typen von Sicherheitszonen zu spezifizieren. Beispiele sind:

  • Aufteilung nach Clients und Servern: Sicherheitszonen mit virtuellen Clients und ggf. (virtuellen) Servern und Sicherheitszonen, in denen sich ausschließlich (virtuelle) Server befinden
  • Aufteilung nach Vertrauensgrad: hohes Vertrauen (Trusted), geringes Vertrauen (Untrusted) und ggf. Restricted für eingeschränktes Vertrauen

Mit diesen Festlegungen lassen sich bei Bedarf dann auch Entwicklungs- und Testsysteme von produktiv genutzten Systemen trennen, wobei z.B. eine Sicherheitszone für Entwicklung und Test und eine weitere Sicherheitszone für Vorproduktion/Staging und IT-Produktion vorgesehen wird. Eine solche Anforderung wird ebenfalls von ISO 27001 gestellt (siehe Maßnahme A.10.1.4 in ISO 27001), die Trennung kann jedoch durch entsprechende Berechtigungskonzepte auch auf Ebene von Betriebssystem oder Plattform der beteiligten Systeme erfolgen.

Es ist empfehlenswert als Basis zunächst folgende Sicherheitszonen in Betracht zu ziehen:

  • Standard-Client-Server-Zone: Hier werden alle Systeme (Clients und Server) zusammengefasst, für die (noch) keine spezifischen Zonierungsanforderungen bestehen. Im Initialzustand kann diese Zone mit dem Office-Netz oder sogar dem Intranet einer Institution übereinstimmen. Schrittweise können dann Systeme aus dieser Sicherheitszone in andere Sicherheitszonen migriert werden.
  • Standard-Server-Zone: Hier werden alle Server positioniert, die zwar separiert werden sollen, für deren Zonierung aber keine speziellen, weitergehenden Anforderungen bestehen.
  • Common-Services-Zone: Server, die allgemein verfügbare Dienste anbieten (z.B. DNS, LDAP, Active Directory) werden hier positioniert.
  • VDI-Zone: Für virtualisierte Clients, die als VM von einer Virtual Desktop Infrastructure bereitgestellt werden, wird oft eine separate Sicherheitszone vorgesehen, da eine VDI-Lösung ja zentral im RZ aufgebaut wird und damit Client-Logik ebenfalls zentral im RZ läuft. Ansonsten könnte eine schadenstiftende Software, die eine Client-VM befällt, sich im RZ ungehindert weiter ausbreiten. Alternativ können Client-VMs auch der Standard-Client-Server-Zone zugeordnet werden.
  • Anwendungs-Virtualisierungs-Zone: Terminal Server, die Anwendungen bereitstellen, werden mit einem zur VDI-Zone analogen Argument oft ebenfalls per Default separiert. Alternativ können die Server auch der VDI-Zone oder der Standard-Client-Server-Zone zugeordnet werden.

Abbildung 11 zeigt exemplarisch die beschriebene Zonenaufteilung.

5. Konflikte zwischen Netz- und Host-basierten Sicherheitszonen
Das Domänenkonzept von Microsoft stellt ein klassisches Host-basiertes Zonenkonzept dar, bei dem Authentisierung und gruppenbasierte Berechtigungen für Windows-Systeme durch Active Directory (AD) / Domain Controller (DC) erfolgen. Eine Domäne stellt dabei ein Vertrauensbereich dar, vergleichbar zu einer Sicherheitszone. Das Domänenkonzept basiert daher auf der Arbeitsannahme, dass innerhalb einer Domäne der Verkehr nicht weiter gefiltert werden muss. Da die Kommunikation mit AD/DC in höchstem Maße komplex ist, ist außerdem eine Filterung der Kommunikation z.B. an einer Firewall entsprechend schwierig.

Hier kollidiert das Domänenkonzept von Microsoft automatisch mit einem netzbasierten Zonenkonzept. An dieser Stelle wird nicht selten gefordert, dass am besten jegliche Zonierung Host-basiert zu erfolgen habe. Das Netz möge sich auf Transportaufgaben konzentrieren, nicht mehr und nicht weniger. Das hört sich zwar gut an, ist aber unrealistisch, da es nicht konsequent umsetzbar ist.

Es bleibt also bis auf weiteres eine Tatsache, dass wir mit dem Konflikt der diametralen Zonenkonzepte leben müssen. Eine Firewall hat dann kaum eine andere Wahl als die Kommunikation zwischen Windows-Systemen und AD/DC sowie zwischen AD/DCs entsprechend freizuschalten.

Noch extremer ist der Widerspruch bei Verwendung einer Ende-zu-Ende-Verschlüsselung zwischen Hosts. Ein Beispiel ist Microsoft Domain and Server Isolation. Hier wird Host-basiert mit IPsec die Kommunikation abgesichert und optional sogar verschlüsselt (d.h. die IPsec Security Associations bestehen direkt zwischen den Hosts). Ein Firewall-System hat nun keine Möglichkeit mehr den Verkehr zu inspizieren.

6. Management der Sicherheitszonen
Die Administration von IT-Systemen ist naturgemäß eine machtvolle Aufgabe, die missbräuchlich durchgeführt einen erheblichen Schaden verursachen kann.

Daher ist eine typische Forderung die Trennung von Systemen, die zur Administration und Überwachung der Infrastruktur dienen, von funktional genutzten Systemen. Hierzu sind dann entsprechende Managementzonen vorzusehen.

Absicherung des Zugangs zu Managementzonen
Der Zugang zu Managementzonen muss mit starken Sicherheitsmaßnahmen abgesichert werden. Typisch sind hier eine starke Authentisierung und die Protokollierung von Sitzungsdaten und ggf. sogar vollständiger Administrationssitzungen. Außerdem ist oft eine starke Entkopplung von administrativen Zugriffen (speziell bei Zugriffen durch externe Unternehmen) gewünscht. Bei der Entkopplung administrativer Zugriffe werden inzwischen gerne Terminal Server und VDI eingesetzt.

Aus Verfügbarkeitsgründen ist es durchaus gängig den Zugang zu Managementzonen über eine eigene Firewall zu regeln (Management Firewall). Es gibt aber genauso Installationen, die für die Kontrolle des Managementzugriffs die produktive Data Center Firewall nutzen.

Funktionale Strukturierung der Managementzonen
Je nach Managementaufgabe werden die Sicherheitszonen oft funktional in Sicherheitszonen für Firewall-Management, Management von Virtualisierungslösungen, Server-Management, Netzmanagement, etc. aufgeteilt.

Außerdem werden üblicherweise unterschiedliche Zugriffsformen (z.B. Management-Ethernet-Port oder serielle Schnittstelle / Konsolen-Port, integrated Lights Out (iLO) – oder vergleichbare Technologie) auf die zu verwaltenden Geräte separiert.

An der Management Firewall können daher beispielsweise folgende Zonen etabliert werden (siehe Bild 12):

  • Zugangszonen für Authentisierung und Entkopplung der Kommunikation
  • Managementzonen für Managementserver (z.B. für Netzmanagement, Überwachung)
  • FW-Managementzone
  • Zonen für die Anbindung der zu administrierenden Geräte, z.B.:
    • pro funktionaler Sicherheitszone eine Zone iLO (oder vergleichbar) für Unix / Linux, Windows und ESX (oder vergleichbar) im Intranet und im Data Center
    • pro Cluster eine Zone vCenter für VMware (oder vergleichbar)
    • eine ggf. gemeinsame Zone für KVM-Switches (KVM ist die Abkürzung für Keyboard, Video and Mouse)
    • eine separate Zone für Mainframe-Administration
    • pro funktionaler Zone eine Zone für den Zugriff auf Management-Ports von Switches

Weiterhin erfolgen meist Anbindungen an alle funktionalen Zonen für ein Inband-Management.

7. Migrationsaspekte
Außerhalb der grünen Wiese ist die Migration zu einer Zonenarchitektur ein langfristiges, strategisches Unterfangen. Einer der Gründe ist, dass im Regelfall die Änderung von IP-Adressen produktiver Server (was ein Umzug in eine Sicherheitszone ggf. erfordern könnte) aus Gründen der Betriebssicherheit ausgeschlossen ist.

Die Migration einer bestehenden Infrastruktur basiert daher meist auf den folgenden Elementen:

  • Clients, die per DHCP mit IP-Adressen versorgt werden, können vergleichsweise einfach in ein anderes IP-Netz umgezogen werden. Bei der Verwendung von statischem DHCP ist der Aufwand allerdings etwas größer. Daher ist eine übliche Strategie für die Trennung von Clients und Servern in unterschiedliche Sicherheitszonen zunächst die Clients in neue IP-Netze umzuziehen, die dann an der Data Center Firewall gefiltert werden können.
  • Wenn Server bereits in eigenen IP-Subnetzen gehalten werden, kann versucht werden diese Subnetz en bloc derart zu migrieren, dass die Server zwar ihre IP-Adresse behalten, jedoch eine Firewall vor ihrem Subnetz platziert ist (die dann je nach Konfiguration als Default Gateway für die Server auftritt).
  • Bei der Beschaffung neuer IT-Systeme wird bereits bei der Planung die Zonierung berücksichtigt, damit die Systeme von Anfang an der gewünschten Sicherheitszone zugeordnet werden.

8. Betriebsprozesse

Für die nachhaltige Umsetzung einer Zonenarchitektur ist die Berücksichtigung und entsprechende Anpassung der Betriebsprozesse von entscheidender Bedeutung.

Insbesondere ist zunächst die Etablierung eines Prozesses (bzw. eine entsprechende Erweiterung eines bestehenden Prozesses) zur Schaffung neuer Sicherheitszonen erforderlich. Dies beinhaltet unter anderem die folgenden Punkte:

  • Festlegungen zur Zuständigkeit für die Schaffung einer neuen Sicherheitszone: Typischerweise ist hier die Erstellung einer Entscheidungsvorlage in der Verantwortung des Sicherheitsbeauftragten und die Entscheidung liegt bei dem entsprechenden Management Board für die Informationssicherheit.
  • Dokumentation: Mit der Beantragung einer neuen Sicherheitszone muss eine Beschreibung der Schutzziele, die mit der neuen Zone verbunden sind, erfolgen und die Kriterien zur Server- bzw. Client-Zuordnung müssen spezifiziert werden.

Eine ähnliche Situation ergibt sich bei der Einführung von neuen Anwendungen. Auch hier muss der bereits bestehende Prozess um Punkte ergänzt werden, die spezifisch für Zonenarchitekturen sind:

  • Es muss identifiziert werden, welche bestehenden und neuen IT-Systeme (Clients, Server) von der Anwendung betroffen sind.
  • Neue IT-Systeme müssen den Sicherheitszonen zugeordnet werden.
  • Regelwerke auf Firewalls müssen ergänzt und ggf. IPS-Policies angepasst werden.

Für Sicherheitszonen müssen natürlich auch Changes bearbeitet werden. Besonders wichtig ist dabei, dass bei Changes von IT-Systemen und Anwendungen geprüft wird, ob der Change von der Zonenarchitektur betroffen ist. Ein entsprechender Prüfpunkt muss zwingend im Change-Prozess berücksichtigt werden. Wenn z.B. ein Software Update eines IT-Systems oder einer Anwendung auch eine Anpassung einer Firewall-Regel oder einer IPS Policy erfordern würde, eine entsprechende Prüfung aber nicht Bestandteil des Prozesses ist, kann die Änderung auf dem Sicherheitselement übersehen werden und der Update scheitern bzw. Anwendungsfehler die Folge sein.
Auch die Prozesse im User Help Desk und im 2nd Level Support müssen um die Aspekte der Zonenarchitektur ergänzt werden. Dabei wird die ohnehin schon hohe Komplexität des Troubleshooting um eine weitere Dimension ergänzt. In der Praxis zeigt sich leider immer wieder, dass es sehr schwer sein kann, Fehler zu lokalisieren und zu analysieren, die ihre Ursache letztendlich im Verhalten einer Firewall oder eines anderen Sicherheitselements haben.

9. Fazit
Je unüberschaubarer die Landschaft der IT-Systeme in RZ und Campus wird, desto intensiver wird die Informationssicherheit eine Zonenarchitektur fordern. Dabei geht es primär um eine notwendige Ordnungspolitik und der damit verbundenen Reduktion der Angriffsfläche.

Die Komplexität einer solchen Zonenarchitektur ist allerdings erheblich und immer wieder sind Sonderbetrachtungen für den Umgang mit einem potentiellen Kurzschluss der Sicherheitszonen durch IT-Systeme, die an mehrere Zonen angebunden werden, notwendig. Als Folge gestalten sich Migration und Betrieb ebenfalls als aufwendig.

Alternativen zu einer netzbasierten Zonenarchitektur gibt es derzeit jedoch im Regelfall nicht. Damit ist letztendlich das Herz einer Zonenarchitektur stets eine entsprechend dimensionierte, leistungsfähige Data Center Firewall. Die Herausforderungen an Verfügbarkeit, Leistung und Qualität sind hier immens und es ist hier durchaus die Frage zu stellen, ob die Firewall-Hersteller dem auch gewachsen sind.

10. Abkürzungen
ACL Access Control List
BSI Bundesamt für Sicherheit in der Informationstechnik
DC Data Center
DC Domain Controller
DHCP Dynamic Host Configuration Protocol
DMZ Demilitarized Zone
DNS Domain Name System
FC Fiber Channel
FCoE FC over Ethernet
IEEE Institute of Electrical and Electronics Engineers
iLO integrated Lights Out
IP Internet Protocol
IPS Intrusion Prevention System
ISMS Information Security Management System
ISO International Organization for Standardization
KVM Keyboard, Video and Mouse
LAN Local Area Network
LB Load Balancer
LDAP Lightweight Directory Access Protocol
MAC Media Access Control
MACsec MAC Security
MPLS Multiprotocol Label Switching
NAC Network Access Control
NAS Network Attached Storage
NAT Network Address Translation
NGFW Next Generation Firewall
NIC Network Interface Card
OSPF Open Shortest Path First
IP Proxy-IP
RADIUS Remote Authentication Dial-In User Service
RTP Real-Time Transport Protocol
RZ Rechenzentrum
SAN Storage Area Network
SGACL Security Group ACL
SGT Security Group Tag
SNAT Source NAT
TOGAF The Open Group Architecture Framework
UDP User Datagram Protocol
UHD User Help Desk
VDI Virtual Desktop Infrastructure
VLAN Virtual LAN
VM Virtual Machine
VRF Virtual Routing and Forwarding
VRRP Virtual Router Redundancy Protocol
VPN Virtual Private Network
WAN Wide Area Network
WLAN Wireless LAN

11. Literatur

[1] DIN ISO/IEC 27001: Informationstechnik – IT-Sicherheitsverfahren Informationssicherheit-Managementsystem – Anforderungen, 2008
[2] IEEE 802.1AE-2006, „Media Access Control (MAC) Security“, August 2006, verfügbar unter http://www.ieee.org
[3] IEEE 802.1X-2010, „Port-based Network Access Control“, Februar 2010, verfügbar unter http://www.ieee.org
[4] Bundesamt für Sicherheit in der Informationstechnik (BSI), „IT-Grundschutz-Kataloge“, 12. Ergänzungslieferung, 2011, verfügbar unterhttps://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Download/download_node.html
[5] VMware, “vSphere 5.1 Security Hardening Guide”, verfügbar unter http://www.vmware.com/support/support-resources/hardening-guides.html
[6] Gartner, „Defining the Next-Generation Firewall“, Gartner Research Note, 12.10.2009

zugeordnete Kategorien: Archiv, Klassiker
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.