Die Kommunikation zwischen den Knoten im Cluster sollte grundsätzlich nicht über die Adapter erfolgen, die auch für die Zugriffe von Clients auf diese Knoten verwendet werden. Vielmehr sollte mit einem privaten Netzwerk gearbeitet werden, das auch bezüglich der verwendeten Netzwerkkomponenten vollständig von dem für Client-Zugriffe eingesetzten Netzwerk getrennt ist. Das hat automatisch die Folge, dass die Cluster- Kommunikation über ein dediziertes Netzwerk erfolgt, das für Angreifer schwerer zu attackieren ist als das für die Client-Zugriffe genutzte Netzwerk, wo relativ einfach mit Software-Sniffern wie dem Netzwerkmonitor gearbeitet werden kann.
Zudem wird durch das getrennte Netzwerk auch eine höhere Zuverlässigkeit erreicht, da sich beispielsweise Lastprobleme durch intensive Client- Zugriffe nicht auf die clusterinterne Kommunikation auswirken.
Für die Administration der Cluster sollten selbstverständlich – wie für alle anderen Administrationsvorgänge – nur sichere Clients eingesetzt werden, um beispielsweise die Verbreitung von Würmern und Viren auf die Server zu reduzieren.
Das für den Clusterdienst verwendete Konto sollte nur die minimal erforderlichen Berechtigungen auf der Domänenebene haben. Es erhält auf den Knoten im Cluster jeweils volle administrative Berechtigungen. Diese sind aber nicht in der Domäne erforderlich und sollten daher auch nicht vergeben werden. Außerdem ist es ratsam, dieses Konto nur zum Starten des Dienstes, aber nicht für die Verwaltung des Clusters zu verwenden. Falls mehrere Cluster betrieben werden, ist pro Cluster ein eigenes Dienstkontoempfehlenswert. Administrative Berechtigungen für den Cluster können Benutzern über die Clusterverwaltung zugewiesen werden (Bild 1).
Wichtig ist auch, dass die Sicherheit auf den Knoten im Cluster sauber konfiguriert wird, ebenso wie die Zugriffsberechtigungen auf die Clusterressourcen. Auf den Quorumdatenträger sollten nur das Clusterdienstkonto und die lokalen Administratoren der Knoten im Cluster Zugriff erhalten. Für Skripts sollten gegebenenfalls entsprechende Zugriffsberechtigungen vergeben werden.
Alles in allem sind es aber nur wenige, eigentlich ohnehin selbstverständliche Maßnahmen, die bei Clustern zusätzlich ergriffen werden müssen.
iSCSI-Sicherheit
Ein besonders kritischer Aspekt bei der Cluster- Sicherheit ist die Verwendung von iSCSI. iSCSI arbeitet über Ethernet-Verbindungen und ist damit angreifbarer als dedizierte Fibre-Channel-Infrastrukturen oder SCSI-Lösungen mit mehreren Initiatoren.
Ein Ansatz für mehr Sicherheit ist die Verwendung von dedizierten Netzwerken auch für die Kommunikation zwischen den Clustern und den Storage-Servern.
Darüber hinaus unterstützt iSCSI prinzipiell auch die Authentifizierung von iSCSI-Initiators an iSCSI-Targets über ein CHAP (Challenge Handshake Protocol) und die Verwendung des sicheren IPsec Tunnel-Modus, mit dem Daten geschützt übertragen werden. Ob diese Mechanismen verwendbar sind, hängt aber von der jeweiligen technischen Implementierung des iSCSI- Target ab – der von Microsoft gelieferte iSCSIInitiator kann sie verwenden.
Solange mit dedizierten Netzwerken gearbeitet wird, die sich nur im Rechenzentrum befinden, ist das Risiko beim Einsatz von iSCSI allerdings überschaubar.