Les applications lourdes sur chaque poste de travail, les applications d'entreprises non visibles de l'extérieur sans oublier les systèmes embarqués existent et je pense que l'ensemble surpasse ce que tu décris en quantité.
Les applications lourdes sur poste de travail c'est justement ce que je développe. Et la plupart se connectent à un serveur SQL à l'extérieur. D'autres se connectent en SSH pour déposer des documents via SFTP. D'autres encore récupèrent des documents via http.
Celles qui sont non visibles de l'extérieur ne risquent pas de compromission depuis l'extérieur, mais elles en risquent quand même depuis l'intérieur.
Des ordinateurs en entreprises qui ont des fonctions très minimalistes et sans accès au net, il y en a une armée dans la nature.
Ben ce que je constate chez mes clients (ça n'a pas valeur d'universalité on est bien d'accord), c'est justement qu'il n'y en a plus beaucoup et que d'années en années, il y en a de moins en moins.
Ils utilisent aussi une machine à café, un lave linge ou lave vaisselle, une télé ou un téléphone
Les 3 premiers n'ont pas (pas encore plutôt) de prise réseau, la sécurité n'a pas d'importance donc. Pour les 2 derniers, si ils sont connectés ils rejoignent mon cas général. Une télé connectée avec un vieux serveur UPNP doit pouvoir être compromise pour rejoindre un botnet par exemple.
Tu sais que les banques et assurances, ces grosses structure, ont beaucoup de code écrit en COBOL ? Tu sais, ce langage hyper moderne et probablement hyper sécurisé.
C'est pas le langage qui implique la sécurisation. Leur COBOL tourne probablement sur un noyau écrit en C qui n'est pas non plus le langage considéré comme le plus sécurisé, et alors ? Une des vraies solutions pour la sécurité, c'est d'être à jour. C'est sûr, il y a les 0 day, c'est pas une solution absolue, mais pas être à jour c'est courir à la catastrophe.
Pour beaucoup de services la coupure peut coûter plus cher que de laisser tourner malgré les failles (cela dépend évidemment de ce que fait l'application et la machine hein).
Ok pour ça.
Ce qui me gène dans ces technos (je ne nie pas leur intérêt dans certains cas) c'est que j'ai l'impression de les retrouver de plus en plus dans ce que j'appelle le cas général. Et dans ce cas précis, la balance avantages / inconvénients d'un unique dépôt centralisé des dépendances est meilleure que celle des images qui embarquent leurs dépendances.
Mais on ne peut pas en l'état actuel des choses garantir la même sécurité à l'application de la banque et de ta lampe connectée
Le problème c'est qu'elles sont sur le même réseau. Il va bien falloir trouver une solution sinon l'avenir est bien sombre.
[^] # Re: Dockerfiles
Posté par guppy . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 2.
Les applications lourdes sur poste de travail c'est justement ce que je développe. Et la plupart se connectent à un serveur SQL à l'extérieur. D'autres se connectent en SSH pour déposer des documents via SFTP. D'autres encore récupèrent des documents via http.
Celles qui sont non visibles de l'extérieur ne risquent pas de compromission depuis l'extérieur, mais elles en risquent quand même depuis l'intérieur.
Ben ce que je constate chez mes clients (ça n'a pas valeur d'universalité on est bien d'accord), c'est justement qu'il n'y en a plus beaucoup et que d'années en années, il y en a de moins en moins.
Les 3 premiers n'ont pas (pas encore plutôt) de prise réseau, la sécurité n'a pas d'importance donc. Pour les 2 derniers, si ils sont connectés ils rejoignent mon cas général. Une télé connectée avec un vieux serveur UPNP doit pouvoir être compromise pour rejoindre un botnet par exemple.
C'est pas le langage qui implique la sécurisation. Leur COBOL tourne probablement sur un noyau écrit en C qui n'est pas non plus le langage considéré comme le plus sécurisé, et alors ? Une des vraies solutions pour la sécurité, c'est d'être à jour. C'est sûr, il y a les 0 day, c'est pas une solution absolue, mais pas être à jour c'est courir à la catastrophe.
Ok pour ça.
Ce qui me gène dans ces technos (je ne nie pas leur intérêt dans certains cas) c'est que j'ai l'impression de les retrouver de plus en plus dans ce que j'appelle le cas général. Et dans ce cas précis, la balance avantages / inconvénients d'un unique dépôt centralisé des dépendances est meilleure que celle des images qui embarquent leurs dépendances.
Le problème c'est qu'elles sont sur le même réseau. Il va bien falloir trouver une solution sinon l'avenir est bien sombre.