Accès au contenu		Début du rapport
	Description		Compte-rendu de la conférence organisée par le Clusif sur les SAN
	Contexte & Dates		Rapport réalisé pour notre service de veille en actualité . La différence entre la date de rédaction et la date d'envoi est généralement due aux corrections et relectures par les différentes personnes ayant participé à la conférence. 18 octobre 2002 - Rédaction du compte-rendu 21 octobre 2002 - Envoi aux abonnés de la veille en actualité 5 avril 2004 - Publication sur le site web d'HSC
	Auteur		Hervé Schauer (Herve.Schauer@hsc.fr)
	Langue et Nature
	Résumé & Table des matières
	Documents liés
	Droits d'auteur		© 2002, Hervé Schauer Consultants, tous droits réservés.

Le Clusif a organisé une conférence sur les SAN (Storage Area Network) et leur sécurité le jeudi 17 Octobre.

Jacques Anis, consultant, a introduit la conférence en rappelant que le SAN permet de maîtriser l'explosion des volumes, et qu'il permettra à terme de gérer l'hétérogénéité des supports : format AS400, Unix, Windows, et des méthodes d'accès. Cela permettra d'éviter d'avoir la même donnée stockée plusieurs fois dans des méthodes différentes.

Gilles Potard, de MTI, un des fournisseurs de SAN avec Brocade, Compaq, EMC, IBM, etc, a présenté les principes et les technologies. Un SAN est typiquement composé de stockage (les disques), d'un système de sauvegarde, des commutateurs, de cartes HBA (Host Base Adapter) pour connecter les serveurs à la fibre optique, et éventuellement de routeurs si l'on doit pouvoir ressortir sur un WAN.
Par défaut, tout périphérique connecté au SAN est accessible par tous les serveurs. Un contrôle d'accès peut être appliqué sur les trois composants du SAN :

1. Sur chaque carte HBA des serveurs
2. Sur le commutateur central
3. Sur chaque carte contrôleur des disques

1. Sur la carte HBA du serveur : chaque carte HBA a une adresse unique de 12 chiffres. Il est possible de faire du "LUN masking" afin de ne voir qu'un sous-ensemble de partitions de stockage. Cependant cette solution est complexe et non sécurisée, car tout administrateur de serveur peut tout s'approprier. De plus, à chaque installation d'une nouvelle carte HBA dans le SAN il faut reconfigurer chaque serveur.
2. Sur le commutateur : il est possible d'associer des adresses de cartes HBA à des partitions ou espaces de stockage : "Data zoning" ou "Fibre Channel zoning". Cela permet une gestion centralisée, de port à port. Mais MTI considère que c'est une sécurité faible car il n'y a pas de redondance, et si le commutateur tombe en panne il faut refaire toute la configuration.
3. Sur la carte contrôleur des disques : il est également possible de dire quels HBA peuvent accéder au contrôleur, le "LUN mapping". La gestion est centralisée et c'est pour MTI la sécurité optimale. Le système de configuration est protégé par mot de passe, et par le fait qu'il est propriétaire et inconnu d'après MTI.

MTI est prêt à s'engager contractuellement afin de garantir l'étanchéité et pense que des serveurs applicatifs qui ne sont pas connectés entre eux au niveau du réseau local, peuvent partager le même SAN en toute sécurité. S'il est possible de prendre la main sur le commutateur, il n'est pas possible de prendre la main sur le contrôleur RAID sur lequel MTI garantit l'étanchéité.

Eric Aubert, d'Atis Real, la filiale informatique de Vendôme Rome, le premier groupe immobilier européen, a mis en oeuvre récemment un SAN. Ce SAN a permis de faciliter une migration en vue de minimiser le nombre de serveurs après des rachats de sociétés.
Il confirme que, par expérience, il constate que le disque est l'élément le plus délicat du SAN, mais la haute-disponibilité coûte très cher, donc la solution adoptée qu'il recommande est de couper en deux les serveurs :

• Une partie disque avec les données applicatives
• Une partie disque avec le système d'exploitation, et le reste avec la mémoire, le CPU, etc.

Jacques Ferre, Alstom Transport, a montré que le choix d'un SAN dans son entreprise est venu essentiellement du problème d'espaces disques perpétuellement saturés sur la messagerie et sur Lotus Notes en 1999. Le déploiement du SAN était intégré dans un projet plus large avec aussi la construction d'une deuxième salle machine avec une nouvelle réplication des serveurs. Les principaux enseignements qu'il tire sont qu'il faut bien impliquer les administrateurs système dès le départ, qu'il vaut mieux laisser le système d'exploitation sur un disque dédié en miroir dans les serveurs, et qu'il ne faut pas oublier la sauvegarde et l'archivage.

Si MTI est prêt à s'engager contractuellement sur l'étanchéité, il reconnaît aussi qu'il n'a pas connaissance d'étude concernant la sécurité. Je rappelle pour ma part que les contrôleurs RAID des baies de stockage sont des ordinateurs, que l'on gère via une interface série ou plus souvent par un réseau local IP, afin notamment de remonter les alarmes. Il convient d'avoir un réseau de supervision totalement cloisonné des réseaux de production. De plus, personne ne semble s'être intéressé aux possibilités d'usurpation d'adresses.

Mon sentiment est que les SAN font peut-être actuellement la sécurité par l'obscurité.

Cependant, à mon avis, cette technologie est importante et pourrait être utile pour l'avenir en sécurité. Dans les mainframes, nous avions une gestion cohérente du contrôle d'accès entre applications et données. Dans l'informatique actuelle, il n'est plus possible de répartir ce contrôle d'accès dans des centaines de serveurs et seul un contrôle d'accès dans le réseau dans les applications client/serveur est possible. Avec les SAN, le RSSI retrouvera des commutateurs en petit nombre qui permettront de manière réaliste d'appliquer une politique de sécurité en construisant un contrôle d'accès entre les applications et les données.

Les présentations seront disponibles sur le site du Clusif pour les membres du Clusif.

Acronymes
LUN : Logical Unit Number

Pour en savoir plus :
Jacques Anis & Associés : http://www.jaa.fr/ : Le site n'existe plus.
MTI : www.mti.com

Hervé Schauer