Le produit de mon entreprise est essentiellement une boîte Linux (Ubuntu) située dans le réseau de quelqu'un d'autre exécutant notre logiciel. Jusqu'à présent, nous avions moins de 25 boîtes à l'état sauvage et utilisions TeamViewer pour les gérer.

Nous sommes sur le point d'expédier 1000 de ces boîtes et TeamViewer n'est plus une option. Mon travail consiste à trouver un moyen d' accéder à ces boîtes et de mettre à jour le logiciel sur celles-ci . Cette solution devrait être capable de percer les pare-feu et ce que vous avez.

J'ai pensé:

1. Solution maison (par exemple un service Linux) qui établit un tunnel inverse SSH vers un serveur dans le cloud, et un autre service dans le cloud qui en assure le suivi et vous permet de vous y connecter.

Cela demande évidemment beaucoup de main-d'œuvre et, à vrai dire, on a l'impression de réinventer la roue, car tant d'autres entreprises doivent déjà avoir rencontré ce problème. Même ainsi, je ne suis pas sûr que nous ferons un excellent travail.

2. Outils tels que marionnette, chef ou OpenVPN

J'ai essayé de lire autant que possible mais je n'arrive pas à pénétrer suffisamment à travers le marketing pour comprendre le choix évident à suivre.

Personne d'autre que nous n'a besoin de se connecter à ces boîtiers. Y a-t-il quelqu'un avec une expérience pertinente qui peut me donner quelques conseils?

Tirer des mises à jour, ne pas pousser

À mesure que vous évoluerez, il deviendra impossible de faire des mises à jour push pour tous vos produits.

• Vous devrez suivre chaque client, qui pourrait avoir une configuration de pare-feu différente.
• Vous devrez créer des connexions entrantes via le pare-feu du client, ce qui nécessiterait une redirection de port ou un autre mécanisme similaire. Il s'agit d'un risque pour la sécurité de vos clients

Au lieu de cela, demandez à vos produits de récupérer régulièrement leurs mises à jour, puis vous pouvez ajouter une capacité supplémentaire côté serveur au fur et à mesure de votre croissance.

Comment?

Ce problème a déjà été résolu, comme vous l'avez suggéré. Voici plusieurs approches auxquelles je peux penser.

• en utilisant apt : utilisez le système apt intégré avec un PPA personnalisé et une liste de sources. Comment configurer un PPA?
  • Inconvénients: à moins que vous n'utilisiez un service d'hébergement public comme le tableau de bord, la configuration de votre propre système d'emballage PPA + n'est pas pour les âmes sensibles.
• using ssh : Générez une clé publique SSH pour chaque produit, puis ajoutez la clé de cet appareil à vos serveurs de mise à jour. Ensuite, il vous suffit d'avoir votre logiciel rsync/ scples fichiers requis.
  • Con: devez suivre (et sauvegarder!) Toutes les clés publiques de chaque produit que vous envoyez.
  • Pro : Plus sûr qu'un téléchargement brut, car les seuls appareils qui peuvent accéder aux mises à jour seraient ceux avec la clé publique installée.

• téléchargement brut + vérification de signature :

  • Publiez un fichier de mise à jour signé quelque part (Amazon S3, serveur FTP, etc.)
  • Votre produit vérifie périodiquement le fichier de mise à jour à modifier, puis télécharge / vérifie la signature.
  • Con : Selon la façon dont vous déployez cela, les fichiers peuvent être accessibles au public (ce qui peut faciliter la rétro-ingénierie et le piratage de votre produit)

• ansible : Ansible est un excellent outil pour gérer les configurations du système. C'est dans le domaine des marionnettes / chefs, mais il est sans agent (utilise du python) et conçu pour être idempotent. Si le déploiement de votre logiciel nécessitait un script bash compliqué, j'utiliserais un outil comme celui-ci pour simplifier l'exécution de vos mises à jour.

Bien sûr, il existe d'autres façons de le faire .. Mais cela m'amène à un point important.

Signez / validez vos mises à jour!

Quoi que vous fassiez, il est impératif que vous ayez un mécanisme pour vous assurer que votre mise à jour n'a pas été falsifiée. Un utilisateur malveillant pourrait emprunter l'identité de votre serveur de mise à jour dans l'une des configurations ci-dessus. Si vous ne validez pas votre mise à jour, votre boîte est beaucoup plus facile à pirater et à entrer.

Une bonne façon de procéder consiste à signer vos fichiers de mise à jour. Vous devrez conserver un certificat (ou payer quelqu'un pour le faire), mais vous pourrez installer votre empreinte digitale sur chacun de vos appareils avant de les expédier afin qu'ils puissent rejeter les mises à jour qui ont été falsifiées.

Sécurité physique

Bien sûr, si quelqu'un a un accès physique au déploiement du client, il peut facilement prendre le contrôle du serveur. Mais au moins, ils ne peuvent pas attaquer les autres déploiements! La sécurité physique est probablement la responsabilité de votre client.

Si vous voulez un instant, imaginez ce qui se passerait si vous utilisiez un grand réseau OpenVPN pour les mises à jour ... Ils pourraient alors utiliser le serveur compromis pour attaquer chaque instance sur le VPN

Sécurité

Quoi que vous fassiez, la sécurité doit être intégrée dès le début. Ne coupez pas les coins ici - vous le regretterez à la fin si vous le faites.

La sécurisation complète de ce système de mise à jour est hors de portée de cet article, et je recommande fortement d'embaucher un consultant si vous ou un membre de votre équipe ne connaissez pas ce domaine. Ça vaut chaque centime.

Avez-vous réellement besoin d'y accéder?

Ou tout simplement les mettre à jour? Parce que vous pouvez les faire se mettre à jour eux-mêmes, de la même manière que les mises à jour aptes sont autonomes.

Si vous devez vous connecter

Pourquoi pas un démon OpenSSH qui écoute via la redirection de port? Chaque client peut avoir une clé de sécurité distincte et ne serait connecté qu'en cas de besoin.

Jusqu'à vos clients

Vous devez également prendre en considération ce que le client est prêt à accepter. Ils peuvent ne pas être à l'aise avec un accès à distance à leur réseau, ou seulement à l'aise avec des technologies / configurations spécifiques.

Je suggère un outil d'orchestration comme Puppet ou Salt .

Salt est une file d'attente de messages et peut établir une connexion sortante persistante entre votre appliance et un serveur maître. Vous pouvez l'utiliser pour exécuter des commandes arbitraires sur les appliances ... comme un apt-get.

L'autre option est Puppet, où vous avez toujours un serveur maître et les clients établissent des connexions sortantes à partir de leurs emplacements.

J'utilise ces deux outils dans un but similaire où je n'ai peut-être pas le contrôle administratif du pare-feu.