Comment Fujitsu veut rendre invisibles les centres de calcul

Sortir les applications sensibles du systèmes d’exploitation

Cette approche s’appuie sur plusieurs composants parmi lesquels Sealed Applications Solution, ou SAS, apparaît clé. De fait, celle-ci s’appuie sur un conteneur dissocié du système d’exploitation, un environnement d’exécution de confiance (TEE) dont on trouve l’implémentation dans les processeurs mobiles, mais aussi AMD et Intel. Thorsten Höhnke fait un parallèle avec le Knox de Samsung et explique « le conteneur lui-même utilise le système d’exploitation pour accéder aux données […] mais il n’en est pas captif, contrairement à quelque chose qui s’exécute dans le système d’exploitation ». Un impératif car « il est impossible de sécuriser parfaitement un système d’exploitation ».

Un cœur physique est entièrement mobilisé pour l’exécution des logiciels placés dans ce conteneur totalement transparent pour eux : « l’application ne sait pas qu’elle fonctionne dans le conteneur et pas dans le système d’exploitation ». Dès lors, comme dans un environnement virtualisé, une application existante peut s’exécuter sans modification.

SAS a nécessité près de 5 ans de développement chez Fujitsu. Le groupe veut à terme supporter tout système d’exploitation, qu’il s’agisse de Windows, de Linux, d’OS X, ou encore d’iOS et d’Android. Mais pourquoi pas bien plus car l’éventail des applications apparaît vaste.

La commercialisation de SAS doit commencer par l’Allemagne, l’Autriche et la Suisse. Le reste de l’Europe – et du monde – devra attendre. Mais c’est tout le modèle économique de SAS qui fait encore l’objet d’une réflexion. Thorsten Höhnke explique ainsi avoir discuté avec des spécialistes de la protection du poste de travail que le point d’observation offert par SAS. Surtout, il précise que Fujitsu entend ouvrir le code de sa solution pour en permettre l’examen par la communauté, par exemple pour garantir l’absence de portes dérobées.

Sécuriser les communications

La solution SAS est mise à profit au sein d’une seconde, Stealth Connect Solution (SCS). Là, elle assure le chiffrement, avec l’algorithme Blowfish 448 bits, des données qui sont échangées sur un lien lui-même chiffré : un VPN établi avec OpenVPN. « Ce VPN permet d’assurer le routage de données pour lesquelles la première couche de chiffrement a supprimé les métadonnées »… tout en protégeant ces données des éventuelles vulnérabilités d’OpenVPN.

Un premier boîtier, la Stealth Connect Box (SCB), est déployé dans les locaux où sont installés les postes clients susceptibles de se connecter au serveur VPN. De l’autre côté, celui-ci est masqué de l’extérieur par l’appliance Central Stealth Connect (CSC). Cette dernière se comporte comme un routeur interne doublé d’un serveur relais. Elle embarque également le serveur VPN.

Les postes clients connaissent l’adresse IP publique de l’appliance CSC, mais celle-ci n’expose aucun port sur Internet : « l’infrastructure ne répond pas aux requêtes externes ; c’est pour cela que l’on la qualifie de furtive », explique Thorsten Höhnke. Pourtant, les postes clients doivent bien pouvoir s’y connecter…

Pour cela, il se signalent à l’appliance CSC, selon un schéma validé par certificat, mais changeant à chaque tentative : « c’est un mécanisme que nous avons fait breveter ». Et pendant « environ 2 ms », un port – choisi aléatoirement – est ouvert pour l’établissement du lien VPN lorsque la signature du poste client a été reconnue. Et là encore, le client doit s’authentifier auprès du serveur VPN. « Avec un peu de chance, et si vous connaissez l’adresse IP, vous pouvez voir passer l’ouverture de port, mais ce n’est pas suffisant pour faire quoi que ce soit », estime Thorsten Höhnke.

Pour décrire quelque peu ce schéma d’invocation breveté, il fait référence aux poupées russes – sans en indiquer le nombre – : des données d’identification de l’utilisateur et de son terminal, notamment, sont chiffrées et imbriquées les unes dans les autres.

SCS doit commencer à être commercialisé au printemps.

Une robustesse éprouvée

Pour Thorsten Höhnke, Fujitsu construit là « un environnement totalement maîtrisé, où l’on sait quelles données attendre, quelles applications fonctionnent. Tout le reste peut être ignoré ». Du coup, « pare-feu et IPS ne sont pas nécessaires ».

Lors de notre échange, début janvier, des tests d’intrusion étaient en train d’être réalisés par des tiers. Mais Fujitsu avait déjà réalisé les siens, en interne, en s’appuyant sur Kali Linux, mais aussi sur les outils de Qualys, ou encore sur ceux de Tenable et de Rapid7. Mais tous sont ressortis bredouilles assure Thorsten Höhnke qui résume ainsi : « la première fois que j’ai vu les résultats, j’ai demandé ‘vous êtes sûr que le système est en route ?’ ».

Fujitsu prévoit en parallèle de commercialiser entre le printemps et la fin 2016 deux solutions de protection des accès physiques au contenu des racks avec une authentification par reconnaissance palmaire et, sur demande, d’autres méthodes biométriques. Celles-ci doivent tirer profit de SCS et, par ricochet, de SAS.

Les données d’identification seront chiffrées et leur comparaison doit se faire sans déchiffrement. Pour cela, Fujitsu s’appuie en fait sur une technologie qu’il vient tout juste de présenter à l’occasion de son North America Technology Forum à Santa Clara, en Californie.