Une plateforme qui publie des applications sur un simple dépôt de fichier doit rendre la sécurité automatique : ce qui dépend de la vigilance de l'exploitant finit toujours par céder un jour de précipitation. Les choix décrits ici visent tous le même objectif — que la protection soit une conséquence du fonctionnement, et non une étape supplémentaire.
Le cadre : à qui s'adresse cette sécurité
Il s'agit d'un cluster interne, sur réseau privé, hébergeant des services personnels ou d'équipe, avec une exposition sur Internet envisagée à terme. Le niveau d'exigence n'est pas celui d'un système bancaire ; il n'est pas nul pour autant, et surtout les limites doivent être connues. Un dispositif de sécurité dont on ignore les frontières est plus dangereux qu'un dispositif modeste et assumé.
1. Le chiffrement par construction
Toutes les requêtes entrent par un point unique, et c'est lui qui porte le chiffrement. Il en découle deux garanties qu'aucune erreur de configuration applicative ne peut annuler :
- tout ce qui est publié l'est en HTTPS, y compris une application qui n'aurait rien demandé ;
- toute requête arrivant en clair est renvoyée vers sa version chiffrée avant d'atteindre quoi que ce soit.
Le chiffrement n'est donc pas une case à cocher lors de la mise en ligne : c'est une propriété du lieu d'hébergement.
Les deux garanties, vérifiées depuis un poste client : toute requête en clair est redirigée, et le certificat présenté est validé par l'autorité locale — sans désactiver la vérification.
2. Une confiance interne plutôt que des exceptions
Sur un réseau privé, sans autorité publique, la facilité serait de générer un certificat isolé par service et d'apprendre aux utilisateurs à « passer outre » l'avertissement du navigateur. C'est précisément ce qu'il faut éviter : un utilisateur habitué à ignorer les alertes ne les lira plus le jour où elles signaleront une vraie attaque.
Le choix retenu est une autorité de certification interne, importée une seule fois sur les postes, qui signe un certificat couvrant l'ensemble du domaine. Les sous-domaines créés par la suite sont valides d'emblée, sans nouvelle manipulation. Résultat : plus aucune exception à accepter, donc une alerte redevient un signal.
3. Le cloisonnement des applications
Chaque application vit dans son propre espace, avec ses ressources, son stockage et ses secrets. Elle ne peut ni lire les données d'une autre, ni consommer sans limite le processeur ou la mémoire de la machine — des plafonds sont posés à la création.
Le cloisonnement sert aussi à la propreté des suppressions : retirer une application retire l'intégralité de ce qui lui appartenait, sans résidu oublié qui traînerait encore ouvert des mois plus tard. Et l'automate qui gère ces espaces s'interdit de toucher à ce qu'il n'a pas créé : aucune manipulation de fichier ne peut détruire un composant du système.
4. Réduire ce qui est atteignable
La meilleure protection d'un service reste qu'il ne soit pas joignable. La plateforme applique ce principe à trois niveaux :
- elle est isolée dans une machine virtuelle, sur un réseau privé — le poste hôte n'est jamais exposé au travers d'elle ;
- seuls les ports web ont vocation à être publiés vers l'extérieur ; l'administration à distance et l'interface de pilotage du cluster restent strictement internes ;
- l'administration se fait par clé cryptographique, avec une clé dédiée à la plateforme, révocable seule, distincte des clés personnelles.
5. Pouvoir revenir en arrière
La capacité de restauration fait partie de la sécurité. Ici, elle est simple parce que l'état de la plateforme tient dans trois éléments : les déclarations d'applications (quelques kilo-octets), les éléments de la chaîne de confiance et les données applicatives.
Le reste — l'état interne du cluster — n'a pas besoin d'être sauvegardé : il est reconstruit à partir des déclarations. Une reprise après sinistre consiste donc à réinstaller la plateforme puis à restaurer une archive, sans avoir à se souvenir de la configuration d'origine.
6. Les limites, écrites noir sur blanc
Quatre points sont aujourd'hui calibrés pour un usage interne et devront être repris avant toute exposition publique :
- les identifiants d'administration, volontairement simples pendant la phase de construction ;
- l'élévation de privilèges sans mot de passe, nécessaire à l'automatisation du provisionnement, à restreindre ensuite ;
- l'accès au pilotage du cluster, aujourd'hui ouvert à tout compte local de la machine ;
- la clé du certificat, présente dans l'espace de chaque application : un conteneur compromis pourrait la lire, alors qu'elle pourrait rester hors de leur portée.
S'y ajoute une absence assumée : rien n'empêche actuellement deux applications de communiquer entre elles. C'est acceptable entre services de même niveau de confiance, et à corriger dès que ce n'est plus le cas.
Le fil conducteur
Aucune de ces mesures n'est spectaculaire, et c'est voulu. Leur intérêt tient à ce qu'elles sont produites par l'outillage plutôt que par la discipline : le chiffrement n'est pas quelque chose que l'on pense à activer, le cloisonnement n'est pas quelque chose que l'on pense à mettre en place. Ils sont la conséquence mécanique du dépôt d'un fichier. Une sécurité qui repose sur la mémoire de l'exploitant est une sécurité en sursis.