Sujet intéressant ! Les mentions légales de ce site sont ici.
https://www.service-public.fr/professionnels-entreprises/vosdroits/F31228
Que dit la loi ? https://www.cnil.fr/fr/cookies-traceurs-que-dit-la-loi
Voir aussi https://github.com/LINCnil/CookieViz/releases pour les cookies !
Cloud Act est l’acronyme de Clarifying Lawful Overseas Use of Data Act. Trop forts ces ricains pour les acronymes (presque aussi bien que Patriot Act). A l’instar du Patriot Act, ou dans le même esprit que le RGPD, il devrait permettre une collaboration plus facile dans les requêtes judiciaires.
Continuer la lectureLe terme objets connectés me semble plus approprié que l‘internet des objets, qui prend les choses dans le mauvais sens en partant d’internet pour arriver aux objets, et qui est également trop limitatif car le vrai enjeu n’est pas tant d’être sur internet que d’être relié à d’autres objets.
Le ‘S’ dans IOT c’est pour « Sécurité ».
Blague anonyme
Les objets connectés existent depuis longtemps, sur l’échelle de temps informatique. Un ordinateur ou un serveur informatique étant des objets, il y a belle lurette que la connexion est faite. Le vrai changement est qu’en suivant la vague de miniaturisation et de banalisation des composants informatiques, on peut désormais coller partout ces composants, jusque dans votre pacemaker12, permettant notamment des fonctions évoluées mais aussi de la communication avec d’autres objets, sur internet ou pas.
Cela concourt selon moi à rendre ces objets menaçants, car comme souvent toujours en informatique, la sécurité n’a été abordée qu’après coup, car le bénéfice immédiat (réel) a souvent coupé court à toute autre réflexion.
Difficile de penser qu’on arrivera facilement à un niveau de sécurité acceptable dans le monde des objets connectés, car la multiplicité des acteurs3 et leur féroce concurrence commerciale, le manque de culture sécurité et le coût nécessaires à cette sécurisation sont des freins puissants sur le chemin de cet objectif. Quant aux mauvaises habitudes, elles perdurent et les mots de passe par défaut continueront à nous jouer des tours, jusqu’à transformer un aspirateur45 en espion (puisque les aspirateurs automatiques ont des caméras pour se diriger).
Que n’ai-je entendu que j’étais un râleur patenté, un pessimiste né, un rétrograde primaire, tout ça parce que je pestais (et peste encore) contre l’innovation bête et stupide, ainsi que sa glorification béate (toute comme pour les start-up) sans prise de conscience de l’ensemble des enjeux liés à ladite innovation.
A partir du moment où votre aspirateur5 devient un objet connecté, attendez vous au pire. Toute caméra peut devenir un espion potentiel. Donc tout objet connecté, même anodin, peut recueillir (et donc transmettre) plein d’informations vous concernant, et à l’ère du big data, l’utilisation qu’on peut en faire est quasiment infinie.
Des chercheurs ont même réussi à transformer un aspirateur-robot en centre d’écoute : ils ont détourné l’usage du « lidar » (le radar dont se sert le robot pour se déplacer) pour capter les vibrations sonores sur les surfaces rencontrées6, et en déduire les conversations. Seul élément rassurant : vous parlez beaucoup, quand l’aspirateur marche ?
Cela fait beaucoup moins rire de parler du danger des connexions dans les avions que pour les réfrigérateurs : autant un frigo qui envoie du spam ou qui commande une pizza, cela prête à sourire, autant la perspective d’un avion qui s’écrase fait froid dans le dos. Or dans objets connectés il y a aussi avions connectés. Et le département de la sécurité intérieure aux Etats-Unis nous dit que ce n’est qu’une question de temps7 avant qu’un avion ne soit piraté, avec les conséquences catastrophiques que l’on peut imaginer. Ils ont réussi à la faire avec un Boeing 737, on peut voir une analyse de risque ici.
Entre les scooters électriques (ou les vélos) en libre-service qu’il faut suivre pour leur entretien, ou les voitures se conduisant toutes seules, les interactions informatiques sont forcément très nombreuses. Donc récolte de données à gogo8 et réutilisation par toujours contrôlée, surtout en cas de faille.
Un autre exemple ? Volontiers : les trottinettes Xiami M365 peuvent être (au moins partiellement) contrôlées par un pirate9, qui peut agir sur le freinage ou l’accélération avec les conséquences qu’on peut imaginer.
Parfois on trouve des failles non seulement dans les objets connectés, mais aussi dans les centrales électroniques censées les contrôler. En gros, si par extraordinaire vous utilisez un objet connecté non troué (= non vulnérable), alors il faudra vérifier que votre hub10 soit également bien protégé.
Puisqu’il est si facile de prendre le contrôle d’un grand nombre de machines informatiques reliées à internet, les objets connectés sont tout naturellement d’excellents candidats pour construire un réseau de machines zombies (botnet). Et les méchants ne s’en privent pas. Les objets connectés piratables, zombifiables et contrôlables à souhait sont du pain béni pour les attaques de type DDoS (déni de service) ; Mirai en a été le premier exemple marquant.
Les conséquences juridiques sont difficiles à appréhender à l’émergence d’une nouvelle technologie (ou de son expansion). Or, tout comme la sécurité, les aspects juridiques sont trop souvent négligés11, et ça n’est qu’au moment d’une catastrophe, d’une attaque ou d’un litige qu’on se rend compte qu’on ne maîtrise ni la situation technique ni les conséquences juridiques (et judiciaires) de cette technologie.
Étonnamment, malgré des alertes renouvelées et argumentées, malgré des compromissions, les fabricants d’objets connectés continuent leur déni12 et la situation ne s’améliore absolument pas. En cause, toujours les mêmes facteurs :
Une étude de Palo Alto Networks13 enfonce le clou : sur le million d’objets connectés étudiés, 98% des flux réseaux circulent en clair, avec les risques de fuite d’information et de détournement associés, 57% sont vulnérables à des attaques ayant des impacts moyens ou élevés, dans l’industrie et les milieux hospitaliers, les objets vulnérables sont sur les mêmes VLAN que les dispositifs traditionnels, les mots de passe sont majoritairement faibles voire encore triviaux, etc.
The Internet of Things is a security nightmare reveals latest real-world analysis: unencrypted traffic, network crossover, vulnerable OSes
Sources
theregister.co.uk
Une autre étude de Zscaler14 est moins pessimiste, mais pas plus rassurante pour autant : seules 17% des « transactions » sont chiffrées. Cela s’explique probablement par un panel d’étude différent, avec d’autres usages et donc d’autres types de machines, mais ça reste pas beaucoup…
La défense semble une posture normale pour tout entité, vivante ou organisationnelle. Il va de soi qu’un Etat va chercher à se défendre et à défendre ses concitoyens, tout comme n’importe quel individu. L’attaque dépend d’autres facteurs, et cette capacité a longtemps eu une place à part en informatique, car cela a toujours été considéré comme l’apanage des méchants. L’informatique était considérée comme un outil de production, qu’il fallait protéger et garder en état de marche.
Or dans la vraie vie, l’attaque fait partie de la stratégie des individus comme des nations, et les capacités offensives commencent à se faire jour. De plus, avec l’importance croissante de l’informatique dans la richesse et les capacités de production (parfois vitales) des pays, elle devient aussi une cible stratégique.
Je ne parle pas des nord-coréens qui ne pensent qu’à détruire cette méchante Amérique qui fait rien que les embêter. Je parle de ce que la cyberguerre est désormais une réalité si tangible qu’elle est l’objet de discussion et même d’un projet de traité au sein des Nations-Unies.
Or il semble que le sujet soit si sensible que treize années de négociations n’ont pas pu aboutir1. Point de traité donc, notamment parce que certains pays souhaitent que le cyberespace reste en dehors des conflits et que sa militarisation (c’est-à-dire la définition de ce que serait une attaque et une réponse dans ce cybermonde) risquerait de conduire à de réels conflits armés2.
L’intention est évidemment bonne, mais l’effet ne sera-t-il pas au contraire une escalade des conflits dans cet espace au mépris de toute règle ? Les attaques informatiques peuvent avoir un impact économique (et donc humain) majeur, et l’absence de principes ou de contrôles pourrait tout au contraire exacerber les tensions et conduire également à de vrais conflits militaires. L’Europe a relancé une action3 pour tenter de formaliser tout ça afin de stabiliser le cyberespace, mais il est difficile de savoir sur quoi cela va aboutir.
Oui : on estime que seuls deux états avaient des capacités offensives en 2007, et ils seraient une trentaine en 2017. Les activités quasi-militaires prennent tant d’importance que l’ONU s’en inquiète et propose d’instaurer une sorte de code de bonne conduite via un cadre légal4, qui risque cependant d’être très difficile à faire respecter s’il venait à voir le jour.
Historiquement, les Etats-Unis, la Chine et la Russie font partie des nations ayant une forte activité (en attaque comme en défense). Mais certains pays émergents profitent de la demande pour proposer des services d’attaque et de compromission, de type APT : l’Iran et le Vietnam commencent à se faire une réputation dans ce domaine5.
On dirait : à l’aube des élections présidentielles russes de 2018, les Etats-Unis accusent ouvertement la Russie6 d’avoir perturbé le fonctionnement des réseaux énergétiques (et d’autres choses7) via une attaque informatique, avec des mesures de rétorsion diplomatiques notables8 en retour. Il semble acquis (en août 2018) que des pirates910 ont bel et bien réussi à pénétrer un réseau pouvant agir sur la distribution d’électricité, mais sans n’avoir rien déclenché11 (ou perturbé).
Ce qu’il y a de nouveau ne sont pas les conséquences dans les relations internationales mais l’outil employé pour peser dans ces relations : l’informatique. Les attaques sont désormais tellement structurées et les conséquences tellement visibles que les attaques informatiques constituent un moyen de pression mais aussi un moyen d’action contre ses ennemis.
En août 2017, une usine pétrochimique située en Arabie Saoudite aurait été visée par un programme malveillant dont le but aurait été une destruction physique12 d’installations de cette usine. La complexité de l’attaque est telle qu’il est peut probable qu’elle soit le fait d’un petit groupe isolé : les auteurs avaient de l’information, du temps, et de moyens. L’attaque n’a échoué qu’à cause d’une seule une erreur dans le code.
En janvier 2017, d’autres structures d’Arabie Saoudite avaient été touchées par un programme ayant effacé une grande partie des disques durs touchés. Une attaque qui rappelle celle ayant eu lieu cinq ans plus tôt (le 15 août 2012) où les 3/4 des disques durs ont été effacés13, ce qui était une des attaques les plus marquantes de l’époque en raison justement de cette destruction physique de données.
En juin 2018, des observateurs ont noté une baisse notables des attaques d’un groupe supposé nord-coréen (Covellite14) vers des cibles américaines. Curieusement, cela correspond à une période de réchauffement des relations15 entre les deux pays, au moment où rencontre entre Potus (@potus est le compte twitter du President Of The United States [of America]) ) et Kim Jong Un (le leader nord-coréen) est prévue.
En 2010, une corvette militaire sud-coréenne a été coulée (incident de Baengnyeong). Récemment, des analystes ont émis l’hypothèse que des cyberattaquants nord-coréens auraient tenté à de nombreuses reprises de compromettre le service météo sud-coréen16 afin de prévoir la route de patrouille empruntée par la corvette.
Les accusations contre la Russie qui compromettrait des installations industrielles continuent à fleurir au début de l’année 2018 (presque autant que des fuites d’informations sur AWS S3).
Comme on peut. Que ce soit contre la manipulation, ou contre les pirates soutenus par des Etats, les grands acteurs de l’informatique se liguent et s’unissent pour protéger nos intérêts. Ou les leurs. Ou les deux. Tous les grands noms y sont, sauf Apple, Amazon et Google. Ne me demandez pas pourquoi.
En 2019, il n’y a plus guère de doutes sur les tentatives de manipulation des élections américaines de 2016, au point qu’on sait désormais qu’il y a eu des mesures de rétorsion17 sur « l’usine à trolls » russe, aboutissant à la destruction de données (via un contrôleur RAID a priori).
Application, gestion des fichiers
Just like files that you save on the device’s internal storage, Android stores your database in private disk space that’s associated application. Your data is secure, because by default this area is not accessible to other applications.
Cependant, si on ne suit pas les bonnes pratiques, notamment lors du stockage de données sur des supports externes à l’OS (genre carte SD), les données deviennent vite accessibles pour des intrus1.
Une des choses que je reproche le plus à Android est la fragmentation des versions de l’OS, ce qui se comprend par la difficulté d’intégration de tous les acteurs (fabricants de composants et puces, fabricants de smartphones, opérateurs téléphoniques) qui devaient chacun revoir leur copie à chaque mise à jour d’Android, ce qui fait que beaucoup traînaient les pieds ou ne le faisaient carrément pas. Or un OS viable est un OS à jour !
Depuis Android 8.0, toutes les parties spécifiques que les acteurs précédents devaient modifier a été séparée (logiquement) de l’OS. L’avantage indéniable de la manœuvre est de laisser le code spécifique à part, sans avoir besoin de le retravailler2. Il « suffit » donc de mettre à jour l’OS, pour un téléphone donné, afin d’avoir les derniers correctifs : le travail est du côté de Google, pas des acteurs intervenant par la suite (fondeurs de puces, constructeurs de téléphone et opérateurs).
Une autre option pour avoir un système à jour est justement de n’utiliser aucune personnalisation du téléphone, en respectant certains critères documentés par Google3. Au final, on aura un téléphone moins personnalisé (personnellement ça m’importe peu) mais surtout suivant (ou plutôt : pouvant suivre) les mises-à-jour Android sans aucun souci.
Google propose même de labelliser les téléphones respectant les critères Android One ; et je ne vois pas l’intérêt qu’aurait un constructeur à s’embêter à être Android One pour ne pas suivre le train des mises-à-jour de l’OS !
La récente salve de francisation de termes informatiques n’a pas fait que des heureux. Plusieurs voix se sont élevées contre l’institutionnalisation de fait de termes abscons, comme darkweb et deepweb dont l’existence même prête à polémique.
Autant un portail de messagerie (« webmail ») est un concept clair pour tous, autant les notions d’internet clandestin (« darkweb ») ou de toile profonde (« deepweb ») n’ont pas de réalité si tangible que ce qu’on veut bien nous faire croire.
Le Larousse nous apprend que clandestin peut signifier « qui se cache » mais aussi « qui contrevient à la loi ou qui se dérobe au contrôle ». Cela peut tout à fait s’appliquer à l’internet de Mme Michu, car nombre de sites web d’accès public contreviennent allègrement à plusieurs lois françaises : tel site d’un journal people qui reprend des clichés violant la vie privée de personnalités, tel autre qui diffuse de annonces liées à des escroqueries diverses (la bague qui guérit tout, le gain assuré au loto, l’augmentation de volume de [ce qu’on veut], la promesse de gains mirobolifiques sur des marchés financiers qu’on cache être extrêmement risqués), la vente d’armes sur Facebook ou Instagram, etc.
Par ailleurs, se dérober au contrôle est parfois une mesure salutaire notamment dans les pays (grands ou petits) où la censure sévit et où la clandestinité est la seule option permettant de vivre (ou survivre). Aller sur l’onionland ou utiliser des VPN est nécessaire à certains.
D’après S. Bortzmeyer, la définition correcte de deepweb serait :
Concept débile, peu ou pas défini, flou, et qui ne sert qu’aux politiciens et journalistes sensationnalistes.
La définition officiellement retenue est :
Partie de la toile qui n’est pas accessible aux internautes au moyen des moteurs de recherche usuels.
Ce qui est sans aucun rapport avec la notion qu’on veut mettre dans ce deepweb peuplé uniquement de méchants qui se cachent pour comploter, car il y a un tas de raisons pour lesquelles les moteurs de recherche n’indexent pas : je prenais le cas d’un portail de messagerie, dont la quasi-totalité du contenu n’est accessible qu’à un utilisateur authentifié (et donc inaccessible aux moteurs de recherche). Ce portail de messagerie serait donc à classer dans le deepweb. Or consulter ce deepweb vous expose directement à l’excommunication ou à des poursuites pénales, bien entendu. Idem pour tous les sites utilisant un fichier robots.txt.
J’avoue moi-même ne plus bien réussir à faire la différence entre ces deux notions, tant elles sont floues. Une distinction plus simple et plus claire serait peut-être de parler d’activités légales ou d’activités illégales sur internet, quels que soient les moyens employés, puisqu’on peut vendre de la drogue sur l’internet « classique » et tenter de sauver sa famille sur l’internet « clandestin ». Toutefois, le darkweb désigne plus généralement :
Réseau accessible uniquement via des outils spécifiques, comme le navigateur Tor.
Après, Tor ou Freenet ne sont pas vraiment des réseaux séparés, puisqu’ils utilisent l’infrastructure d’internet. On parle de réseaux « overlays », qui se superposent sur des réseaux existants.
Internet n’est qu’une sorte de reflet des activités humaines : les truands se cachent, sauf parfois pour escroquer les gens ou faire leur business. Et les gens normaux sont parfois tentés d’être discrets pour de bonnes raisons. Le darkweb sera d’ailleurs peut-être la dernière solution pour tenter de garder un soupçon de vie privée.
The Dark Web Boundaries Are Not Always Clear, and Many Sites Fall in a Gray Area
Idan Aharoni on SecurityWeek.com
GnuPG est un système de chiffrement (ou cryptosystème) indépendant des grands acteurs de la sécurité et de la surveillance (lesquels se confondent parfois). Il se base sur l’utilisation de clés de chiffrement asymétriques, ce qui permet de les échanger plus facilement.
Ça sert à masquer vos très chères données à nos très chers GAFA et autres acteurs du web et de l’internet. Accessoirement, Mme Michu ne pourra pas non plus lire ce que vous échangez avec vos correspondants.
En gros, vous créez une paire de clés de chiffrement qui vous seront associée à vous personnellement. Un des clés sera publique, l’autre sera privée ; elles vous permettront de chiffrer vos données ou vos mails. La clé publique pourra et devra être diffusée partout, et la clé privée devra rester secrète et donc, au contraire, être la plus cachée possible. Le gros inconvénient est que lorsqu’on perd sa clé privée, et bien c’est foutu, ça marche plus ! Il n’y a plus qu’à en recréer une, et diffuser la nouvelle clé auprès de vos correspondants, car il n’existe aucun moyen de la récupérer.
Sur les systèmes Linux, les outils nécessaires sont généralement installés par défaut. Après, le plus important est de stocker la clé privée en lieu sûr. La première opération à réaliser est la génération d’une paire de clés avec la commande --gen-key :
gpg --gen-keyOn aura besoin durant cette procédure de disposer d’une quantité d’aléa (ou entropie) suffisante. Afin de voir l’entropie disponible sur un système Linux, on peut utiliser la commande suivante1 :
watch cat /proc/sys/kernel/random/entropy_availS’il vous en manque, il peut être judicieux d’utiliser le package rng-tools (sur Ubuntu).
apt-get install -y rng-toolsPour générer un peu d’entropie supplémentaire, on peut utiliser la commande suivante :
/usr/sbin/rngd -r /dev/urandomLa seconde mesure consiste à générer un certificat de révocation pour toute une nouvelle paire de clés. La raison de procéder ainsi est qu’il vous faut disposer de la clé privée pour générer son certificat de révocation. Générer le certificat de révocation le plus tôt possible vous met à l’abri de l’oubli de votre clef. Vous devrez bien sûr conserver ce certificat à l’abri. En outre, il doit rester facile et rapide de révoquer une clé, en cas de compromission.
Pour chiffrer :
gpg -e destinataire [message]Pour déchiffrer :
gpg [-d] [message]Pour signer et chiffrer un message, la syntaxe complète est :
gpg [-u expéditeur] [-r destinataire] [--armor] --sign --encrypt [message]On peut faire un chouïa plus simple, pour signer un message avec l’identité par défaut de votre trousseau de clé :
gpg --sign|--clearsign|--detach-sign [message]L’option --sign vous construit un fichier .gpg illisible, --clearsign produit un fichier au format texte avec le contenu en clair suivi de la signature, et enfin --detach-sign ne fournit que la signature dans un fichier .sig. Ajoutez l’option --armor pour avoir un fichier signature en clair, suffixé par .asc. Si vous prenez l’option --clearsign, cela vous construira un fichier de type :
root@rasp-janiko:/jean/test# cat essai.txt.asc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ceci est un test.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJV+WSgAAoJEN+s4kEe3i4xT6AH/RlkQZyQQ5XkdGmIQGgk8H6h
C8zK7/RO1XzzP4xyqA59yHfgPgwGJ9PASaaUlOHgLcIbbiTRTrow8ZIPNhBdF4fC
gEvZfu9p27X6SXXRa/94Lt1uIHDVFhtzWf9YNoytToxRSIf/CvPpTXcHPbnYP7YD
Gwdz+Qxz8u2vhKJKLk4uXHgJb97IvsgoSfpb7e7TMMqCRIKV2S6T1LyouW+Tyy1Y
ZerF5rGIWle2rYVQoM5ujuM77q/XaxAZyGQ7fp5rndBSVMBWptK5W9k8Ji4vhCqa
FqhVdzTvq+DwmsjigCUtLk9uxSdqBhNQ+xb3sSRlyXG1PmnQtigXlUnUs/wBVds=
=t6tc
-----END PGP SIGNATURE----- Pour vérifier la signature, il suffit de taper :
gpg --verify [message]Si tout va bien, vous aurez :
root@rasp-janiko:/jean/test# gpg --verify essai.txt.asc
gpg: Signature faite le mer. 16 sept. 2015 14:46:24 CEST avec la clef RSA d'identifiant 1EDE2E31
gpg: Bonne signature de « Jean GEBAROWSKI (statodynamicien) <jean@geba.fr> » </jean@geba.fr>Et si la signature est mauvaise ou que le fichier est modifié :
root@rasp-janiko:/jean/test# gpg --verify essai.txt.asc
gpg: Signature faite le mer. 16 sept. 2015 14:46:24 CEST avec la clef RSA d'identifiant 1EDE2E31
gpg: MAUVAISE signature de « Jean GEBAROWSKI (statodynamicien) <jean@geba.fr> » </jean@geba.fr>Comme toujours, ça ne sert à rien d’utiliser des moyens sûrs si on ne vérifie pas leur validité. Quand on reçoit une alerte sur un certificat, il ne faut pas cliquer sur OK sans réfléchir. Pour les clés PGP, on a vu des tentatives d’usurpation reposant sur l’identifiant court (ou short id), qui peut parfois être dupliqué ! Donc en utilisant et/ou important des clés, il ne faut pas de limiter à cet identifiant mais aussi vérifier l’adresse mail23…
Le réseau SKS Keyserver (Synchronizing Key Server) a été historiquement le principal système de distribution des clés publiques. Le réseau SKS est en déclin (relatif) car il est vulnérable à des attaques comme l’empoisonnement de clés (« key poisoning »). On a, par exemple :
Sinon vous pouvez vous tourner vers :
Pour importer une clé :
gpg --keyserver hkps://keys.openpgp.org --recv-keysUne faille a été découverte en mai 20184 dans de nombreux outils de messagerie ou dans leurs plugins mettant en oeuvre PGP et S/MIME. Il s’agirait plus d’une mauvaise implémentation de ces protocoles dans les clients de messagerie que d’autre chose, mais le résultat est le même : il y a danger, même sil l’exploitation n’est pas triviale5.
Le seul conseil pour l’instant est de désactiver le déchiffrement automatique des messages dans les clients de messagerie concernés (tels que Outlook, Thunderbird, Apple Mail, etc.) en supprimant les clés qui y sont stockés, et de désactiver l’affichage HTML. Le déchiffrement ne doit être effectué que dans une application tierce, jusqu’à production du correctif.
Une autre faille a été mise au jour en juin 20186 permettant d’usurper n’importe quelle signature, ce qui est gênant. La version 2.2.8 de GnuPG corrige le tir de cette anomalie qui existait depuis très longtemps, apparemment !
La confiance n’exclut pas le contrôle, dit-on souvent. Il existe d’excellents outils pour évaluer la sécurité et la robustesse d’un serveur proposant une communication SSL.
Pour ma part, je recommande SSLScan, dont il existe plusieurs variantes. En fouillant un peu, celle qui me semble la plus pertinente est celle de rbsec, car elle est à peu près à jour (elle intègre les versions 1.1 et 1.2 de TLS), et ne mixe pas les technologies puisqu’il s’agit uniquement d’un programme en langage C. Ca permet d’éviter de trop nombreuses dépendances, et ça évite de cumuler les vulnérabilités de multiples technologies (bien que cet aspect puisse être débattu).
Kubernetes, ou k8s pour les intimes, est un orchestrateur. On pourrait dire parmi tant d’autres, vus qu’ils fleurissent pour nous aider à tout faire, mais pas tant que ça : il tend de facto à devenir un standard, ou tout du moins l’outil le plus utilisé dans son genre.
C’est de déployer une application sur des nœuds. Dis comme ça, ça ne casse pas des briques. Mais disons que c’est un outil (initialement créé par Google mais open source depuis quelques temps) qui dispose d’une certaine puissance et surtout une grande maturité dans son domaine, ce qui est plutôt rare dans le monde si animé du DevOps.
En gros nous avons les grands constituants suivants :
Le rôle de Kubernetes est de déployer un système (une application) selon les spécifications qu’on lui donne, et de le maintenir dans l’état voulu. Cet état peut être défini grâce au mécanisme Replication Controller, qui se met en place par un simple fichier YAML. On peut par exemple indiquer que l’on souhaite 10 ou 20 instances d’un même pod, et que cet état soit maintenu dans le temps.
En résumé, et en image (source wikipedia) :
Un composant est très intéressant : etcd, qui est une base de type clé/valeur (noSQL pour ceux qui aiment ré-inventer la roue), et qui sert de base référentielle persistante pour le master.
L’ensemble du paramétrage d’une application se fait via des fichiers de type manifest, ou bordereau de livraison, au format YAML ou JSON.
Le pod est l’unité la plus intéressante dans Kubernetes, car c’est l’unité qu’on manipule, qu’on construit, et qui sert effectivement à produire le service demandé. Un pod peut contenir plusieurs conteneurs : ainsi un pod peut intégrer tous les services nécessaires à un fonctionnement intègre et autonome, ce qui peut toujours être utile ou plus pratique en termes d’architecture.
Points notables :
C’est donc un peu plus conséquent en termes de fonctionnalités qu’un simple conteneur, mais cela reste en dessous du niveau d’une machine virtuelle. D’ailleurs, un pod ne peut pas être scindé, c’est-à-dire déployé par morceaux sur plusieurs noeuds : il est installé sur un et un seul noeud. Et lorsqu’il meurt, on ne relance pas un pod : on en recrée (refabrique) un nouveau, identique, mais qui n’est pas le pod précédent : il n’y a aucune persistance de pod. Le pod est donc un simple mortel, et non un phénix renaissant de ses cendres.
Comme vu ci-dessus, un service est une abstraction d’une fonctionnalité mise en oeuvre par un ensemble de pods. Un service est caractérisé par une adresse IP fixe, un nom, et un port interne et un port exposé (si besoin). Un service peut être de différents types :
Le port interne doit être le même que celui du service mis en oeuvre au niveau du pod (il n’y a pas de translation au niveau du port, mais uniquement au niveau de l’adresse IP).
Ainsi on ne se préoccupe plus du détail de l’instanciation des pods : le service trouve et regroupe les pods réalisant le service (par exemple via des labels qu’on assigne aux pods) et permet d’avoir un point d’entrée unique et stable au service (via une API REST) et même permet un équilibrage de charge.
C’est le stade ultime dans une architecture Kubernetes : on y gère la mise-à-jour (et le retour arrière), les différents Replicas Sets, de façon à initier l’application ou à la faire monter de version proprement.
Euh… non. Pas bien, en tout cas. En dehors des mécanismes basiques genre TLS qui ne servent qu’au transport, un secret est difficile à protéger au sein d’un déploiement Kubernetes1. Il est possible de gérer des secrets partagés au sein d’un cluster, mais in fine les informations sont stockées en clair2 (ou quasiment, je crois que c’est en base64) dans etcd, qui est l’outil de stockage utilisé par Kubernetes (cf plus haut).
Il ne faut donc pas compter sur le mécanisme par défaut pour une gestion sécurisée des secrets, notamment dans un environnement mutualisé comme le cloud. Dans l’avenir, il sera peut-être possible que ces valeurs secrètes soient stockées correctement chiffrées, mais pour l’instant c’est expérimental3. Les seules solutions fonctionnant en pratique sont d’utiliser les gestionnaires de clés ou les HSM des fournisseurs (AWS, Azure, Google) ou un vault comme celui d’HashiCorp4. Vous ne maîtriserez donc pas totalement vos clés, ce qui peut être un obstacle dans les environnements où la conformité importe.
Pour apprendre le fonctionnement de Kubernetes, le meilleur moyen sera d’installer MiniKube, un tout-en-un qui tient sur une seule machine mais qui permet d’apprendre les principes. Le support le plus à jour se trouve sur github :
Il y a plusieurs prérequis, dont celui d’avoir installé un outil de virtualisation genre VirtualBox. Il faut aussi avoir installé kubectl.
Tout en ligne de commande !
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
$ chmod +x ./kubectl
$ sudo mv ./kubectl /usr/local/bin/kubectl
$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
Il n’y a aussi qu’à recopier les binaires. Pour des questions pratiques, il faut ajouter le chemin d’installation dans le paramètre PATH de Windows, ce qui peut aussi être fait via un installateur pour MiniKube (en version bêta).
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.9.0/bin/windows/amd64/kubectl.exe
Le lien est https://storage.googleapis.com/minikube/releases/latest/minikube-windows-amd64.exe.
$ minikube start
La cryptologie est la science de l’écriture secrète, comprenant la cryptographie (technique de chiffrement de message) et la cryptanalyse (technique de déchiffrement d’un message).
La stéganographie est la dissimulation du message sur un support d’apparence anodine (une tablette gravée puis recouverte de cire, le crâne rasé du messager qui laissera ensuite repousser ses cheveux, etc.).
La transposition consiste en la permutation de lettres, sans en changer la valeur, comme dans un anagramme. Le secret réside dans le choix de la transposition :
La substitution est le remplacement d’une lettre par un autre caractère, sans modifier sa position. Il en existe différentes formes
Les débuts de cryptanalyse sont liées à l’évolution des mathématiques, des statistiques et de la linguistique. Les premiers principes furent appliqués pour ordonner chronologiquement les chapitres du Coran, en fonction de la fréquence d’usage de mots modernes par exemple. L’analyse des fréquences d’usage des lettres fut également étudié.
Longtemps considéré comme sûr, il reste vulnérable à l’analyse des fréquences, pourvu que le texte chiffré soit assez long et la clé relativement courte : si la clé fait 5 caractères de long, on se retrouve finalement face à 5 substitutions monoalphabétiques (car la clé se répète de façon cyclique lors du chiffrement), d’où on peut conjecturer les lettres les plus fréquentes.
Il faut toutefois connaître la longueur de la clé ; or on peut la déduire de l’espacement des séquences de lettres répétées dans le texte chiffré (là encore si le texte est assez long), qui sera probablement le plus grand diviseur commun des espacements entre les séquences répétées.
Vigénère était plus robuste que tout chiffrement monoalphabétique, mais restait sensible à l’analyse des fréquences. Les Américains eurent l’idée d’une clé de la longueur du message pour utiliser Vigénère : l’analyse de fréquence devient alors impossible si la clé est suffisamment aléatoire, puisque qu’il n’y a aucune répétition prévisible. Il fut finalisé par la major Mauborgne, d’après les travaux de Vernam qui donna son nom au système (« chiffre de Vernam »).
Théoriquement incassable, il est malheureusement très difficile d’emploi :
Son usage sur un champ de bataille est rendu quasi-impossible par la nécessité que tous les points de communications doivent avoir le même livre de chiffres (non compromis) et le temps nécessaire au chiffrement et déchiffrement aurait nécessité un travail colossal.
Son usage restera en pratique limité à quelques communications ultra-confidentielles, de fréquence modérée, avec un échange de clés (de livre de chiffres) bien sécurisé.
Voir l’article dédié à l’informatique quantique.
Fiche de lecture : 2253150975 / 978-2253150978