IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les conteneurs du DevOps présentent-ils des risques pour la sécurité de vos données ?
Oui, selon une étude

Le , par Bill Fassinou

423PARTAGES

13  0 
À l’heure où la méthode de travail DevOps semble gagner toutes les entreprises technologiques, de nombreux professionnels ont commencé à s’inquiéter sur la sécurité des conteneurs souvent préférés pour leur flexibilité et leur agilité. L’un des éléments clés dans la mise en œuvre du DevOps est la technologie des conteneurs. Les conteneurs sont de plus en plus mis en œuvre par les entreprises. Le DevOps est un mouvement en ingénierie informatique et une pratique technique visant à l'unification du développement logiciel (dev) et de l'administration des infrastructures informatiques (ops), notamment, l’administration système.

Apparu courant de 2010, le mouvement DevOps se caractérise principalement par la promotion de l’automation et du suivi (monitoring) de toutes les étapes de la création d'un logiciel, depuis le développement, l'intégration, les tests, la livraison jusqu'au déploiement, l'exploitation et la maintenance des infrastructures. Les principes DevOps soutiennent des cycles de développement plus courts, une augmentation de la fréquence des déploiements et des livraisons continues pour une meilleure atteinte des objectifs économiques de l'entreprise. La virtualisation à base de conteneurs est une méthode de virtualisation dans laquelle la couche de virtualisation s'exécute au sein même du système d’exploitation.

Dans cette approche, le noyau du système d'exploitation hôte exécute directement plusieurs machines virtuelles invitées et autonomes sans passer par une couche logicielle supplémentaire. Ces machines invitées s'appellent des conteneurs. Les conteneurs permettent donc de s'affranchir des hyperviseurs et de la gestion qui découle de l'exécution sur chaque machine virtuelle d'un système d’exploitation invité. Cette approche permet d'améliorer les performances, puisqu'un seul et unique système d'exploitation (l'hôte) se charge des appels matériels. Elle permet également d'héberger sur un serveur beaucoup plus d'instances virtualisées que la virtualisation traditionnelle.

Cette technologie est depuis quelques années très utilisée par de grandes firmes telles que Google, BlaBlacar, etc. L’un des plus connus de ces conteneurs est Docker (il s'agit d'un conteneur Linux). Cette façon de faire est très répandue aujourd’hui dans le monde technologique. Mais la technologie des conteneurs garantit-elle une sécurité optimale pour les ressources des entreprises ?


Une récente étude de Tripwire, une agence de cybersécurité, révèle que 60 % des entreprises ont subi un incident lié à la sécurité des conteneurs en 2018. Les résultats de l’étude publiés le 7 janvier dernier indiquent que les entreprises qui ont adopté le DevOps feront certainement face à des défis importants et des risques liés à la sécurité de leurs conteneurs. Pour Tripwire, si ces entreprises veulent minimiser les risques et leur exposition aux menaces numériques, elles devront penser à des solutions immédiates pour sécuriser leurs conteneurs.

Tripwire a procédé à l’interrogation d’environ 311 professionnels de la sécurité informatique qui gèrent des environnements avec des conteneurs dans beaucoup d’entreprises et les réponses étaient pour la plupart inquiétantes. D’abord, 60 % ont confirmé avoir subi quelques problèmes concernant la sécurisation et le déploiement de leurs conteneurs. L’étude de Tripwire fait ressortir que pour la majorité des entreprises dont il est question, plus le nombre de conteneurs en production augmente, plus les risques de sécurité augmentent.

« 86 % des organisations interrogées avaient des conteneurs en production au moment de l'étude. Plus il y avait de conteneurs dans la production, plus il était probable qu'ils subissent un incident lié à la sécurité des conteneurs. Parmi les entreprises comptant plus de 100 conteneurs en production, 75% avaient subi un incident lié à la sécurité. Il n’est donc pas étonnant que 94% des répondants se disent préoccupés par la sécurité des conteneurs. Soixante et onze pour cent des personnes allaient jusqu'à prédire que le nombre d'incidents liés à la sécurité des conteneurs augmenterait au cours de la prochaine cette année », indique Tripwire.

Selon Tripwire, si de tels risques planent sur les installations de ces entreprises, cela peut être la conséquence directe de leur manque d’expérience ou leur immaturité dans la mise en œuvre du DevOps. L’étude rapporte à ce sujet que beaucoup d’entreprises dans le lot traînent encore des lacunes dans leurs stratégies actuelles pour sécuriser leurs conteneurs. Par exemple, lit-on dans le rapport, à peine 12 % des répondants au sondage ont déclaré pouvoir détecter un conteneur compromis en quelques minutes. Quarante-cinq pour cent des participants au sondage ont déclaré que cela prendrait des heures, alors que certains estimaient que cela prendrait encore plus longtemps. Dans le même temps, près de la moitié (47 %) des professionnels de la sécurité informatique ont déclaré que leurs entreprises fabriquaient des conteneurs vulnérables, tandis que presque le même nombre (46 %) ont déclaré ne pas savoir avec certitude si c'était le cas.

Bon nombre de ces entreprises limitent pour ce fait leurs déploiements de DevOps pour parer certains risques de sécurité, indiquent les résultats de l’étude. Elles veulent toutes pouvoir acquérir de nouveaux environnements offrant bien plus de sécurité. « Avec la croissance et l'adoption de conteneurs, les entreprises sentent la pression pour accélérer leur déploiement. Pour faire face à la demande, les équipes acceptent les risques en ne sécurisant pas les conteneurs. Sur la base de cette étude, nous pouvons constater que le résultat est que la majorité des organisations sont confrontées à des incidents de sécurité des conteneurs », a expliqué Tim Erlin, vice-président chargé de la gestion des produits et de la stratégie chez Tripwire.

Source : Tripwire

Et vous ?

Disposez-vous d’un déploiement de conteneurs pour votre entreprise ? Comment assurez-vous leurs sécurités ?

Voir aussi

Les cinq étapes de l'évolution DevOps identifiées par le state of devops 2018, présentées par Puppet et Splunk

Azure DevOps : Microsoft annonce le successeur de Visual Studio Team Services et un service d'intégration et déploiement continus intégrés à GitHub

Le « DevOps » et le développeur « FullStack » mettraient en danger le métier de développeur le constat inquiétant de Jeff Knupp

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de micka132
Expert confirmé https://www.developpez.com
Le 05/07/2022 à 9:19
Citation Envoyé par grunk Voir le message
Par contre écrire un script pour mettre en oeuvre ce qu'à préparer les ops ca on sait faire , souvent plus efficacement que les ops.
Avec cette phrase tu résumes le phénomène. Les "ops" ne sont que les "sys admin" de la décennie précédente.
Et comme dans la décennie précédente, tu as les gars dans les petites boites qui font tout (dev/exploitation/support/qualité) et au plus tu vas dans de grosse boite au plus les activités sont dissociées. Cette mouvance "devops" est initiée par des gars de grosse structure qui voulait ressentir le coté touche à tout de la petite boite.
Mais le réel c'est que passer le fun d'apprendre des trucs avec des tutos, ça reste bien plus efficace d'avoir des "spécialistes".

Moralité: si vous voulez faire du vrai devops il faut aller dans une petite structure.
10  0 
Avatar de Eric80
Membre éclairé https://www.developpez.com
Le 02/07/2022 à 0:15
le job d un ingénieur moderne est d automatiser des tâches, cad de faire travailler des machines plutôt que des humains.
Avec DevOps, il s agit donc de supprimer les équipes opérationnelles et de demander aux développeurs de les remplacer par des outils automatisés. Sauf que ces outils sont souvent frustrants à utiliser pour les développeurs car comme dit l auteur, les outils sont d abord penser pour la partie opérationnelle et sont pas aussi mature que les IDE pour la partie développement des scripts.
Prenez par ex les pipelines CI/CD sur Gitlab ou AzureDevOps: ce sont les outils de base pour déployer automatiquement les composants logiciels écrits par les équipes de développeurs. Mais on demande à ces mêmes développeurs d'écrire aussi les scripts de ces pipelines, qui peuvent vite devenir très complexe dans un environnement entreprise: une ligne de code d un script yaml est autrement plus "coûteuse" (en terme de temps) qu'un bloc de code en java, JS ou autre car on ne peut pas débugger notre code si facilement.
(bais cognitif du moment: cela fait des semaines que je me prends la tête sur les "rules" dans des pipelines imbriquées sur Gitlab)
6  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 17/01/2019 à 15:42
Bonjour,

Il est évident que si on intègre la sécurité dès le début, celle-ci est moins cher à mettre en œuvre, plus facile à intégrer, et souvent plus robuste.

Après, ce qu'il faut mettre en balance dans cette étude, c'est que le problème de sécurité n'est pas lié aux conteneurs ou aux processus DevOps, mais à un manque de sécurité dans les procesus. Autrement dit, si n'importe quoi d'autre aurait été utilisé pour faire ce déploiement, les problèmes de sécurité auraient été là également.

On commence de plus en plus à intégrer la sécurité dès le début des processus, mais on part de tellement bas qu'il reste énormément de chemin à parcourir.
2  0 
Avatar de Mingolito
Membre extrêmement actif https://www.developpez.com
Le 04/07/2022 à 16:45
C'est Devops qui est un échec, ou alors les baltringues qui sont censés faire appliquer cette méthode ?

T'es nul en programmation ? T'es nul en informatique ? T'es nul en management de projet ? Hop devient "Devops" après quelques semaines de formation merdique dans une école privée pourrie avec des profs nuls voir absents, ou alors lis un "tuto" sur Youtube, et devient grassement payé à ne rien foudre en travaillant seulement en vrai 1 h par jour pour pondre des rapports à la con qui servent à rien

La théorie sur ce que ça devrait être :



Le résultat sur le terrain en pratique dans les faits :



6  4 
Avatar de grunk
Modérateur https://www.developpez.com
Le 04/07/2022 à 21:36
Citation Envoyé par Eric80 Voir le message
le job d un ingénieur moderne est d automatiser des tâches, cad de faire travailler des machines plutôt que des humains.
Avec DevOps, il s agit donc de supprimer les équipes opérationnelles et de demander aux développeurs de les remplacer par des outils automatisés. Sauf que ces outils sont souvent frustrants à utiliser pour les développeurs car comme dit l auteur, les outils sont d abord penser pour la partie opérationnelle et sont pas aussi mature que les IDE pour la partie développement des scripts.
Prenez par ex les pipelines CI/CD sur Gitlab ou AzureDevOps: ce sont les outils de base pour déployer automatiquement les composants logiciels écrits par les équipes de développeurs. Mais on demande à ces mêmes développeurs d'écrire aussi les scripts de ces pipelines, qui peuvent vite devenir très complexe dans un environnement entreprise: une ligne de code d un script yaml est autrement plus "coûteuse" (en terme de temps) qu'un bloc de code en java, JS ou autre car on ne peut pas débugger notre code si facilement.
(bais cognitif du moment: cela fait des semaines que je me prends la tête sur les "rules" dans des pipelines imbriquées sur Gitlab)
Rien ne t'empêche d'écrire un yaml ultra minimal qui va ensuite aller exécuter des scripts écrits dans le langage que tu veux.

Le but de devops c'est pas de supprimer les équipes opérationnelles , mais de supprimer la friction entre les dev et les ops. L'ops ca reste un vrai métier pour lequel les dév on rarement de l'intérêt et quand c'est le cas il leur manque souvent de la connaissance pour faire les choses bien (exemple).
Par contre écrire un script pour mettre en oeuvre ce qu'à préparer les ops ca on sait faire , souvent plus efficacement que les ops.
3  1 
Avatar de smarties
Expert confirmé https://www.developpez.com
Le 14/07/2022 à 10:56
Citation Envoyé par TJ1985 Voir le message
Problèmes de riches. "De mon temps", même dans des structures importantes, un développeur était responsable de son produit de a..z. Accessoirement, c'étaient les développeurs internes qui développaient l'environnement d'exploitation et l'environnement de développement, afin d'offrir une gestion de sources et de versions homogènes, une gestion multi-plateformes des mises en production, etc.
Ça, c'était dès 1990. Ensuite, on a voulu des spécialistes, car un spécialiste, c'est spécialisé et le "chef de projet consultant" aura toujours beau jeu de le renvoyer à sa spécialité lorsque lui-même sera menacé d'avoir démontré son inutilité.
La situation a commencé à sérieusement se dégrader lorsque les méthodes dites agiles sont apparues. L'aspect sectaire et messianique des séances était frappant, leur inefficacité aussi. Mais comme on avait payé très cher le super consultant venu mettre tout ça en place, il n'était pas question de revenir en arrière. Alors on a engagé, car c'est bien connu : Quand un projet prend du retard, doublez les effectifs, ça ira mieux (je plaisante).
Bref. J'ai l'impression qu'aujourd'hui beaucoup de gens dépensent une énergie folle à faire une informatique qui ne soit plus de l'informatique mais de la gestion administrative, tout en s'affublant de titres inflationnistes.
Mais dans le fond, si vous voulez livrer quelque chose qui facilite la vie de votre client, un compilateur (multi-plateformes), un SGBDR, de bonnes librairies, du temps, un peu de talent valent beaucoup mieux qu'une équipe de fashionistas déversant leur glose récemment apprise en prenant l'air d'avoir inventé la poudre qui pète deux fois.
Dans les années 90 il n'y avait pas autant d'outils qu'aujourd'hui et d'environnements cloud. De plus on voit ce que ça donne le code legacy :
- souvent peu de documentation
- les personnes qui les ont développés sont parties
- chacun programmait à sa façon
- parfois obliger de coder des fonctionnalités qui sont devenues standards dans les autres langages/frameworks
- peu de tests

Quand les outils de gestions de version sont arrivés cela a apporté un confort et de nouvelles règles.
Je trouve que ça s'est complexifié quand les solutions cloud sont arrivée : avant on installait un serveur de A à Z mais maintenant on doit apprendre un nouvel environnement à chaque fois que l'on change d’hébergeur cloud.
Avant on avait des petits scripts pour la compilation et le déploiement (ou ce dernier point était fait manuellement) mais maintenant on a intégrer des outils d'analyse de code, des automatisation de tests, des règles pour les pull requests donc de nouveaux outils à connaître.
Enfin, on a des délais courts pour le développement donc il est plus facile de déléguer à des spécialistes plutôt que de passer plusieurs jours pour automatiser le déploiement ou autre.
2  0 
Avatar de Astraya
Membre chevronné https://www.developpez.com
Le 08/07/2022 à 8:25
Citation Envoyé par redcurve Voir le message
Perso mes Yaml ne font que lancer des scripts powershell et ce pour Windows, Linux et Macos grace à Powershell core https://github.com/powershell/powershell .
Je suis heureux de pas être le seul pour ma part c'est un exécutable. Net Core que je peux aussi tester sur ma machine
1  0 
Avatar de redcurve
Membre extrêmement actif https://www.developpez.com
Le 08/07/2022 à 9:24
Citation Envoyé par Astraya Voir le message
Je suis heureux de pas être le seul pour ma part c'est un exécutable. Net Core que je peux aussi tester sur ma machine
Franchemen je n'ai pas touché Bash depuis 3 ans et je dois dire que ça ne me manque pas
1  0 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 13/07/2022 à 12:16
Mon point de vue sur DEVOPS c'était surtout de "professionnaliser" ce qui tourne autour du dev sans être du dev pur. En effet, le focus étant souvent mis sur le dev pur que le reste, le reste est mal maîtrisé au sens gestion, mal budgété, et en plus mal maîtrisé techniquement par les développeur, résultant plus souvent dans des résultats relativement "amateur".

Car le fait est que la plupart des développeurs peuvent écrire quelques script d'auto déploiement qui marcherons a peu près. Mais pour avoir un truc nickel, surtout dans le cas d'un client lourd par exemple, il y a une marche qui distingue bien un truc plus "amateur" qu'un truc "pro" fait par les gens plus du système généralement.

Dans les exemples :
  • Mis à jour automatiques des applications, mais aussi upgrade des composant de serveur/bdd.
  • Regénération des certificats SSL nécessaires pour avoir une plateforme validation qu'on teste en HTTPS.
  • Gestion des comptes utilisateurs, de l'AD, des trucs SSO (kerberos, SAML, CAS, ,...),...
  • Pipelines CI (bon j'ai pas chez moi ça )
  • ...


Quand on voit ça, j'ai aucun doute qu'une bonne partie peuvent ce dire "bon je vais galérer mais ça va globalement passer", ben oui, sauf que régulièrement y'a quand même un truc qui pète et le temps de trouvé tu prend deux jours.
1  0 
Avatar de smarties
Expert confirmé https://www.developpez.com
Le 05/07/2022 à 11:40
Citation Envoyé par grunk Voir le message
Le but de devops c'est pas de supprimer les équipes opérationnelles , mais de supprimer la friction entre les dev et les ops. L'ops ca reste un vrai métier pour lequel les dév on rarement de l'intérêt et quand c'est le cas il leur manque souvent de la connaissance pour faire les choses bien (exemple).
C'est en effet ce qui arrive quand on embauche des développeurs sur du DevOps.
En tant que développeur, quand je vois la stack technique sur la partie dev (souvent back-end avec la connaissance du front ) et qu'en plus ça demande des compétences CI/CD et Cloud dans les offres d'emploi, ce n'est pas étonnant que la production soit mal configurée. Certe, on a des connaissances et des compétences sur la partie DevOps mais on deviendra rarement un expert DevOps si on n'est pas à plein temps dessus.
Personnellement, je me contente au quotidien de :
- 1-2 langages de programmation avec 1-2 framework par langage
- docker pour la conteneurisation et effectuer des tests
- un serveur Linux et Ansible pour le déploiement de la solution en production
- nginx pour configurer le serveur web

La partie CI/CD je passerais du temps si je dois mettre ça en place
0  0