Pour être compétitives, les entreprises doivent innover continuellement et aller vite.
DevOps et sécurité : ce qu’il faut changer
Du DevOps au DevSecOps
Cela signifie qu’elles doivent être capables de sortir de nouveaux produits et de nouvelles fonctionnalités pour satisfaire des clients toujours plus connectés et demandeurs de nouveautés. Mais au-delà de l’innovation pure, le challenge encore plus important est la capacité pour l’entreprise à sortir ces nouveautés le plus rapidement possible, afin de s’assurer un avantage concurrentiel précieux. Et à notre époque, l’avantage est à l’entreprise qui va le plus vite et non à celle qui a le plus de moyens.
Pour optimiser les temps de développement et de déploiements applicatifs, les entreprises commencent à s’appuyer sur le concept DevOps. Cette méthode vise à mettre fin aux silos – un problème récurrent et culturel français – au sein des entreprises, en favorisant la collaboration et la coordination des équipes (développement, administration systèmes, qualification, etc.) sur des projets de développement spécifiques. L’objectif étant de gagner en rapidité et de mieux gérer les risques. Preuve de l’engouement pour ce concept,
le Cabinet Vanson Bourne estimait en 2015 que 95% des entreprises françaises planifiaient la mise en œuvre du DevOps afin d’accélérer le développement d’applications.
Reste un problème persistant : aller vite signifie souvent faire l’impasse sur la sécurité. Pourtant, la sécurité est un mal plus que nécessaire, même si elle est souvent perçue comme une contrainte par les équipes, tant du côté des développeurs, que du côté des administrateurs systèmes.
Alors comment assurer des déploiements applicatifs de plus en plus rapides tout en garantissant la sécurité du système d’information ? Cela passe notamment par l’implication des équipes sécurité dès le début des projets DevOps, et par l’évolution de leurs pratiques existantes. Pour suivre ce rythme effréné et ne pas ralentir les équipes, la sécurité doit également de plus en plus s’appuyer sur l’automatisation.
Ne parlons plus de DevOps mais plutôt de SecDevOps
Au sein de projets DevOps, la sécurité a un rôle très important à jouer car elle doit permettre de sécuriser l’application mais aussi le système d’information tout entier. De ce fait, l’équipe sécurité ne peut plus rester une équipe à part dans l’entreprise, et l’on ne peut plus parler de DevOps sans parler de sécurité. C’est ainsi qu’est né le terme de SecDevOps.
-
SecDev – Sécuriser le code applicatif
- un certain nombre d’outils permettent d’analyser le code et de réaliser des audits réguliers pour détecter les failles et les vulnérabilités à la source. Nous pourrions comparer cela à un correcteur d’orthographe et de grammaire.
- SecOps – Sécuriser le système d’information
- les administrateurs systèmes voient de plus en plus évoluer leur métier vers celui d’architecte. L’avènement de la virtualisation et du Cloud est venu faciliter la disponibilité du système d’information par la mise en place de mécanismes de redondance automatique, voire de plan de reprise d’activité (PRA) automatique. Les mécanismes de redondance ou de PRA ne doivent pas être identifiés par les seules équipes opérations. L’implication des équipes de développement est indispensable dans la définition des architectures afin d’aller vers des systèmes de redondance transparents pour l’utilisateur final.
Certaines vulnérabilités propres aux systèmes d’exploitation existent également : ces failles détectées nécessitant une mise à jour du système d’exploitation par exemple. Là encore, la mise en place d’outils permettant de détecter en temps réel et/ou régulièrement les systèmes pour maintenir à jour l’ensemble du parc, est nécessaire. La mise en place de ces outils doit être poussée rapidement et à grande échelle afin de maintenir le système à jour. Des outils comme Chef, Puppet et mcollective permettent de déployer rapidement des nouveaux packages sur un grand nombre de serveurs.
Les métiers évoluent, de nouvelles méthodes de travail apparaissent
Plutôt que de grandes mises à jour, les équipes préfèreront souvent de petites « releases » qui peuvent être poussées plus rapidement sur les environnements de production, et à une plus grande fréquence. Le risque est alors mieux maîtrisé.
Auparavant, les administrateurs systèmes étaient concentrés sur la stratégie du « comment », c’est à dire « comment mettre à jour nos milliers de serveurs ? ». Aujourd’hui, avec l’automatisation du « comment », ils passent directement à la question du « quoi ? » (« Qu’est ce qui doit être mis à jour ? ») et du « quand ? » (« A quel moment puis-je mettre à jour mes serveurs ? »).
Pour la sécurité, cela est assez similaire, l’énergie doit être concentrée sur le « quoi » plutôt sur le « comment » qui doit être ainsi entièrement automatisé. Les équipes de sécurité vont devoir suivre ce mouvement pour analyser et détecter rapidement les failles de sécurité.
Les éléments clés pour adapter la sécurité à la mouvance DevOps
- Un monitoring continu, à travers un dashboard commun : il est nécessaire de suivre en temps réel l’état de l’application grâce à des indicateurs communs de performance et de disponibilité et non plus uniquement sur l’état du CPU et de la RAM. Ce qui permet aux équipes de parler le même langage.
- Des environnements IaaS ou PaaS : des Datacenter virtuels permettent une consommation à la demande et pilotable par API pour automatiser les process. Cela permet de faire grossir sa plate-forme à la demande et donc d’éviter les périodes d’indisponibilité pour cause de charge trop importante et non anticipée.
- Une gestion centralisée de la configuration : des outils de centralisation de la configuration des systèmes et des applications permettent d’avoir une vision de la plate-forme complète en un coup d’œil. La sécurité doit être évaluée pour ne pas permettre à n’importe qui d’avoir accès à des informations sensibles. Cependant, cela apporte de nouvelles possibilités, comme le fait qu’un administrateur sécurité puisse auditer la configuration de la plate-forme sans avoir à accéder aux serveurs.
- Une intégration continue : l’automatisation de l’intégration (test du code des développeurs à la volée) permet de bénéficier d’une information en temps réel sur la qualité du code et sur sa sécurité. Les reports sont ainsi directement visibles par les développeurs qui peuvent corriger la faille de sécurité avant même qu’elle ne soit poussée en production et détectée par un test de pénétration.
Vers la fin de la pré-production ?
Avec ces nouveaux outils et cette automatisation, la question de la fin des environnements de pré-production se pose légitimement. En effet, la pré-production est un environnement coûteux à mettre en place, qui nécessite des ressources pour le maintenir et qui possède toujours des différences avec la production. Grâce
– À l’intégration continue qui permet d’avoir une validation de la qualité et de la sécurité du code dès la phase de développement,
– Au déploiement continu sur des micro-releases qui permet de pousser du code en production en quelques secondes et d’effectuer un rollback en aussi peu de temps,
– À du monitoring applicatif qui permet d’avoir une vision en temps réel sur la santé des applications, le besoin d’une pré-production devient de plus en plus faible et est remplacé par des tests en temps reel avec une maîtrise des risques. Cela peut sembler effrayant, mais certaines entreprises ont déjà sauté le pas…
Téléchargez cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre dossier Green IT sur les actions engagés par inmac wstore pour réduire son impact environnemental