Certaines organisations utilisent encore des serveurs jump pour fournir un accès à leurs centres de données et à leurs serveurs cloud Infrastructure-as-a-Service. Cependant, pour de nombreuses organisations, il existe un meilleur moyen de fournir un accès sécurisé à leur infrastructure. Dans cet article, nous expliquerons pourquoi les serveurs jump sont une solution obsolète pour les organisations DevOps modernes et explorerons comment une architecture cloud émergente peut les remplacer et améliorer la sécurité.
Serveurs Jump & Sécurité du périmètre
Le serveur jump, ou jump box, était un pilier pour de nombreuses organisations informatiques et équipes DevOps afin d’établir un entonnoir clair par lequel le trafic passait vers leur infrastructure. L’idée était simple: Désigner un serveur comme point de contrôle et forcer les utilisateurs à se connecter d’abord à ce système. Une fois authentifiés, ils pourraient naviguer vers d’autres serveurs sans avoir à se reconnecter.
Cette approche présentait de nombreux avantages, notamment la facilité d’utilisation après la connexion, et aidait les organisations à respecter les réglementations de conformité, car elles pouvaient fournir des journaux d’audit simples. Il a également mis en parallèle la façon dont la plupart des organisations ont implémenté la gestion des identités et des accès (IAM) dans leurs environnements. Les serveurs Jump, comme les contrôleurs de domaine Active Directory®, permettaient aux administrateurs d’établir un périmètre sécurisé autour des ressources informatiques. Une fois que les utilisateurs étaient à l’intérieur du périmètre, ils faisaient face à moins de mesures de sécurité internes.
Cependant, cette approche exposait également les organisations à des risques énormes. Une fois qu’un utilisateur — ou un mauvais acteur — a franchi le périmètre, il a pu traverser les réseaux et les ressources de l’organisation avec une relative facilité. Par exemple, le Bureau américain de la gestion du personnel a annoncé en 2015 qu’il avait subi l’une des plus importantes violations de données du gouvernement, résultant d’un serveur jump compromis. Comme Wired l’a dit après l’autopsie de la brèche: « En contrôlant la jumpbox, les attaquants avaient eu accès à tous les coins et recoins du terrain numérique d’OPM. »
Ces risques de sécurité, combinés à la nature de plus en plus complexe des pipelines CI/CD modernes (intégration continue, livraison continue et déploiement continu) et des environnements hybrides, indiquent que les serveurs jump ne sont plus le meilleur moyen de sécuriser l’accès des utilisateurs à l’infrastructure.
Nouvelle approche : Architecture sans domaine
Au fur et à mesure de l’évolution du paysage informatique, les organisations ont commencé à abandonner le concept de sécurité périmétrique au profit de méthodes plus dynamiques telles que la sécurité zero trust, dans laquelle tout le trafic réseau n’est pas fiable par défaut. Une architecture cloud émergente permet aux entreprises d’adopter une approche zéro confiance, d’augmenter leur flexibilité et d’accorder des autorisations d’accès au serveur granulaires à chaque utilisateur, entièrement à partir du cloud.
Cette architecture – qui pilote le modèle d’entreprise sans domaine — est construite autour d’un service d’annuaire cloud. À partir d’un service d’annuaire cloud, les administrateurs peuvent établir un canal sécurisé directement entre leur annuaire et chaque serveur, quel que soit l’endroit où il se trouve. Ils peuvent ensuite fournir et révoquer systématiquement l’accès à ces serveurs avec des autorisations d’accès granulaires adaptées au rôle de chaque individu.
Cette approche exige que les utilisateurs s’authentifient auprès de chaque ressource informatique de manière unique et distincte pour protéger chaque point d’accès et empêcher un accès trop large aux ressources. Il ne nécessite pas de serveur de saut, de VPN ou de toute autre infrastructure sur site pour fournir un accès.
Les services d’annuaire cloud modernes peuvent également gérer les clés SSH et activer l’authentification multifacteur (MFA/2FA) pour protéger davantage l’accès aux serveurs, ainsi que pour accélérer la mise à l’échelle automatique des serveurs afin de garantir le bon fonctionnement des pipelines.