it-sa Security-Newsletter NR.9 - 01.10.2009 - Anwender-Forum
Sicherheitsaspekte bei Hochverfügbarkeitsclustern
Thorsten Früauf, Sun Microsystems GmbH
In der IT-Welt teilen die Themen Hochverfügbarkeit und Sicherheit ein ähnliches Schicksal: beide werden aus der Benutzersicht als selbstverständlich angesehen. Erst wenn ein Ausfall oder die Einschränkung eines Dienstes für den Nutzer spürbar ist, rücken beide Themen in den Fokus. Sie adressieren den Ausnahmefall, erst bei Eintritt zeigt sich die Wirksamkeit der Umsetzung.
Hochverfügbarkeit und Sicherheit stehen in einem gewissen Gegensatz: Fehler von Hard- oder Software sind unausweichlich, Hochverfügbarkeitscluster lösen dieses Problem durch Redundanzen. Statt einem System müssen nun mindestens zwei oder mehr Systeme beim Thema Sicherheit berücksichtigt werden. Durch die enge Kopplung von Clusterknoten müssen sich die Systeme vertrauen können.
Sicherheit ist aber auch eine wichtige Komponente von Hochverfügbarkeit, denn ein kompromittiertes System ist im Extremfall nicht mehr verfügbar.
Beide Themen sollte man auf mehreren Ebenen betrachten und letztlich die ganze Kette zwischen Dienstnutzer und Dienstanbieter berücksichtigen. Weder Sicherheit noch Hochverfügbarkeit kann man lediglich durch Nutzung von Produkten erreichen. Personen, Richtlinien, Vorgaben und Prozesse spielen mindestens eine genauso große Rolle.
Im Folgenden konzentriert sich die Betrachtung auf zwei Sicherheitsaspekte bei Hochverfügbarkeitsclustern, welche auf Solaris und Solaris Cluster basieren und Dienste zur Verfügung stellen: zum einen die „Härtung“ der Systeme (auch als „security hardening“ bezeichnet), also das gezielte Abschalten und Einschränken aller Dienste und Funktionen, welche zwar installiert, aber nicht benötigt werden. Zum anderen die Minimierung der Systeme, d.h. nur wirklich jene Programme, Dienste und Funktionen zu installieren, welche auch wirklich benötigt werden, um keine unnötige Angriffsfläche zu bieten.
Wichtig dabei ist, dass all diese Maßnahmen im Cluster explizit getestet und voll unterstützt sein müssen.
Härten („security hardening“) der Clusterknoten
Das Solaris Security Toolkit ermöglicht das automatisierte und nachvollziehbare An- und Ausschalten von Diensten und Funktionen gemäß eines konfigurierbaren Profils. Das Profil definiert, welches der zur Verfügung stehenden Härtungs-Skripte laufen sollte. Jedes Einzelskript führt dabei das An- oder Ausschalten eines konkreten Dienstes oder einer Funktion aus.
Es gibt ein Profil (suncluster3x-secure.driver), das die Obermenge an Diensten und Funktionen definiert, die man voll unterstützt und getestet mit Solaris Cluster abschalten kann. Wenn man das Profil an die konkreten Sicherheitsanforderungen angepasst hat, kann man so identische Konfigurationen über mehrere Systeme hinweg ausrollen, und später auch wieder mit der Audit-Funktion überprüfen. Details werden in einem Blueprint beschrieben, dessen Inhalt mit der Version des Solaris Secutity Toolkit 4.2 auch für aktuelle Solaris 10 und Solaris Cluster 3.2 Updates gültig ist.
Auf der Netzwerkebene bietet Solaris mehrere Sicherheitsoptionen mit Standardmitteln:
1. Mittels IPFilter kann man pro Knoten Firewall Regeln definieren. In Kombination mit Solaris Cluster kann man IPFilter für Failover Dienste verwenden. Hierbei ist darauf zu achten, dass man den Netzwerkverkehr für den privaten Cluster Interconnect zulässt. Die entsprechenden Regeln sind im Handbuch dokumentiert.
2. TCP-Wrapper erlauben die feingranulare Zugriffsbeschränkung für inetd basierende Dienste.
3. Internet Protocol Security (IPsec) erlaubt das Absichern von IP basierendem Netzwerkverkehrs. Dies gilt für Kommunikation von Dienstnutzern zu den Diensten im Cluster auf dem (aus Cluster Sicht) öffentlichem Netzwerk. Gleichermaßen kann innerhalb des Clusters auch der private Interconnect (Abgleich der Clusterkonfiguration, Daten des globalen Filesystem, private Kommunikation der Anwendungen (z.B. Oracle RAC Cache-Fusion), etc) mittels IPsec abgesichert werden. Details dazu stehen im Handbuch.
Auf der Anwendungsebene kann durch Verwendung von Solaris Containern (Solaris Zonen) die Laufzeitumgebung für Anwendungen beschränkt, eingekapselt und abgegrenzt werden. Ein „Ausbrechen“ aus der Zone ist nicht möglich.
Mit dem HA Solaris Container Agenten ist man in der Lage so genannte Failover-Zonen zu implementieren und so Zonen zwischen Cluster Knoten zu schwenken. Zusätzlich wird hier aus einem Container ein flexibler Container. Das heißt, es ist völlig unerheblich, auf welchem der am Cluster beteiligten Systeme der Container abläuft. Diese Option ist besonders geeignet wenn man Administrationsrechte an Nutzer der Zone komplett delegieren möchte und sie als Blackbox begreift.
Man kann auch lediglich die Dienste (in der Regel Anwendung, Filesysteme und IP-Adressen) zwischen Zonen schwenken, welche auf unterschiedlichen Clusterknoten laufen, und dabei alle Sicherheitsvorteile von Zonen nutzen, die Solaris von Hause aus bietet.
Schließlich gibt es noch die Möglichkeit einen virtuellen Cluster aus lokalen Zonen zu konfigurieren, welche auf unterschiedlichen physikalischen Clusterknoten laufen. Hierbei kann ebenfalls die Administration eines virtuellen Clusters an den Administrator der beteiligten Zonen delegiert werden.
Der Solaris Cluster Concepts Guide bietet Entscheidungshilfen über das Pro und Contra der verschiedenen Optionen mit Solaris Zonen innerhalb Solaris Cluster.
Natürlich können noch viele weitere Sicherheitsmechanismen von Solaris in Kombination mit Solaris Cluster genutzt werden, wie etwa rollenbasierte Zugriffskontrolle (RBAC - Role Based Access Control). Generell ist darauf zu achten das alle Einstellungen konsistent über alle Clusterknoten vorgenommen werden.
Hierbei kann das Cluster Control Panel verwendet werden. Mittels cssh werden mehrere Verbindungen über SSH gleichzeitig zu allen Cluster Knoten oder deren Console geöffnet. Die zentrale Eingabemaske verteilt dabei alle Eingaben einheitlich auf die unterschiedlichen Fenster.
Minimierung der Clusterknoten
Die Installationsanleitung für Solaris Cluster 3.2 und Solaris 10 definiert das minimal unterstützte Gruppenpaket für Solaris 10: End User Solaris Software Group (SUNWCuser). Das Installationsprogramm von Solaris Cluster erlaubt die Selektion von optionalen Cluster Komponenten (Geo Edition, Quorum Server, Agentbuilder, individuelle Cluster Agenten, etc).
Mit der Einführung des Image Packaging System (IPS) in OpenSolaris als Alternative zu dem bisherigen SVR4 Paket Formats wurden die Abhängigkeiten zwischen Cluster Paketen untereinander und gegenüber Solaris Paketen neu ermittelt und explizit definiert. Mit der Kombination OpenSolaris 2009.06 und Open HA Cluster 2009.06 kann somit über die Gruppenpakete eine weiter minimierte Installation bezogen auf die absolut notwendigen Pakete erzielt werden.
Fazit
Mit Solaris und Solaris Cluster lassen sich komplexe Anforderungen an IT-Sicherheit und Hochverfügbarkeit von Diensten umsetzen und realisieren. Die in Solaris verfügbaren Sicherheitsmechanismen, vor allem bei der Verwendung von Containern, lassen sich nahtlos in hochverfügbare Infrastrukturen auf der Basis von Solaris Cluster integrieren. Dafür stehen in der Praxis bewährte und unterstützte Verfahren zur Verfügung.
Referenzen
1. Solaris Security Toolkit: http://www.sun.com/software/security/jass/
2. Blueprint – Securing the Sun Cluster 3.x software:
http://www.sun.com/blueprints/0203/817-1079.pdf
3. IPFilter Konfiguration mit Solaris Cluster:
http://docs.sun.com/app/docs/doc/820-4677/gftcs?l=en&a=view
4. IPsec Konfiguration mit Solaris Cluster:
http://docs.sun.com/app/docs/doc/820-4677/ghqmg
5. SSH Unterstützung für das Cluster Control Panel: http://blogs.sun.com/SC/entry/ssh_support_for_cluster_console
6. Unterstützung von Solaris Zonen in Solaris Cluster:
http://docs.sun.com/app/docs/doc/820-4676/gcbkf?l=en&a=view
