La célèbre citation de Werner Vogels « You build it, you run it », prônant le partage des responsabilités entre les développeurs et les opérations, est aujourd’hui un mantra du DevOps. Plus récemment, John Willis est passé à l’étape suivante avec « You build it, you secure it », lorsqu’il a déclaré : « Les développeurs ont la responsabilité de permettre, et dans de nombreux cas d’opérationnaliser, leur service. Il existe maintenant un nouveau mouvement pour inclure et collaborer d’une manière similaire avec la sécurité. Tout cela fait partie de l’approche idéale où nous déplaçons tout ce qui reste dans le pipeline de livraison.

Avec DevOps sur le cloud public, la sécurité ne peut être ignorée

L’une des activités quotidiennes de DevOps, qui s’effectue à l’infini, consiste à permettre une connectivité réseau sécurisée. Découvrez comment les équipes de DevOps peuvent automatiser et « posséder » une connectivité réseau sécurisée, simplifiant et accélérant ainsi une tâche qui les ralentit souvent.

Et il ne s’agit pas d’un problème isolé. Selon une enquête du SANS Institute, « 73 % des personnes interrogées, soit une augmentation de 30 % par rapport à l’année précédente, défendent les applications dans le nuage public, et 34 % prévoient de le faire dans les 12 prochains mois. Soixante-cinq pour cent d’entre eux sont déjà impliqués dans la sécurisation d’applications dans des conteneurs (contre 28 % en 2017), tandis que 45 % s’attendent à ce que ce chiffre augmente au cours des 12 prochains mois ».

Avec DevSecOps maintenant sur la table pour la plupart des organisations, il est temps de prendre en compte son environnement d’exploitation afin de concevoir et/ou de mettre en œuvre une infrastructure de sécurité qui non seulement défend l’accès aux applications critiques, mais le fait d’une manière simple, efficace et rentable.

Intégrer l’accès sécurisé dans le plan

Un aspect important de toute stratégie de cloud computing est de fournir un accès à distance qui soit simple, sécurisé et – autant que possible – automatisé. Cela semble simple, mais la plupart des entreprises font des compromis sur au moins certains de ces objectifs. L’accès à distance sécurisé ne fait généralement pas partie des processus DevOps ou DevSecOps automatisés. Les définitions sont plutôt configurées manuellement pour chaque fournisseur de cloud computing. Dans d’autres cas, l’automatisation est mise en œuvre, mais la sécurité est compromise.

Les solutions d’accès à distance sécurisé Zero-trust offrent une alternative sans compromis aux DevSecOps. Les approches avancées dans ce domaine permettent aux développeurs de sécuriser de manière proactive l’accès aux DevOps et aux environnements en nuage tout en intégrant des politiques d’accès automatisées dans leurs processus et leur production de CI/CD. Les équipes DevOps obtiennent un accès granulaire aux applications et services spécifiques dont elles ont besoin (et rien d’autre), le tout avec une configuration minimale.

Accès au centre de données et au cloud défini par une politique, un peu sur les réseaux cloud sécurisés. De nombreux experts recommandent maintenant un réseau mondial superposé déployé sur une dorsale mondiale de PoPs. La distribution des points de présence et leur proximité avec les utilisateurs distants permet d’offrir une expérience optimale aux utilisateurs lorsqu’ils se connectent à distance aux ressources de l’entreprise et du cloud, quel que soit leur emplacement. La bonne solution d’accès à distance de confiance zéro serait conçue autour des utilisateurs, plutôt que des centres de données ou des bureaux. Les administrateurs définissent de manière centralisée des politiques qui contrôlent précisément les ressources réseau auxquelles les utilisateurs peuvent accéder. Les utilisateurs se connectent une fois au réseau sécurisé, et de là aux cibles définies par la politique – qu’ils se trouvent dans le centre de données, le nuage ou une succursale.

Bien entendu, les politiques d’accès à distance ne se limitent pas à l’interface utilisateur (IU) de l’administrateur. Les administrateurs peuvent utiliser l’API pour inclure les politiques d’accès dans le cadre des flux de travail de DevOps, ce qui permet d’automatiser et d’accélérer la sécurité, de réduire les risques et d’accroître la productivité.

Exemple : Permettre l’accès à distance à un consultant\nPour comprendre la complexité du problème, considérez un cas où vous voulez fournir à un consultant un accès à un environnement de mise en scène Jenkins dans le nuage afin qu’il puisse enquêter sur une question. Une topologie de réseau traditionnelle utilisant OpenVPN nécessite généralement ce qui suit :

  • Installer OpenVPN
  • Mise en place du répertoire des autorités de certification (CA)
  • Configuration des variables de l’AC
  • Mise en place de l’autorité de certification
  • Création du certificat du serveur, de la clé et des fichiers de cryptage
  • Génération d’un certificat client et d’une paire de clés
  • Configuration du service OpenVPN
  • Ajustement de la configuration réseau du serveur
  • Démarrer et activer le service OpenVPN
  • Création d’une infrastructure de configuration du client
  • Installation de la configuration du client
  • Définir les règles d’accès

Avec une solution d’accès à distance sécurisée comme un logiciel de confiance zéro défini par le périmètre (SDP), la mise en place d’un accès à distance est nettement plus facile, sans rien à installer ou à configurer du côté client :

Au lieu des étapes 1 à 9 ci-dessus, installez un certificat unique et une appliance virtuelle en exécutant un script automatisé. La même solution/service est utilisée pour tous les nuages (privés et publics). Avec lui, les administrateurs définissent les services ou les sous-réseaux qu’ils veulent exposer et définissent de manière centralisée les politiques d’accès. Tous les accès sont micro-segmentés et entièrement enregistrés et audités. L’administrateur crée facilement des liens pour fournir un accès simple et en un seul clic au consultant à partir de son navigateur.

Exemple : Accès automatisé

Le processus peut également être automatisé pour les IC en utilisant une API. Voyons comment cela fonctionnerait à la dernière étape du processus ci-dessus, la création d’un « lien facile ». Un appel API créerait un lien d’accès comme celui ci-dessous, vers le serveur Jenkins et permettrait au consultant externe d’accéder à l’instance Jenkins et de déboguer.

Lorsque le consultant visite le portail SSL-VPN, il peut voir un écran qui comprend des liens vers des ressources réseau supplémentaires. En cliquant sur le lien Jenkins (AWS), elle se rendra sur le serveur. Notez que l’accès à distance s’effectue via SSL (HTTPS) malgré le fait que le serveur Jenkins mappé utilise HTTP. La solution SDP de confiance zéro (dans ce cas) fournit un accès sécurisé à une ressource interne non sécurisée.

Chen Nisnkorn est un leader technologique à part entière, avec une expérience en R&D, ventes, SE et CS, qui s’efforce d’établir des relations à long terme avec des clients allant des entreprises du Fortune 500 aux start-ups. Pour en savoir plus, téléchargez un livre blanc détaillé sur le sujet.