Votre VPN cloud dépend toujours de l’hébergeur

Vous avez installé le système d’exploitation, durci le service et vous détenez les clés, et il commence à sembler que le serveur est à vous. Il est à vous comme un appartement loué est à vous : la serrure est sous votre contrôle et l’immeuble non. L’hyperviseur, le réseau devant l’instance et le compte qui peut tout reconstruire appartiennent à quelqu’un d’autre. Cette distinction détermine ce qu’un plan de reprise doit couvrir, et c’est la partie que l’auto-hébergement change le moins.

Le compte est le véritable plan de contrôle

Un compte d’hébergement gère la machine virtuelle, ses disques, ses instantanés, ses adresses publiques et ses règles réseau. Tout cela peut être modifié sans même se connecter à l’invité, ce qui place le compte hors du modèle de menace que décrivent la plupart des guides VPN. Une configuration de tunnel parfaite survit à une action sur le compte qui remplace un disque.

Protégez ce compte comme un actif distinct : identifiants indépendants, seconds facteurs adossés à du matériel et une piste d’audit que quelqu’un lit réellement. Le partager avec la même entrée de gestionnaire de mots de passe que le service VPN est l’erreur qui rend tous les autres contrôles sans objet.

Lisez la répartition des devoirs du fournisseur pour le produit précis, et non pour le cloud en général. Le modèle de responsabilité partagée est un exemple utile de la façon dont les couches sont divisées, et d’autres fournisseurs décrivent leurs propres frontières plutôt que d’hériter de celle-là. Ce que vous cherchez, c’est quelles défaillances vous devez réparer et lesquelles vous ne pouvez que signaler.

Des événements d’infrastructure que vous n’administrez pas

La migration à chaud, la maintenance de l’hôte, une panne matérielle sur le nœud physique et un événement de capacité sont autant de choses que le fournisseur traite selon son propre calendrier. Vous pouvez voir un redémarrage, une brève perte de paquets ou un changement d’adresse, et vous ne verrez pas la raison. Une conception qui traite l’instance comme un point fixe interprétera chacun d’eux comme une panne du VPN. L’action corrective consiste à rendre le service tolérant à une instance qui disparaît, plutôt qu’à enquêter sur une cause qu’on ne vous montrera jamais.

Les sauvegardes relèvent de cette couche, pas du tunnel. Conservez la configuration du serveur, les identités, le plan d’adressage et les routes autorisées dans un endroit qui ne dépend pas de l’accessibilité de l’instance, et confirmez que la copie peut être restaurée sans le disque d’origine.

Le comportement de l’adresse mérite sa propre vérification. Qu’une adresse publique survive à un arrêt, à un remplacement ou à une suppression dépend de la façon dont elle a été attribuée, et les trois opérations ne sont pas interchangeables. Notez celle sur laquelle vous comptez avant qu’un incident ne rende la question urgente.

Vérifiez ce qui survit à une reconstruction

Construisez le chemin de reprise pendant que tout fonctionne. Identifiez la console ou l’accès hors bande que propose le fournisseur, confirmez que vous pouvez l’atteindre sans le tunnel et stockez les identifiants ailleurs qu’un ordinateur portable en panne ou un téléphone perdu ne les emporte. Si une modification locale du pare-feu bloque le tunnel, cette console est le seul chemin de retour.

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

Le service de métadonnées répond à des questions sur l’instance que l’invité ne peut pas voir autrement, et ses chemins exacts diffèrent selon les fournisseurs et les plateformes, alors vérifiez-les dans la documentation du produit que vous exploitez. Exécutez ensuite une reconstruction contrôlée d’une instance de test et chronométrez-la. Une procédure de reprise que personne n’a exécutée est une hypothèse.

Notez ce que la reconstruction a fait à l’adresse, aux clés d’hôte, à l’identité du disque et à tout ce que les clients épinglent. Les clients qui ont mis en cache une clé d’hôte se plaindront après une reconstruction, et cette plainte est un comportement correct, non un bug à faire taire.

Décidez ce que l’auto-hébergement change réellement

Exploiter son propre VPN déplace la confiance d’un opérateur VPN vers un hébergeur plus vous-même. C’est un vrai changement, et ce n’est pas la même chose que supprimer un tiers. Si le but était d’empêcher un VPN commercial d’observer le trafic, le fournisseur peut toujours observer le réseau de l’instance, son disque et ses relevés de facturation.

Vos propres journaux décrivent votre logiciel et ne décrivent pas chaque enregistrement d’infrastructure que le fournisseur conserve. L’inverse est vrai aussi : la visibilité de l’infrastructure n’établit pas ce qu’un fournisseur retient. Les deux questions exigent la politique du fournisseur et votre propre configuration, et aucune ne répond à l’autre.

Écrivez la réponse comme une division du travail : quelle couche a échoué, qui peut la réparer et combien de temps prend cette réparation. L’auto-hébergement change à qui vous faites confiance, et la partie utile de l’exercice est de savoir exactement pour quelle couche vous leur faites confiance.