Le biais du survivant est une tendance à se concentrer uniquement sur les exemples qui ont survécu à un événement, en ignorant ceux qui ont échoué. En matière de cybersécurité, cela signifie que les entreprises ont souvent tendance à se baser uniquement sur les incidents de sécurité passés qui ont été résolus, sans prendre en compte ceux qui ont échappé à leur détection ou n'ont pas été correctement résolus.
L'un des exemples les plus connus est celui des avions durant la seconde guerre mondiale:
En étudiant les dommages causés à des aéronefs revenus de mission, l'étude a recommandé de blinder les endroits des appareils qui présentaient le moins de dommages. En effet, Wald a constaté que les études précédentes ne tenaient compte que des aéronefs qui avaient « survécu » à leur mission, sans tenir compte de ceux qui avaient disparu. Ainsi, les endroits endommagés des aéronefs revenus représentent les endroits où ces derniers peuvent encaisser des dommages et réussir à rentrer à la base.
L'idée est donc de dire que les incidents que l'on voit ne sont pas forcément les plus importants, et qu'il peut être pertinent de se focaliser sur ce que l'on ne voit pas.
Les limites de l'apprentissage à partir des incidents passés
Apprendre de ses erreurs est sans doute l'étape la plus importante d'un incident, qu'il soit lié à la sécurité ou non. Durant l'étape du post-mortem, le focus est souvent mis sur la raison de l'incident, et comment éviter sa reproduction et le monitorer.
Toutefois, les attaques et les menaces évoluent constamment, de nouvelles vulnérabilités sont découvertes et les attaquants utilisent des tactiques de plus en plus sophistiquées. Se baser uniquement sur les incidents passés peut donc conduire à des lacunes dans la préparation à de nouvelles menaces.
Par exemple, une entreprise peut se concentrer uniquement sur les types d'attaques qui ont été précédemment détectées et résolues, tandis que de nouvelles méthodes d'attaque peuvent être utilisées sans être détectées. Cela peut entraîner une fausse confiance en matière de sécurité, car les attaquants peuvent exploiter les vulnérabilités non prises en compte pour causer des dommages importants.
Détecter des attaques est une étape cruciale de la surveillance d'un système d'information, toutefois, il est aussi très important de garder en tête qu'il y a toujours la possibilité de vulnérabilité qui n'ont pas encore été identifiée.
On se rappellera par exemple de WannaCry en 2017. Le ver était resté en sommeil pendant une longue période avant de s'activer et verrouiller énormément de systèmes, provoquant même l'arrêt de certaines entreprises.
En se basant uniquement sur les incidents visibles, de nombreuses entreprises ont donc été durement impacté par cette attaques.
La proactivité : l'arme de la cybersécurité
Il est essentiel d'adopter une approche proactive en matière de cybersécurité, plutôt que de simplement se fier aux incidents passés pour prendre des décisions. Cela peut inclure la surveillance continue des réseaux, la détection proactive des menaces, la formation des employés à la sensibilisation à la sécurité, ainsi que la mise en œuvre de mesures de sécurité appropriées pour protéger les systèmes et les données.
Une approche proactive implique également de reconnaître les limites de l'apprentissage à partir des incidents passés et de ne pas se fier uniquement à cette approche pour évaluer les risques de cybersécurité. Il est important de rester informé des nouvelles menaces, de mettre à jour régulièrement les systèmes et les logiciels, de réaliser des évaluations de sécurité régulières et de former continuellement les employés sur les meilleures pratiques en matière de sécurité.
La cybersécurité est une veille continue qui doit permettre de rester en permanence au courant des dernières attaques, des derniers vecteurs, des dernières vulnérabilités. Regarder uniquement le passé n'est pas (ou plus) suffisant, il faut être en mesure de préparer les futures attaques, identifier les failles avant qu'elles soient activement exploitées, surveiller, monitorer.
J'en avais parlé dans le passé, mais l'arme principale d'un hacker est sa capacité à identifier rapidement des failles, mais aussi à penser différemment, à exploiter ce qui peut passer pour des détails.
Il est aussi important d'être au courant des derniers modèle d'attaques, il existe pour ca de nombreux site et flux RSS.
En France, nous avons notamment le CERT-FR, qui publie nombre de bulletin de sécurité avec énormément d'informations pertinentes.
A noter qu'il existe aussi un flux RSS intégrable facilement sur des outils comme Slack par exemple.
Le site de l'ANSSI regorge aussi d'information utiles sur les bonnes pratiques pour prévenir autant que possible les incidents de sécurité.
Enfin, un détail souvent oublié : il est crucial de former ses effectifs, surtout les équipes techniques (Développeurs, Ops, etc.) afin qu'ils soient conscient des risques liés à la sécurité et puissent les prendre en compte dans leurs réalisations.
Pour terminer
Le biais du survivant peut être un piège dans le domaine de la cybersécurité, car il peut amener les entreprise à se baser uniquement sur les incidents passés résolus, en ignorant les menaces potentielles persistantes. Il est essentiel de reconnaître les limites de l'apprentissage à partir des incidents passés et d'adopter une approche proactive pour protéger les systèmes et les données.
Il est important de rester informé des nouvelles menaces, de mettre en place des mesures de sécurité appropriées et de former continuellement les employés à la sécurité. La cybersécurité est un processus continu qui nécessite une vigilance constante pour protéger les actifs numériques d'une entreprise. En adoptant une approche proactive, elles peuvent ainsi mieux se préparer aux nouvelles menaces et réduire les risques de cyberattaques.
Oui, je sais, j'arrive après la bataille sur ChatGPT!
Pour une raison simple, j'aime me faire un avis et ne pas suivre aveuglément les modes dans la Tech, surtout que lesdites modes ont tendance à passer bien vite, on se rappelle (ou pas) de nua.ge qui a fait un grand coup de com' à coup de vouchers chez des "influenceurs" et a disparu des ondes aussi vite qu'il est apparu.
Bref, revenons à nos moutons! ChatGPT va remplacer les métiers de l'IT, c'est ce que j'ai lu pas mal de fois ces derniers temps, disant que nous serons relégués à de simples exécutants de requêtes sur ChatGPT.
Bon, qu'on se le dise, on a encore un peu de temps devant nous, mais nous allons voir tout ça en détail.
ChatGPT, c'est quoi ?
Commençons par les bases, ChatGPT est le dernier-né de l'entreprise OpenAI. L'objectif de cette entreprise est de promouvoir l'intelligence artificielle en l'"humanisant" autant que possible.
Les usages de l'intelligence artificielle au quotidien pourraient améliorer le quotidien de beaucoup d'utilisateurs.
Attention, on parle bien d'un modèle d'IA, de l'IA tout court, ça fait trèèèèèès longtemps qu'on en voit en informatique, de simples "if" sont déjà une forme d'intelligence, aussi basique soit-elle.
ChatGPT est donc le dernier jouet d'OpenAI, ce dernier est un modèle de conversation textuelle humain. C'est-à-dire qu'il est capable de comprendre ce qu'on lui dit, mais aussi de répondre de manière "naturelle", comme le ferait un être humain.
Il s'agit donc avant tout d'un modèle entrainé pour comprendre les demandes et répondre de manière cohérente. ChatGPT ne "sait" rien, il compile des informations qu'il a obtenues de multiples sources publiques.
Cela signifie aussi que cette IA a les mêmes biais que les humains. Il y a quelques années, c'était Amazon qui en avait fait les frais, avec son IA d'aide au recrutement sexiste et raciste... parce qu'elle était entrainée par les comportements des recruteurs d'Amazon!
Un article très complet en parle d'ailleurs ici (en anglais) :
Maintenant, est-ce que ce code est utilisable et fiable à 100% out of the box? C'est un sujet plus compliqué.
Ce qui fait la valeur d'un développeur en entreprise n'est pas forcément sa capacité à délivrer beaucoup de code, ou à connaitre par cœur toutes les documentations, c'est sa capacité à s'adapter et à délivrer ce qui est attendu par son entreprise.
Cette capacité à raisonner et chercher la solution la plus adaptée n'est pas forcément innée chez ChatGPT.
Cela signifie par exemple que le code de base possède souvent de nombreuses duplications par exemple (peu de factorisation de code par défaut), il peut parfois être inutilement complexe pour un besoin simple aussi.
De même, étant donné que le modèle a été entrainé via des données publiques, toutes les données ne se valent pas. Je ne pense pas que ce soit une surprise si je dis que l'ensemble des données trouvées sur Internet ne sont pas de la même qualité.
Pour ma part, j'ai fait quelques tests simples avec l'outil, et quand des tests simples ont produit du code correct, dès lors qu'on commence à demander des spécificités, ChatGPT s'emmêle les pinceaux et arrive parfois à des contradictions dans ses réponses.
Une fois de plus, l'œil critique humain est nécessaire pour évaluer la qualité des réponses.
ChatGPT : Un outil parmi d'autres
Est-ce que je dois croire aveuglément ce que me remonte un SIEM, ce qu'une analyse de code statique me donne ?
La réponse est bien sûr non. En ce qui concerne ChatGPT, c'est la même chose, il s'agit d'un outil avant tout.
Est-ce qu'il permet d'aider à délivrer du contenu : oui, dans certaines conditions, mais comme tous les outils, il a ses limites, dont certaines que j'ai décrites plus haut.
En tant que tel, il faut le considérer comme un outil qui peut accélérer potentiellement les choses, mais en restant critique sur ses réponses, tout comme vous le seriez avec un quelconque parseur.
Si le résultat peut parfois être bluffant, cela reste un algorithme, raisonnant sur un modèle connu et limité. Le but premier de ChatGPT n'est pas le code, mais la discussion naturelle, et c'est sur ce domaine qu'il est plutôt bon.
Ainsi, pour obtenir des résultats précis, il faut parfois guider l'IA pour qu'elle produise ce qu'on veut, voici un petit exemple que je me suis amusé à faire
Test de code avec ChatGPT
De plus, je reste dubitatif sur certaines réponses, si le modèle est indiqué comme "coupé d'Internet à la fin 2021", il semble avoir reçu des mises à jour "manuelles", comme ici, où il parvient à m'indiquer qu'Elon Musk est le PDG de Twitter, alors qu'il ne l'est que depuis octobre 2022.
Donc ChatGPT sait qu'Elon Musk est le PDG de Twitter?
On notera d'ailleurs que ChatGPT botte en touche quand on insiste sur la source de ses données.
En insistant un peu
En conclusion : ne mettez pas encore à jour votre CV
Je pense que vous l'avez compris, je pense que ChatGPT est un bon outil, qui est assez bluffant, mais je suis encore confiant sur le fait que nos métiers (dans l'IT) vont perdurer encore un moment.
Actuellement, ce modèle d'IA est limité sur beaucoup d'aspects, et surtout donne toujours raison à l'humain, même quand il a tort! J'ai ainsi réussi à faire dire à ChatGPT que 2+2 faisait 5 en lui disant qu'il avait tort en me répondant 4.
2+2=5, tout va bien
À noter que ChatGPT est basé sur GPT3, et que GPT4 est en cours de développement, promettant des possibilités énormément plus grandes!
L'amélioration de l'intelligence va bien entendu modifier notre manière de travailler, mais pour l'instant, j'imagine mal une entreprise pouvant se passer entièrement d'équipes en les remplaçant par GPT. Peut-être que l'avenir me donnera tort, mais je suis plutôt confiant.
Depuis quelques jours, suite au rachat de Twitter par Elon Musk, on entend beaucoup parler de Mastodon. Certains se disent prêts à migrer de Twitter vers Mastodon, si nombre de billets de blog parlent de Mastodon vs Twitter du point de vue fonctionnel, on parle assez peu des aspects liés à la sécurité. Ici, je ne vous parlerais pas de modération, de changements d'habitude, etc. simplement de mon point de vue lié à la sécurité.
Mastodon : comprendre le modèle décentralisé
Au contraire de Twitter, Mastodon utilise un modèle décentralisé.
Ce dernier permet d'avoir de multiples instances qui communiquent entre elles via un protocole commun.
Cela permet de ne pas nécessiter que l'ensemble des utilisateurs soit sur la même instance pour se suivre, réagir ou liker des "pouets" (l'équivalent des tweets).
Pour en savoir plus sur le sujet, je vous conseille l'excellent article sur le blog de Framasoft :
Vous l'aurez compris, nous avons déjà un premier "point faible", du a un principe que j'ai déjà abordé dans d'autres billets dans le passé : le tiers de confiance.
L'un des principaux défauts de Mastodon est aussi sa force. La décentralisation empêche une politique de sécurité commune à l'ensemble des instances. Cela signifie donc que l'on confie des données potentiellement confidentielles et/ou sensibles à un tiers. Tout dépend de l'importance que l'on attache aux dites informations, mais par exemple votre adresse mail peut potentiellement être exploitée par un administrateur malveillant ou une instance compromise. Cela signifie aussi que d'une instance à l'autre, vous pouvez avoir différents niveaux de gestions de données sensibles. Pour certains, il sera impossible aux modérateurs d'accéder aux données "personnelles", pour d'autres, ça sera open bar.
Modification du code
J'ai vu en boucle "Mastodon est open source, tu n'as qu'à voir le code si tu veux voir [choisir la feature sécurité]". Oui et non, tout comme VSCode n'est pas l'exact contenu du repository open source, ce n'est pas parce qu'un système est basé sur de l'open source qu'il est déployé tel quel. Au contraire, vu que le code est ouvert, il est d'autant plus facile pour quelqu'un de malveillant de le modifier pour en faire ce qu'il veut. Ainsi, rien ne m'empêche techniquement de modifier le code de mastodon pour qu'il stocke les mots de passe en clair, m'envoie une copie de tous les MP par mails ou envoyer des messages en me faisant passer pour quelqu'un d'autre.
Phishing
Le côté décentralisé facilite aussi un autre aspect : le phishing. En effet, étant donné qu'il n'y a pas de domaine prédéfini, rien ne m'empêche de mettre une page de création de comptes "fake". Ainsi je peux récupérer pas mal d'informations sensibles, notamment les mots de passe. En effet, si dans l'IT, nous sommes plus sensibilisés que d'autres sur la réutilisation de mot de passe, ce n'est pas le cas d'une grande partie de la population qui recycle ses mots de passe d'application en application.
De cette manière, je peux facilement tester un mot de passe que j'ai récupéré sur d'autres sites web pour en prendre le contrôle ou exfiltrer nombre d'informations.
L'infrastructure et le patching
Une fois de plus, étant donné que la solution est hébergée par un tiers, il est nécessaire de s'assurer que l'infrastructure qui héberge la solution est assez sécurisée. En effet, la moindre brique non sécurisée est un vecteur d'attaque. Tous les jours des dizaines de CVE (Common Vulnerabilities and Exposures) sont trouvées des produits, y compris des failles zéro day (faille inconnue non patchées), il est donc nécessaire d'avoir une veille de la part de l'hébergeur pour mettre à jour rapidement ses briques à chaque faille découverte, ainsi qu'une surveillance sur son infrastructure pour être à même de détecter et réagir à tout comportement anormal ou inhabituel.
Et twitter dans tout ça ?
On pourrait croire que je vais dire que Twitter est sécurisé, mais c'est faux. Dans le passé, il y a eu de multiples hacks de Twitter, j'avais même parlé du dernier dans un billet sur ce blog.
Toutefois, des mécanismes de protection dus au fonctionnement même d'une entreprise assurent un niveau de sécurité plus élevé, qui est potentiellement audité. Twitter doit se conformer à de nombreux impératifs de sécurité de par sa taille et le fait qu'elle doit rassurer son public.
Ça reste tout de même une boite noire sur laquelle, de mon côté, je ne peux pas vous assurer que tout est à 100% sécurisé.
En conclusion : on oublie Mastodon ?
On pourrait croire que je dise qu'il faut donc s'enfuir loin de Mastodon avec ce que je viens de dire, mais c'est faux! Comme à chaque fois que vous confiez vos données personnelles, il est important d'être conscient de la sécurisation de celles-ci.
Mastodon reste un outil open source très puissant qui dans certains modèles peut rivaliser avec Twitter.
Toutefois, son côté décentralisé le place aussi potentiellement en position de faiblesse quand on s'attarde sur la sécurité.
N'hésitez pas à réagir dans les commentaires pour donner votre avis!
Comme souvent sur ce genre de billet, je tiens à rappeler que le contenu que vous trouverez ici l'est uniquement à des fins pédagogiques.
L'intrusion non autorisée dans un système d'information est passible d'amende et/ou d'emprisonnement.
Comprendre les attaques, c'est savoir comment les éviter. Dans ce billet, je vous propose de voir un modèle d'attaque réseau courant : l'ARP poisoning.
L'ARP, c'est quoi ?
Pour comprendre l'attaque, il faut déjà comprendre sur quoi elle repose.
Pour l'ARP, nous repartirons donc du modèle OSI, décrivant les différentes couches du réseau.
Source : Wikipédia
L'ARP est le lien entre la couche 2 et 3, c'est ce qui va permettre à un ordinateur ou serveur de convertir une adresse IP en adresse matérielle (MAC).
Pour fonctionner, l'ARP utilise un système de broadcast. Chaque périphérique sur le réseau envoie globalement à l'ensemble dudit réseau son adresse IP associée à son adresse matérielle.
Vous pouvez facilement accéder et modifier cette table avec la commande arp -a (que ce soit sous Linux ou Windows).
Exemple d'affichage de la table ARP
La faiblesse de ce protocole
Je pense que vous avez déjà localisé le point faible : chaque nœud envoie l'information, et rien ne permet de contrôler la véracité de celle-ci.
Ainsi, je peux très bien annoncer mon adresse MAC comme correspondant à l'IP du routeur.
Chaque nœud (ou les nœuds ciblés) sur mon réseau recevra donc cette information et mettre à jour sa table ARP avec la correspondance.
Comment se passe l'attaque?
Il y a un prérequis, être sur le même réseau que sa cible.
Ensuite l'idée consiste à se mettre entre la cible et le routeur. Cela permettra donc de lancer une attaque de type "Man in the middle" pour capturer tout le trafic réseau entre ma cible et le routeur.
Pour l'exemple que je vais prendre ci-dessous, je vais partir de mon propre réseau, et je vais me mettre entre mon PC et ma Livebox.
Pour ce faire, je vais donc envoyer deux informations différentes.
Depuis mon PC attaquant, je vais indiquer à ma livebox que je suis le PC de la victime.
À ma victime, je vais dire que je suis la livebox. De cette manière, cela me permet d'avoir les deux flux d'informations qui transit au travers de mon PC d'attaque, en me positionnant de la même manière qu'un proxy.
Un avant/après de l'attaque
L'attaque en détail
Prérequis
Comme je l'ai décrit plus haut, je vais donc avoir besoin de plusieurs choses pour procéder à mon attaque :
Un accès au même réseau que ma cible
Un PC avec différents outils (que je décrirais plus bas)
L'IP de ma cible, même si je peux m'en passer, comme nous le verrons
Dans le cas de ce billet, je vais utiliser deux machines virtuelles "Lab" :
Mon attaquant sera une VM utilisant Kali Linux
Ma cible sera un VM sous Windows 10
Détecter le PC Windows
Pour effectuer mon attaque, je vais utiliser le populaire bettercap.
Ce dernier va me fournir l'ensemble des outils dont j'ai besoin pour détecter les périphériques sur mon réseau et procéder à l'ARP poisoning.
Je vais donc le démarrer avec la commande ci-dessous :
bettercap -iface eth0
Bettercap fonctionne avec des modules, configurables et exécutables. Je ne rentrerais pas dans les détails des modules ici, et je vous invite à consulter la documentation associée pour plus de détails.
Si nécessaire vous pouvez utiliser la commande help pour voir les commandes et modules disponibles ainsi que leurs statuts.
Dans un premier temps, nous allons utiliser le module "net.probe".
Comme son nom l'indique, ce dernier va nous permettre de détecter les périphériques sur le réseau.
net.probe on
net.show
On retrouve bien ma cible ci-dessous, qui n'est autre que l'IP 192.168.109.130
Commençons à s'amuser
Maintenant nous allons lancer l'attaque sur la table ARP de la cible.
Avant de commencer, je vais juste capturer la table de ma cible.
Table ARP de ma cible
Le plus important ici est l'IP 192.168.109.2 qui correspond à l'IP de mon routeur virtuel.
Depuis ma VM Kali, toujours dans bettercap, je vais donc passer à l'offensive!
set arp.spoof.fullduplex true #Indique de lancer l'attaque sur la cible et sur le routeur
set arp.spoof.targets 192.168.109.130 #Indique l'IP de la cible
arp.spoof on #Lance l'attaque
La première ligne est importante, car elle va permettre de lancer directement l'attaque des deux côtés.
À noter que certains routeurs sont protégés contre les attaques ARP. Dans ce cas, nous ne verrons que les trames sortir de la cible, mais pas le retour, ce qui limite les attaques.
Si je regarde la table ARP de ma cible maintenant, nous verrons que l'IP du routeur n'est plus la même!
Au passage, on notera qu'elle a maintenant la même adresse MAC que ma VM Kali 192.168.109.129.
Maintenant je suis capable de voir le trafic entrant et sortant de ce PC avec un simple net.sniff on
Qu'est-ce que ça m'apporte à ce point ?
Arrivé là, je suis capable de capturer l'ensemble du trafic non chiffré sortant du PC de ma victime.
Cela signifie que je peux voir :
Les appels en HTTP
Les requêtes DNS non chiffrées
Les requêtes SNI
C'est tout naze, on voit que le HTTP
Beaucoup diront que cela correspond à une faible partie du réseau. C'est vrai et faux à la fois.
Si je suis dans une entreprise, beaucoup considèrent qu'il n'est pas nécessaire de mettre du chiffrement pour les endpoints internes par exemple, cela permet donc de potentiellement capturer beaucoup de trafic.
De même savoir sur quel site un utilisateur va me permet potentiellement de cibler une attaque, que ce soit du phishing ou du social engineering.
Enfin, il faut voir cette partie comme une première étape, en effet, une fois que je suis positionné en man in the middle cela me permet aussi d'altérer le trafic pour modifier ce que voit ma victime, mais nous verrons ce point dans un autre billet!
En conclusion, méfiez-vous de TOUS les réseaux
Le but de ce billet est de rappeler qu'un attaquant n'est pas forcément externe, même dans votre réseau d'entreprise il est possible de faire pas mal de dégâts.
L'ARP spoofing fait partie des points qui sont normalement couverts par la plupart des routeurs d'entreprise, mais pas tous. Il est important de s'en protéger.
La plupart des routeurs grand public ne proposent pas de protections particulières à ce sujet, par exemple, je peux faire cette attaque sur ma Livebox.
Cela rappelle aussi l'importance de tout chiffrer sur le trafic sortant de votre PC, via un VPN par exemple, il existe aujourd'hui encore de très (trop) nombreux services communiquant en HTTP.
En entreprise, n'hésitez pas non plus à imposer le TLS partout, y compris en interne.
Si vous souhaitez en savoir plus sur ce qu'apporte un VPN, rendez-vous sur mon billet associé!
Je travaille sur des environnements AWS depuis plus de 6 ans maintenant. Que ce soit en tant qu'Ops, architecte, ou architecte sécurité, il y toujours une constante que je constate autour de moi : l'IAM d'AWS est très souvent mal utilisé.
Dans ce billet, je vous propose de faire un petit tour d'horizon des raisons probables.
Parce que la doc vous indique de mettre du wildcard
La documentation est censée être le pilier sur lequel s'appuyer. Toutefois, force est d'admettre que la documentation d'AWS est loin d'être un exemple en ce qui concerne l'IAM.
Bien que la firme prône le least privilege, beaucoup de ses documentations en sont très loin.
Petit exemple tiré de la documentation officielle
De mon point de vue, la documentation est censé montrer des exemples les plus sécurisés possible pour "pousser" les utilisateurs à adopter les bons réflexes. Force est d'admettre que ce n'est pas le cas.
Parce que les APIs sont inconsistantes
Principal souci du modèle d'AWS, qui fait que chaque équipe produit est autonome : L'inconsistance des API.
Les même actions ne correspondent pas forcément au même verbes API...
Ainsi la simple action de créer un tag peut avoir plusieurs nom différents en fonction des services, comme par exemple :
elasticloadbalancing:addTags
ec2:createTags
ecr:tagResource
Mais comme ce serait trop simple, toutes les API n'ont pas forcément les mêmes type de cible.
Ainsi si je veux cibler des ressources en fonction de leurs tags, j'ai encore une fois des filtres différents :
Lorsqu'on met en place un modèle zero trust basé sur le least privilege, on va vouloir cloisonner au mieux les droits que l'on donne pour éviter toute action non désirée.
Maintenant on arrive au vrai problème.
En fonction des ressources, on pourra (ou non) filtrer correctement, mais pas forcément au même niveau.
Certaines ressources ont des ARN prévisibles, dans ce cas il est simple filtrer en amont (avant même que la moindre ressource soit créé).
D'autres fonctionne sur des identifiants internes créés par AWS, comme les security group par exemple.
Dans ce cas, il est parfois possible de filtrer sur la présence de certains tags, mais une fois de plus, pas tout le temps!
En effet, tous les services n'appliquent pas les tags de la même manière. Certains vont l'appliquer dès la création, d'autres après. Parfois tout se fait en un seul appel API, parfois en plusieurs...
Parce qu'il y a de multiples type de policies
J'aime à dire que l'IAM d'AWS est sans doute l'un des plus complet à ce jour. Toutefois, sa complétude vient aussi avec une complexité certaine : Le nombre de policies et les différentes couches qui s'appliquent à chaque évaluation.
Commençons par le plus simple : les policy IAM "classiques", que l'on appelle aussi "Identity based policies", ce sont les politiques que tout le monde exploite directement lorsque vous vous connectez à AWS. Ce sont aussi ces dernières qui sont utilisées quand vous utilisez des roles AWS.
Ensuite, il y a les "resource based policies", qui au contraire des précédentes sont directement attachées à un service, comme S3, SQS ou IAM (pour les trusts)
Puis viennent les boundaries, ces policies sont attachées à des roles ou utilisateurs pour filtrer les droits, un peu comme un tamis.
On pourrait aussi parler des SCP, qui englobent tout un compte ou une OU du service AWS Organization, pour appliquer des boundaries globales.
il y a enfin des policies qui peuvent être crée à la connexion avec un utilisateur fédéré : les session policies
Cinq type des policies qui peuvent toutes être utlisées en même temps lorsque vous accédez à un service, cinq!
Je ne peux que comprendre ceux qui se perdent dans ces multiples niveaux d'abstraction.
Parce qu'il y a beaucoup de limitations
Comme tous les services d'AWS, l'IAM a ses propres limitations.
Par exemple, un role IAM ne peut pas avoir plus de 10 managed policies d'attachées, et chacune de ces policies ne peut pas dépasser 6144 bytes (sans les espaces/sauts de ligne).
Un role ou un utilisateur ne peut pas avoir plus d'une boundary attachées.
Ces limitations empêchent de pouvoir composer des roles ou utilisateurs de manière optimale car si l'on veut restreindre au maximum, on est obligé de recréer des policy pour chaque ressource!
De plus quand on veut pouvoir donner des accès console + CLI, on est parfois obligé de donner plus de droit que souhaité car sinon on empêche la console de fonctionner correctement.
Parce que même le support y perd son latin
Mon dernier point et non des moindre : le support lui même s'y perd!
j'ai déjà eu à contacter le support à de multiples reprises pour des soucis d'IAM, et force est d'admettre que très souvent le support tatône pour trouver une policy fonctionnelle ou comprendre d'où peuvent venir les blocages.
Entre l'inconsistance des API, des ressources, des filtres et la complexité de certaines policies lorsqu'on veut filtrer efficacement, c'est parfois compliqué de suivre le fil.
Petit exemple de policy avec une condition (source : documentation officielle)
Comment améliorer les choses ?
Malgré tout les points que j'ai cité, il est toujours possible de faire "proprement" des policies (du moins du mieux possible), toutefois, ca demande du temps et de l'outillage.
Pour ma part, voici ce que j'utilise très (très) souvent :
La documentation officielle de toutes les API, avec leurs filtres : Cette documentation est relativement bien tenue à jour et vous permet d'avoir déjà une bonne vision d'ensemble
Le simulateur de policy d'AWS : qui vous permet de tester une policy sur une action particulière, très utile quand on veut filtrer sur des ARN ou tags par exemple.
Des linter de policy, que ce soit celui intégré dans AWS Access Analyzer ou des outils tiers comme Parliament par exemple
Il faut garder en tête que l'IAM d'AWS reste complexe de part sa puissance. Pour ma part, même après des années à en faire quotidiennement, je suis très loin d'en maîtriser 100% de ses aspects...
Les certificats TLS font partie du quotidien pour n’importe qui manipule les technologies du web.
Mais saviez-vous que vos certificats peuvent trahir vos projets confidentiels, vos environnements non productifs ou la topologie de votre entreprise ?
Un besoin de transparence
Pour comprendre pourquoi vos certificats peuvent être un vecteur d’attaque, nous allons nous pencher sur le fonctionnement même d’un certificat TLS, du point de vue de votre navigateur.
Ça y est, vous êtes décidé! Vous allez démarrer blog!
Bon, maintenant, la vraie question : par où je commence ?
Pas d'inquiétude, je vais vous donner quelques astuces que j'ai apprises en presque 3 ans de blogging.
Pourquoi je peux en parler ?
Il y a 3 ans de cela, je publiais mon premier billet sur ce blog, après des mois et des mois d'hésitations.
Content d'avoir eu mes 10 premiers lecteurs (des amis et collègues de travail), j'ai continué à publier, en améliorant petit à petit mon contenu.
Aujourd'hui, vous êtes entre 3.000 et 10.000 visiteurs uniques à visiter ce site chaque semaine (en fonction du contenu que j'ai publié).
Je sais que j'ai un nombre conséquent de gens qui suivent ce blog, et mon flux RSS est dans l'abonnement de nombre de personnes!
Toutefois, cette croissance ne s'est pas faite par magie, et je vais vous expliquer les points clés qui m'ont permis de croitre et vous permettrons vous aussi de lancer votre blog avec succès.
Pourquoi écrire?
Cette question, c'est la première que vous devez vous poser : pourquoi voulez-vous écrire?
Pour partager au plus grand nombre
Pour être visible
Juste pour vous
Pour vous faire un porte-folio
Qu'on se le dise : il n'y a pas de mauvaise raison. Par contre, en fonction de votre objectif, vous n'allez pas aborder les choses de la même manière.
Pour ma part, j'écris pour partager au plus grand nombre, ce qui, par ricochet, implique le second point : pour partager à beaucoup de monde, il faut être visible!
Les deux derniers points sont les plus simples : ils ne vous engagent pas vraiment dans un rythme ou un niveau de contenu.
Pourquoi est-ce qu'on viendrait sur mon blog ?
Si votre but c'est d'être lu, il faut que les gens aient eu une raison de venir sur votre blog plutôt que celui d'un autre.
Pour ce faire, il existe plusieurs points.
Publier du contenu "atypique"
Ne pas suivre la masse vous permet de sortir du lot. Petit exemple en date : la faille log4j en décembre dernier.
Lorsque beaucoup de site et blog ont décidé de couvrir la faille en elle-même, et de la décortiquer 8.500 fois, j'ai préféré pour ma part parler de la réalité du terrain en tant que membre d'une équipe sécurité.
Avoir une approche nouvelle sur un sujet existant est rafraichissant à lire, je suis le premier à préférer lire ce type de contenu qu'un énième redit de la même chose.
Avoir du contenu atypique, c'est parfois aussi le choix de la langue. Ce blog est publié principalement en français (même si une version anglaise existe), cela me permet aussi de sortir du lot, vu que nombre de personnes n'aiment pas forcément lire l'anglais.
Offrir VOTRE point de vue
Personnellement, lorsque je vais sur un blog, c'est pour lire le contenu d'un auteur. Je ne veux pas forcément lire quelque chose de trop neutre.
Au travers des billets, c'est aussi l'occasion de vous exprimer, aussi bien sur le contenu que sur la manière de le présenter.
N'hésitez pas à mettre votre "patte"!
Publier du contenu régulièrement
Autre règle de base pour augmenter sa visibilité : la régularité.
Publier à intervalle régulier (pas forcément rapproché) va permettre de fidéliser votre lectorat en créant un "rendez-vous".
Attention toutefois, le but n'est pas de noyer votre lecteur sous le contenu, donc n'essayez pas de publier souvent, mais simplement avec des écarts fixes, par exemple une fois toutes les deux semaines.
Vous ne verrez pas d'augmentation de votre audience instantanément, mais sur la durée, ça paie!
Utiliser les réseaux sociaux
Les réseaux sociaux sont un bon levier pour parler de vos contenus.
Attention toutefois à cibler les réseaux qui sont exploités par votre lectorat, pour ma part, je me focalise principalement sur Twitter et LinkedIn qui contiennent le plus gros de mes lecteurs (environ 50% de mes lecteurs viennent de Twitter par exemple).
Mais attention, les réseaux sociaux, c'est aussi :
Les réseaux décentralisés, comme Mastodon par exemple
Votre premier cercle de lecteur sera souvent votre entourage : famille, ami, collègues de travail, etc.
Augmenter son nombre de lecteurs est quelque chose qui prend du temps, beaucoup de temps, et la patience est indispensable.
Écrire pour le plaisir
Je terminerais avec ce conseil, tout aussi important que le premier. Écrire doit rester un plaisir.
Tomber dans le batch pour faire de l'écrire risque de vous dégouter. Écrivez quand ça vous plait, sur ce qui vous plait.
De même, écoutez les retours de vos lecteurs, mais ne vous focalisez pas dessus. Pour ma part, j'ai eu ma dose de haters, et même si ça me gênait au début, je n'y prête même plus attention!
Je vois souvent passer des communications indiquant qu'il faut faire des mots de passe avec beaucoup de caractères, car cela les sécurise, avec de jolis graphes qui expliquent qu'il ne faut que quelques secondes pour casser un mot de passe à 8 caractères.
C'est à la fois vrai et faux.
Aujourd'hui, je vais vous partager mon avis sur ce sujet.
Avoir un mot de passe fort est important...
...mais ce n'est pas la seule chose importante
Il est évident qu'il est indispensable d'avoir un mot de passe fort pour sécuriser ses différents accès.
Par mot de passe fort, j'entends :
Minimum 12 caractères
Mélange de majuscules et minuscule
Présence de chiffres et caractères spéciaux
Unique pour chaque site
J'ajouterais aussi qu'il est important que ce mot de passe ne reprenne pas quelques informations "personnelles", telle que :
Nom des animaux de compagnie
Date de naissance
Prénom des enfants, conjoint etc.
Pourquoi? Car cela permet de vous protéger des attaques par dictionnaire.
En effet, l'un des modèles d'attaque courant consiste à se renseigner un minimum sur sa cible, avec les réseaux sociaux par exemple, pour construire un dictionnaire, permettant de créer des combinaisons de mot de passe possibles.
A chaque site son mot de passe
Plus important encore que la complexité du mot de passe, son unicité est un critère primordial.
Pourquoi ? Tout simplement parce que des sites se font pirater tous les jours et toutes les entreprises sont ciblées.
L'intérêt est donc en cas de compromission d'un site de réduire énormément le blast radius et éviter que l'ensemble de vos comptes soit compromis en un coup.
A ce titre, je vous invite fortement à vous inscrire sur HaveIBeenPwned.com afin de voir si votre adresse mail s'est retrouvée dans un leak.
Exploiter autant que possible l'authentification à facteur multiple
L'authentification à facteur multiple, ou MFA (Multiple Factor Authentication), permet de complexifier une attaque en demandant une information supplémentaire à l'utilisateur pour l'identifier.
Cela peut être, sans être exhaustif :
Une clé physique, comme les célèbres YubiKeys
Un code unique, avec des applications comme Authy, ou un générateur physique
Un code envoyé par mail, SMS, appel téléphonique, etc.
Responsabilité du développement
Limiter la communication à indiquer qu'il faut créer un mot de passe sécurisé est insuffisant.
Il est aussi indispensable de mettre en place de bonne pratiques de développement, petit tour d'horizon.
Exponential backoff
Derrière ce terme barbare se cache l'un des concept qu'on retrouve souvent dans les webservices.
L'idée ici est qu'a chaque mot de passe erronné, on interdit à l'utilisateur de se connecter pendant un certain laps de temps, de plus en plus grand.
C'est ce que font la plupart des systèmes Linux par exemple.
Cela permet de réduire grandement la facilité avec laquelle on va pouvoir "brute force" un compte, c'est à dire tenter de casser le mot de passe en essayant beaucoup de combinaisons.
Ainsi, même avec un mot de passe plus faible, les possibilités restent réduites.
Toutefois, pour que ce modèle soit efficace, il est important de prendre en compte les points suivants :
Toutes les attaques ne ciblent pas forcément un seul compte, certains attaquant vont cibler une liste de compte et tourner entre les comptes pour attaquer et être moins visible, sur ce point, on filtre souvent en exploitant les adresses IP, en interdisant les tentatives d'affilées depuis la même adresse.
Empêcher les tentatives d'affillée sur le même compte, même depuis plusieurs IP. Cela permet par exemple de se protéger contre les attaques effectuées par des botnets.
Ces protections vont être pertinentes avec des modèles d'attaques courants.
De plus, il faut aussi se méfier des attaques slow rate. Ces attaques vont utiliser les mêmes modèles que précédemment, mais avec une fréquence faible, pour essayer de passer sous les radars. D'où l'importance de bien surveiller les tentatives d'accès!
On peut aussi aller plus loin en implémentant en plus une solution antibot, comme j'en ai parlé par le passé :
Je l'ai déjà dit : l'information, c'est le pouvoir.
Même si un utilisateur légitime sera heureux de savoir s'il s'est trompé sur son login, son mot de passe, si son compte est verrouillé etc., cela reste une informations pertinente pour un attaquant, lui permettant de savoir comment orienter son attaque.
L'un des exemples est d'utiliser les formulaires de login pour faire de l'énumération d'adresse mail, quand le formulaire réponds gentiment "je ne connais pas ton adresse mail".
Ainsi, quelque soit le problème d'authentification, il est conseillé de toujours répondre le même message, le plus générique possible.
Ajouter du sel à la recette
La sécurisation des mots de passes passe aussi par leur stockage.
En cas de compromission d'une base de donnée, le but est de complexifier autant que possible le boulot du hacker.
Pour cela, la technique la plus commune (et simple) reste le basique, mais efficace salt + hash.
Cette technique consiste à ajouter un chaine de caractères en supplément du mot de passe, si possible unique pour chaque utiliteur.
Cela permet d'avoir des hash moins facilement reversible (par dictionnaire).
Auth0 a publié un bon article sur le sujet, que je vous invite à lire si vous voulez en savoir plus.
Les points que je cite ici ne sont pas exhaustifs, mais consiste pour moi dans le socle solide qui permet de sécuriser un peu plus vos comptes.
La meilleure manière de générer un mot de passe unique et sécurisé pour chaque site reste l'utilisation d'un password manager, comme keepass, bitwarden, etc.
Pour ma part, j'exploite bitwarden, qui me permet de générer et stocker des mots de passe forts et uniques, comme vous pouvez le voir ci dessous.
N'hésitez pas à rajouter en commentaires les points qui vous semblent indispensables.
Dans les deux premiers billets de cette série, nous avons vu comment créer notre bucket de base, configurer notre nom de domaine, et manipuler rapidement Hugo.
Dans ce dernier billet de la série, nous allons donc passer à l'étape manquante : le déploiement.
Automatiser le déploiement sur Scaleway
Créer un utilisateur API
Nous allons commencer par créer un utilisateur API sur la console Scaleway.
Pour cela, rendez-vous sur le menu en haut à droite, puis "Identifiants"
Cliquez ensuite sur "Générer une nouvelle clé API", puis donnez-lui un nom.
Copiez de suite les identifiants, il ne sera pas possible de les récupérer ensuite!
Préparer la clé dans le repository
Dans votre repository Github, rendez-vous dans "Settings", puis "Secrets"
Nous allons créer deux secrets :
AWS_ACCESS_KEY_ID: qui porte la clé publique
AWS_SECRET_ACCESS_KEY : qui porte la clé privée
Ces secrets ne sont pas récupérables directement, à part par votre pipeline de déploiement.
Préparer la configuration S3 pour Scaleway
Scaleway exploitant le standard S3 d'AWS, nous allons utiliser la ligne de commande d'Amazon pour pousser sur S3.
Toutefois, nous aurons besoin de configurer le client pour qu'il pointe vers scaleway au lieu d'AWS.
La configuration nécessaire est décrite sur la documentation officielle de Scaleway :
Enfin, nous allons préparer un fichier de configuration pour notre pipeline, c'est ce dernier qui se chargera de livrer chaque modification sur notre bucket.
Pour ce faire, nous allons créer le fichier .github/workflows/deploy/yml, dans lequel nous allons mettre le contenu suivant :
Nous ne voulons lancer le pipeline que lors d'un commit sur master, ou le merge d'une branche sur le master
Nous allons utiliser une image docker Ubuntu pour effectuer le déploiement
Nous avons un déploiement en plusieurs étapes
Concernant ces étapes nous avons donc :
Le checkout du code : nous indiquons que nous voulons que le code de notre repository soit rapatrié (c'est mieux pour l'utiliser)
Ensuite, nous installons via apt : Hugo, unzip, et pip. Ces derniers sont peut être déjà présents, mais ça ne coûte rien de s'en assurer
Après, nous déployons le client AWS V2, comme le point précédent, il est peut être déjà là, mais ça ne coûte rien.
Nous installons ensuite le plug-in nécessaire pour surcharger le endpoint S3 vers Scaleway
Nous déployons notre configuration AWS
Nous lançons la compilation du site avec Hugo, il nous générera les fichiers HTML statiques dans le répertoire "public"
Enfin, nous poussons le site sur S3, l'option --delete permettant de supprimer les fichiers qui ne sont éventuellement plus présents
Let's rock!
Maintenant que tout est prêt, il est temps de faire un gros push vers Github.
Si vous allez sur l'interface, dans l'onglet "actions" vous devriez voir votre pipeline tourner.
En quelques minutes, il devrait avoir fini :
Et si vous allez sur votre bucket sur Scaleway, vos objets sont bien présents :
Enfin, si nous retournons sur notre record DNS que nous avions créé plus tôt, nous avons bien notre site qui s'affiche :
En conclusion
Hugo est un outil puissant
Dans ce billet, je n'ai fait que survoler Hugo. Si vous voulez en savoir plus, je vous encourage vivement à visiter la documentation du projet, qui a le mérite d'être très accessible.
Scaleway vous permet de commencer un blog sans prendre de risque
Le stockage objet de scaleway est adapté si vous voulez commencer un blog sans prendre de risque.
En effet, il ne coûte rien, et vous permet d'avoir un service de qualité sans avoir besoin de passer du temps à le maintenir en fonctionnement.
De plus, cela vous permet d'héberger vos données en France, par un acteur français!
Github simplifie les choses
J'ai fait le choix de Github pour ce billet, mais j'aurais pu aller jusqu'au Github pages, qui permettent aussi d'héberger du contenu statique. J'ai choisi de mettre Scaleway comme point final, car je voulais montrer qu'on pouvait aussi héberger en France sans avoir plus de difficultés.
Ces billets sont une base
Comme je l'ai dit plusieurs fois, ces billets sont une simple base, beaucoup de choses sont améliorables, et beaucoup de chemins alternatifs sont possibles.
Le but est simplement de montrer une solution, fonctionnelle de bout en bout.
N'hésitez pas à réagir dans les commentaires si vous voyez des points à améliorer!
Cette semaine, nous allons passer à Hugo. Nous allons voir comment l'utiliser de manière très basique pour créer notre blog, et nous créerons le repository Github qui hébergera le code de notre blog.
Passons à Hugo
Créer un repository Github
Pour ce billet, j'ai choisi d'héberger le contenu sur Github, rien n'empêche de l'héberger ailleurs.
L'intérêt de Github est multiple :
Hugo repose sur des fichiers "descriptifs" très légers
Github permet d'historiser
Github permet de sauvegarder
C'est simple de gérer les accès pour gérer un blog à plusieurs par exemple
Il est possible d'avoir un process de revue (automatisé ou non) avant la publication
Donc, nous allons donc créer un repository Github, que vous pouvez mettre en public ou privé selon ce que vous préférez.
Ce repository portera donc notre "code Hugo" ainsi que le pipeline de déploiement, puisque comme je l'ai dit plus haut, j'utiliserai Github actions pour le déploiement et les mises à jour de mon blog.
Initialiser mon blog
Sur mon ordinateur, je vais donc cloner mon repository tout beau tout neuf, puis je vais installer Hugo.
Pour cela, je vous invite à consulter la documentation officielle à ce propos, qui vous permettra de choisir la solution la plus adaptée à votre besoin.
Ensuite, je vous invite à modifier le fichier config.toml à la racine pour renseigner les informations qui vous correspondent (notamment l'URL racine du site).
Si l'on fait un blog, c'est pour avoir du contenu. Nous allons donc de suite créer un premier billet avec une simple commande :
hugo new posts/my-first-post.md
Avec cette commande, nous indiquons que nous allons créer un post qui s'appellera "my-first-post".
Vous noterez l'extension : Hugo fonctionne avec des posts écrits en markdown. Si vous n'êtes pas à l'aise avec ce templating, il existe de nombreuse "cheat sheet" pour vous aider, comme :
Ensuite, vous pouvez éditer votre post, qui se trouvera dans ./content/posts/my-first-post.md
Voici par exemple les informations que j'y ai mises.
À noter que le premier bloc entre les tirets en haut correspond aux métadatas de votre billet.
Avant de fermer votre éditeur, n'oublier pas de changer la variable draft de true à false, sans quoi votre billet ne sera pas publié.
---
title: "My First Post"
date: 2021-12-22T17:23:34+01:00
draft: false
toc: false
images:
tags:
- untagged
---
Hello friend!
As you can see, we use **markdown** to create a simple blog
```python
#!/usr/bin/env python3
# We can use every markdown blocks
works = True
if works:
print "You're the best!"
```
Vous pouvez tester le rendu en lançant la commande suivante :
hugo server -D
qui devrait vous donner le résultat suivant :
ted@kali:/home/ted/dev/hugo-demo# hugo server -D
| EN
+------------------+----+
Pages | 12
Paginator pages | 0
Non-page files | 0
Static files | 3
Processed images | 0
Aliases | 4
Sitemaps | 1
Cleaned | 0
Total in 75 ms
Watching for changes in /mnt/d/dev/hugo-demo/{content,data,layouts,static,themes}
Watching for config changes in /mnt/d/dev/hugo-demo/config.toml, /mnt/d/dev/hugo-demo/themes/listed/config.toml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop
À partir de là, vous pouvez vous rendre sur http://127.0.0.1:1313 pour voir votre blog tourner.
Maintenant, c'est bien joli, mais vous n'allez pas faire se connecter les utilisateurs sur votre PC!
A suivre au prochain épisode
Dans les deux premiers billets, nous avons vu comment créer notre bucket qui servira notre site, ainsi que le domaine associé, puis nous avons commencé à manipuler Hugo.
Dans le billet final, nous mettrons en place le nécessaire pour automatiser le déploiement et avoir un blog en haute disponibilité, automatisé, sauvegardé à moindre coût.
Héberger un blog ne demande pas forcément une énorme infrastructure et beaucoup de moyens. Il est possible de créer un blog simplement pour quelques euros par an (et encore).
Il y a quelques mois, j'avais écrit un billet indiquant l'importance de publier son contenu "chez soi", que vous pouvez retrouver ci-dessous.
Suite à ce dernier, beaucoup m'ont contacté pour me demander des exemples concrets de ce que j'entendais par là.
Aujourd'hui, je vais donc vous présenter un modèle, que vous pouvez facilement modifier ou faire évoluer pour héberger votre contenu à moindre coût. Tout en prenant en compte la haute disponibilité, les sauvegardes et le déploiement.
⚠️
Le sujet couvrant l'intégralité du déploiement, et étant de fait très long, sera découpé sur 3 billets successifs. Dans ce premier billet, nous allons créer la base nécessaire pour héberger notre blog.
La cible
Je vais partir sur une cible assez simple.
Je veux pouvoir éditer mon blog depuis mon PC, pousser le code sur Github, et qu'il soit publier en quelques minutes.
De manière très synthétique, voici la cible.
Le seul prérequis est d'avoir un nom de domaine (et on peut s'en passer si on le souhaite).
Certains domaines ne coûtent presque rien, par exemple le ".ovh" ne coute que 3€ HT par an!
⚠️
Attention en achetant un domaine : certains revendeurs pratiquent des prix d'appels très agressifs la première année. Par exemple, toujours chez OVH, le ".blog" est à 5,49€ la première année, mais 25,99€ les suivantes!
Hugo, c'est quoi ?
Hugo est un moteur de création de sites, open source, générant des fichiers statiques. L'intérêt premier est de ne pas nécessiter de compilation à la volée comme avec des langages interprétés (Php, Node, Python, etc.), et il n'a donc pas besoin de base de données.
Dans le cas d'un blog, c'est un modèle adapté, car nous avons du contenu qui n'a pas besoin de bouger énormément au jour le jour.
Pour plus d'information, je vous invite à vous rendre sur le site du projet !
Maintenant que vous avez notre nom de domaine, on va commencer à préparer le socle qui va recevoir notre site.
Pour ce billet, j'ai fait le choix de le faire manuellement, mais libre à vous de l'automatiser si vous le souhaitez!
À noter que le mode d'hébergement que nous allons utiliser ne sait pas gérer le chiffrement TLS avec votre nom de domaine.
Pour cela il faut soit :
Que vous mettiez un reverse proxy devant
Que vous passiez par des solutions qui vont faire du proxy, comme Cloudflare (que j'utiliserais dans ce billet)
Première étape : Créer un compte sur Scaleway
Pour cela, il vous faut ouvrir un compte sur Scaleway. Ce compte est gratuit. Scaleway est un cloud provider d'Illiad. Pas d'inquiétude, une carte bleue vous sera demandée, mais vous n'aurez aucune facture, je peux vous l'attester :
Ma facture mensuelle, alors que Scaleway stocke tous mes backups de ce serveur (environ 40Go de données)
Seconde étape : Créer un bucket de stockage sur Scaleway
Ensuite, nous allons utiliser la solution de stockage d'objet de Scaleway.
Pourquoi cette solution?
75Go de stockage et transfert offert tous les mois, sans limites de durée
Compatible S3 (nous en aurons besoin ensuite)
Taux de disponibilité à 99.99% (ce qui correspond à une indisponibilité maximale de 5 min par mois)
Possibilité d'héberger votre contenu en France
Cloud souverain
À noter qu'un stockage d'objet est prévu pour stocker des fichiers statiques, qui peuvent être téléchargés directement. Nous ne pouvons pas manipuler les fichiers en direct comme sur un disque dur.
Nous allons donc cliquer sur "Object storage" dans le menu "Stockage" du menu latéral gauche. Ensuite, nous allons cliquer sur le "+" en haut à droite pour créer un nouveau bucket.
Vous devriez arriver sur un masque similaire à celui-ci :
⚠️
Le nom du bucket est important, il doit porter le nom de domaine que vous souhaitez utiliser pour votre blog, sans quoi nous ne pourrons pas faire de redirection.
Dans mon cas, vous pouvez voir qu'il s'agit de "demo-hugo.tferdinand.net" que j'ai créé pour l'occasion. Vous pouvez choisir la région que vous souhaitez, pour ma part, j'ai pris la France. Pour la visibilité du bucket, vous pouvez laisser en privé, nous reviendrons indirectement dessus par la suite.
Une fois le bucket créé, cliquez sur son nom, puis allez dans l'onglet "Réglages du bucket".
La partie qui nous intéresse ici est le "bucket website". Cette fonctionnalité va nous permettre de créer un serveur web distribuant des fichiers statiques.
Nous allons donc activer la fonctionnalité, et indiquer les paramètres suivants :
Nom du fichier d'index : index.html
Nom du fichier d'erreur : 404.hmtl
Vous pouvez ensuite cliquer sur "enregistrer la configuration"
Troisième étape : configurer Cloudflare
Cloudflare est aussi un service gratuit pour une utilisation non commerciale, car nous n'avons pas forcément besoin de ses fonctionnalités avancées.
Cloudflare est d'ailleurs devant mon serveur, et vous l'utilisez actuellement!
Nous allons donc récupérer le nom de domaine de notre bucket, dont nous aurons besoin.
Ensuite, depuis l'interface de Cloudflare, nous allons créer un record DNS CNAME qui pointera vers ce bucket.
Attention, si on veut avoir du TLS, il faut bien choisir l'option "Proxied" sur Cloudflare, qui permet de surcroit d'exploiter le cache de ce CDN.
Arriver à cette étape, vous pouvez vous rendre sur votre record DNS, et si tout va bien, vous obtiendrez une jolie erreur 404.
Pas d'inquiétude, c'est normal. Actuellement, nous avons un hébergement, mais aucune donnée dessus!
To be continued
Comme je vous l'ai indiqué en préambule, ce billet est le premier d'une série de trois.
Rendez-vous au prochain billet pour dans lequel nous commencerons à manipuler légèrement Hugo et nous créerons le repository Github qui hébergera notre solution.
Ce billet sera bien plus long que l'habitude, car il s'agit d'une retranscription complète de l'interview pour ceux qui préfèrent le format classique de ce blog, l'écrit.
La version vidéo contient exactement le même contenu.
Bonjour à toi, Carl, ça me fait plaisir d’échanger avec toi pour cette interview. Dans un premier temps, je vais te laisser te présenter.
Dans la vie je suis freelance, architecte de systèmes informatiques, une branche que tu connais bien, à mon compte depuis 2012. J’ai une activité assez importante dans l’open source, dans lequel je suis investi depuis 2010, voire un peu avant même.
Depuis quelques années, j’ai pris un virage un peu différent dans l’entrepreneuriat dans lequel je lance différents projets, qui se recoupent bien l’open source et l’entrepreneuriat, car beaucoup de choses se croisent.
J’ai créé une newsletter qui se base sur le journal du hacker qui s’appelle le courrier du hacker qui a atteint les 4000 abonnés, pour 187 numéros, je crois.
Un projet qui fait le lien entre l’entrepreneuriat et l’open source, qui s’appelle Linuxjobs.fr qui est un site d’emploi pour les professionnels de l’open source
Le petit dernier : lesnewsletters.com, un site qui vise les créateurs de newsletter francophone afin de les aider à faire connaître et monétiser leurs newsletters
Tout ça en parallèle de mon activité de freelance, j’essaie de créer que des projets qui tournent seuls en majorité ou en grande partie.
Effectivement, je t’ai connu grâce au journal du hacker personnellement. Du coup, sans transition : Le journal du hacker, le courrier du hacker, linuxjobs, lesnewsletters, ça fait beaucoup de projets. D’où te vient cette volonté de partager toujours plus de connaissance avec le plus grand monde ? [Même si beaucoup de choses viennent de l’extérieur, comme tu l’as dit, ce sont en grosse partie des agrégateurs.]
C’est une bonne question ! Je pense que quand j’ai commencé au début dans l’open source, à la fin de mes études en informatique, j’avais déjà évolué dans le monde de l’open source, en particulier dans le monde de Linux. Et puis peu à peu dans le monde des distributions GNU Linux, et en particulier de Debian.
Il y avait donc ce projet, Debian, déjà très connu à l’époque [dans les années 2008-2010], qui me faisait envie. J’avais aussi de me prouver à moi-même que j’étais capable d’intégrer un projet open source d’importance. C’était pour me le prouver à moi-même, mais aussi prouver aux autres que je n’avais pas fait des études en informatique pour rien [rires], et que j’allais pouvoir apporter une pierre à l’édifice tout en construisant ma carrière professionnelle.
J’ai commencé, au tout début, sur un outil de traduction de KDE. J’aidais à développer la partie française, pour traduire ce qui était dans les logiciels de KDE. J’ai rapidement mis le pied à l’étrier comme ça. Mais rapidement, ce n’était pas assez technique, j’avais envie de partir sur quelque chose de beaucoup plus technique et donc je me suis aventuré dans le monde de la distribution Debian.
J’ai commencé par corrigé des petits bugs qui sont dans les programmes qu’on installe par défaut dans Debian, puis peu à peu, l’investissement a grandi. J’ai commencé à gérer mes premiers paquets, à arriver sur des paquets beaucoup plus lourds comme virtualenv et pip qui sont des outils pour le monde Python, que je connaissais bien aussi. J’ai développé une activité dans la communauté Python à côté de ça. Ça a été assez rapidement après mes études quelque chose que j’ai essayé de consolider.
Dans le même temps, j’ai écrit 56 articles pour GNU Linux magasine France (GLMF), qui est le principal magasine public du logiciel libre et de l’open source francophone (magasine papier).
Mon blog aussi, j’ai créé un blog très rapidement, qui a eu pas mal de succès dans les années 2012-2015.
Une aventure pour faire progresser le logiciel libre, l’open source, en tirer quelque chose que je pouvais partager de ma part. Je voulais me sentir utile, progresser techniquement parce que les apports de travailler avec les autres gens sont énormes. C’est le background technique qui s’est posé à moi.
J’ai eu ensuite un virage assez différent, une fois que je me suis prouvé ça, on avance assez rapidement dans le temps, on est en 2012-2015. J’ai commencé à avoir fait le tour, je suis devenu développeur Debian officiel. Ça veut dire que tu es reconnu par tes pairs, qui te propose puis les contributeurs confirment qu’ils sont d’accord pour que tu deviennes développeur Debian. Ça faisait déjà 4 ans que j’étais dans le projet. J’avais envie de voir et proposer autre chose.
Il ne faut pas se le cacher non plus, il y avait des raisons financières : sur l’open source tu peux passer beaucoup de temps à travailler pour les autres, à fournir de la valeur à la communauté, et au bout d’un moment j’avais envie de générer un peu d’argent sur un projet qui ne soit pas lié au salariat [j’étais encore salarié à l’époque].
J’ai commencé par un premier projet : Linuxjobs.fr, un site d’emploi que j’ai mis en place qui me permettait de faire le lien entre la communauté open source et l’entrepreneuriat.
À côté de ça, j’ai d’autres projets liés à l’open source également : le journal du hacker, un agrégateur de lien, sur lesquels les gens proposent des liens, et les liens qui ont le plus de succès se retrouvent sur la première page et sont le plus mis en avant.
Je suis parti sur une idée à la base de quelque chose qui ressemblait au site hacker news, qui est un gros site américain du même genre, en me disant "Ça n’existe pas en France, donc il faut que l’on fasse quelque chose à ce niveau-là".
On voit le début du virage entre l’entrepreneuriat et l’open source tout simplement.
J’ai rencontré assez rapidement mon premier associé, cascador [ il aime bien qu’on utilise uniquement son pseudo, alors je n’utiliserais que son pseudo], c’est quelqu’un que je considère vraiment comme le cofondateur, qui m’a soutenu dans le premier élan, qui a travaillé autant que moi sur le projet et qui nous a permis faire grandir ce projet, de le faire connaître, et d’arriver aujourd’hui à plusieurs milliers d’utilisateurs réguliers, avec plusieurs centaines de personnes qui postent des liens régulièrement. Et un noyau dur, comme tous les projets du logiciel libre, d’une dizaine, une vingtaine, une trentaine de personnes qui interviennent très souvent.
Je pense que c’est le succès le plus visible d’un de mes projets que j’ai eu à l’époque. Les gens ont commencé à voir le travail qui était fourni, en direction de l’open source, mais un outil qui était donné à disposition des gens, moins communautaire, moins "confidentiel" que le projet Debian où les gens sont peu connus.
[Teddy : Effectivement, ce n’est pas le même public, je pense. Sur le projet Debian, tu as un public qui est beaucoup plus initié à la technique que le journal du hacker. Sur le journal du hacker, tout le monde peut poster, proposer des choses, mais profiter aussi des liens qu’il y a dessus, je l’utilise moi-même pour ma veille technologique par exemple]
C’est l’envie que j’avais ! J’avais envie de sortir un peu de la technique, d’avoir un public plus large. J’ai un blog depuis quasiment le début. J’écrivais assez souvent sur LinuxFr, principal site francophone du logiciel libre et l’open source. J’ai toujours essayé de partager un peu. C’est vrai qu’on est dans une niche technique, mais je ressentais le cloisonnement qui pouvait être limitant pour notre communauté, et j’ai essayé d’ouvrir un peu ça avec le journal du hacker.
C’était vraiment l’approche d’un projet utilisable par le plus grand nombre.
Ensuite, le projet intéressant, je pense, qui découle du premier : comme j’ai mis un outil à disposition de la communauté, j’ai voulu pousser des gens à utiliser cet outil, et dans cette démarche, comme on est quasiment en open data on peut dire [on peut récupérer la base de données du journal du hacker et faire des projets tiers avec], et comme je voulais donner l’exemple sur ce type d’initiative, j’ai créé une newsletter qui chaque semaine résumé les meilleurs liens du journal du hacker et que j’ai nommé le courrier du hacker. Cette newsletter est indépendante, car je ne voulais pas mélanger les deux projets, mais elle s’appuie très fortement sur la base de données et tout le travail fourni par, comme toi par exemple, les créateurs de bons billets de blog, qui reçoivent des critiques positives, qui sont sur la première page du journal du hacker.
Je voulais continuer à mettre en avant ce travail de la communauté francophone, des créateurs de contenus, des sociétés, des individus qui créent ce contenu que je trouve excellent, et ça me permettait au travers de cette newsletter de remettre une couche auprès d’un public qui pouvait être différent de celui du journal du hacker.
Le journal du hacker, c’est un agrégateur, il faut aller tous les jours sur le site, l’investissement est différent. Donc le courrier du hacker, cette newsletter que j’envoie le vendredi le plus souvent, permet aux gens d’analyser un peu ce qui s’est passé. Et comme ce n’est pas email, tu peux le lire dans le train, de manière asynchrone, et ça marche bien. La courbe des abonnés a grandi assez rapidement.
Le projet est lancé depuis 3 ans maintenant, et cette année, on a franchi le cap des 3000 abonnés, c’est une recette qui ne change pas : toujours fournir les 18-20 meilleurs liens de la semaine passée, et elle continue de marcher, le nombre d’abonnés continue de grandir, et ça participe encore de sortir de cette niche technique et de partager au plus grand nombre ce que font les créateurs de la communauté logiciel libre et open source francophone.
Comme tu le disais, j’utilise beaucoup le journal du hacker, vu que je squatte régulièrement la première page [rire]. J’utilise peu les autres projets, mais je pense que ce sont des projets qui permettent de propager la connaissance au plus grand nombre, à partager cette connaissance, à l’apporter à tous, donc déjà je te remercie pour ça ! Tu as abordé un point qui est très intéressant : tu as dit que tu étais contributeur actif au projet Debian. C’est un point qui m’intéresse beaucoup, et je voulais savoir : ça fait quoi, concrètement, de contribuer à un projet open source de cette envergure ?
Alors c’est une aventure un peu en standby tout de même. Je suis assez loin de Debian aujourd’hui, je suis plus dans l’entrepreneuriat, mais on va dire qu’autour de 2012, j’étais assez investi.
Ça a commencé, comme je le disais au début, de manière assez triviale : j’ai commencé à apporter quelques correctement de bug, à parler avec les gens. C’était aussi pour moi la découverte de ce qu’on appelle aujourd’hui le télétravail : donc j’étais chez moi, j’envoyais des mails, je discutais en direct avec d’autres personnes qui étaient à l’étranger.
On échangeait de manière complètement asynchrone, tout ça en contribuant au projet Debian : le faire grandir, le faire évoluer, rendre disponible ce que les gens veulent trouver dans le projet Debian. C’était assez passionnant.
Je n’ai pas vu passer la première année, j’étais à cout de 4 heures par soir tous les soirs en rentrant du travail. C’était facile j’étais encore chez ma mère, donc c’est elle qui faisait à manger [rires] !
Au bout d’un an, j’avais un mentor, quelqu’un avec qui je travaillais régulièrement, un Italien, Sandro Tosi, que je salue.
Donc je lui dis "ça fait un an que je bosse, tu vas peut-être me sponsoriser pour que je sois développeur Debian", et là il m’a dit "Ah non, tu ne peux pas", puisqu’à l’époque seuls les gens qui géraient des paquets pouvaient devenir développeurs Debian. Ce n’est plus le cas aujourd’hui, même des gens non techniques peuvent l’être : des gens qui font des conférences, qui s’investissent dans la communauté, qui promeuvent l’accessibilité, peuvent être reconnus en tant que "developpeur Debian", et avoir le même statut.
À l’époque, ce n’était pas le cas, et là je me suis dit "ça fait un an que j’écris des programmes Python pour Debian et je ne peux pas être développeur Debian".
Donc rebelote, j’ai commencé à gérer des paquets Debian. Et qui travaille avec Debian sait l’énorme machinerie des paquets Debian qui est extrêmement fiable et présente dans la distribution Debian, et je m’y suis collé, j’ai représenté un an après ma proposition.
Ça a pris un peu de temps, parce qu’il a fallu que je trouve un sponsor. Quelqu’un acceptait de sponsoriser mon entrée. Mon sponsor officiel l’avait déjà fait, et ne souhaitait plus le faire.
Il y a eu beaucoup d’humains à cette période, et je crois que je suis devenu développeur Debian au bout de 3 ou 4 ans, ça ne s’est pas fait du jour au lendemain.
C’est fait pour, clairement, on ne te donne pas les clés des archives des paquets Debian comme ça. Il faut montrer patte blanche, c’est un très gros projet, ils doivent être à plus de 1000 développeurs officiels aujourd’hui [NDLR 1022 à l’heure de l’écriture].
Ça fait 1000 personnes qui peuvent jouer avec les archives. Déposer des paquets dans les archives, évidemment, c’est cloisonné, il y a des sécurités. C’est la première reconnaissance par les pairs, comme j’en parlais tout à l’heure.
Quand tu reçois ton email avec tes différents credentials et identifiants, les liens vers ta boite mail Debian, tu te sens reconnu, d’appartenir à un projet auquel tu contribues de manière quotidienne.
C’est un sentiment assez incroyable. C’est l’un des plus gros projets logiciels avec le noyau Linux. Je crois c’est parmi les plus gros en termes de contributeurs. J’étais fier et heureux de travailler et j’ai continué à contribuer assez longtemps sur ces sujets.
Je suis toujours développeur Debian officiel, mais je suis un peu plus en retrait de la contribution.
Effectivement, je pense que les mentalités ont un peu changé pour mettre en avant les contributions dans l’open source, moi même je suis "Traefik ambassador", à une échelle beaucoup plus petite, celle du projet Traefik, et je sais qu’aujourd’hui beaucoup de projets essaient de pousser vers la contribution, mais pas forcément la contribution purement technique : parler du projet, le documenter, en parler en conférence permet aussi d’être mis en avant. Après de ce que tu dis, c’est tout de même quelque chose d’assez incroyable, et on retrouve la rigueur qui fait la réputation de Debian dans les process que tu décris, même en interne.
Je continue de suivre le projet Debian, même sur les listes privées de Debian, et on voit qu’un projet d’une telle envergure doit se protéger au niveau humain.
Parce qu’évidemment sur 1000, tout le monde n’est pas ou plus forcément d’accord avec ce qu’il se passe ou avec la majorité des gens, tu as des gens qui craquent. Et comme ils ont été développeurs Debian, ils ont un pouvoir de nuisance qui est certain.
Une fois que tu es développeur Debian, tu as accès à une bonne partie de l’infrastructure. Tu as uniquement les Debian SysAdmin qui possèdent réellement les clés de tous les serveurs, mais tu n’en es pas loin, tu peux te connecter en utilisateur normal sur une grande partie de l’infrastructure. Ce qui est déjà une porte ouverte à beaucoup de choses.
La machine du projet Debian a appris à se protéger, mais ça reste beaucoup d’humain, tu vois que les "core developpers" de Debian sont réduits, je pense qu’il n’y a pas plus d’une cinquantaine de personnes où tu n’envoies pas un email sans les voir réagir. Ça reste beaucoup d’humains malgré la taille du projet, et bien évidemment des systèmes de protection, de CICD, de moyens techniques pour protéger le projet.
En parlant des projets open source, tu fais partie des gens qui militent pour que l’open source se développe, pour que l’open source soit utilisée le maximum possible. Est-ce que tu penses qu’aujourd’hui tous les besoins peuvent être adressés par l’open source ?
C’est une bonne question ! Je ne connais pas tous les besoins, donc ça va être dur de répondre.
En tout cas dans ma carrière, j’ai croisé beaucoup d’utilisation, et Debian est utilisé dans des domaines spécifiques : l’administration système, l’infrastructure système par exemple.
L’open source marche très bien, je dirais même qu’elle a gagné, avec notamment les offres cloud qui sont en grande majorité des serveurs Linux. Donc dans l’infrastructure, c’est clairement un domaine ou l’open source s’est bien développé.
Dans l’embarqué, c’est des systèmes dérivés de Linux, donc basés sur de l’open source, même si parfois ça peut dériver comme avec Android.
La sécurité est un domaine que je connais moins bien, mais je vois beaucoup d’outils open source, ou en tout cas d’outils qui sont basés sur de l’open source à la base, qui sont transformés, modifiés.
Est-ce que des domaines échappent complètement à l’open source ? Je n’en ai pas l’impression. Un des domaines sur lesquels j’ai écrit des billets de blog récemment, c’est le rachat par Microsoft de Github : on voit que quelque part, on voit une espèce d’aveu que le modèle open source est en passe de devenir le modèle dominant.
Après qu’il couvre tous les besoins, c’est une très bonne question. Connaissant la diversité du monde, surement pas, il y a surement des besoins pour lesquels ce n’est pas nécessaire, mais je pense que le modèle fait sa preuve que les échanges entre les gens, même au niveau professionnel, la contribution, la mise en commun des stacks techniques, du code, de travailler ensemble qui était uniquement pratiqué par la communauté du logiciel libre et de l’open source au début est devenu un domaine dominant chez les développeurs.
Je ne sais pas ce que tu en penses pour la sécurité par exemple ?
Pour la sécurité, ça reste encore un peu en marge comme tu disais, parce que malheureusement aujourd’hui, avec la complexité de la détection qu’on embarque aujourd’hui dans la détection d’attaque, très souvent, ça reste le monopole de quelques très grosses entreprises. Même s’il y a des initiatives communautaires, je pense notamment à CrowdSec, qui sont réellement de grosses initiatives communautaires. Pour moi dans le domaine de la sécurité, on est pas encore complètement mature dans le domaine de l’open source, même s’il y a déjà beaucoup d’outils qui existent, je pense notamment à Suricata, Metasploit. On va aussi vers de l’open source, le fait que la sécurité devient le nerf de la guerre va améliorer les choses, et va pousser les gens à aller vers de l’open source aussi.
Tu as abordé un sujet très intéressant, tu as dit que la plupart des clouds providers tournaient aujourd’hui avec Linux. Est-ce que l’open source, ce n’est pas aussi le risque que les mastodontes, notamment les GAFAM, qui récupèrent tous les lauriers ? Je pense notamment au cas qu’on a vu au début de l’année, avec le changement de licence d’ElasticSearch, où c’était la guerre ouverte entre Amazon et Elastic.co sur le fait qu’Amazon avait lancé son offre basée sur ElasticSearch et récoltait un peu tous les lauriers de la solution qui était pourtant une solution open source, maintenue par des dizaines de personnes derrière, mais c’était Amazon qui se faisait de l’argent dessus, et non pas la solution payante que proposait Elastic, qui permettait justement de contribuer à ce projet. Est-ce que justement l’open source, ce n’est pas justement le risque de créer plus de cas comme ça ? On avait déjà eu MongoDB VS Amazon. On avait déjà eu des cas pareils dans le passé, je pense qu’on en aura encore dans le futur. Est-ce que ça ne met pas en péril l’open source aussi ?
Je pense que c’est un problème global. Tu as cité des exemples qu’on peut rattacher au modèle économique et à l’entreprise, Elastic, son principal produit, qui a reçu beaucoup d’aide de la communauté, mais qui est porté par cette société, qui fait un produit efficace, bien fait.
Il avait réussi à trouver un modèle économique, et là en effet, le mastodonte AWS essayait de les ramener à un rôle d’éditeur strict quand eux essayaient justement de développer de l’infrastructure à la demande avec leur propre offre cloud.
AWS les a restreints, contraints et comme ils ont vu qu’Elastic essayait de développer son offre cloud, la guerre était lancée.
Ce qui se fini un peu bizarrement avec un changement de licence pour les produits ElasticSearch, et la création d’un fork plus ou moins maintenu uniquement pas les gens d’AWS, si tu regardes les commiters. Un modèle qui est perdant pour tout le monde je trouve.
J’avais constaté il y a longtemps de ce problème avec AWS qui proposait leur instance Linux [Amazon Linux, basé sur CentOs], qui montrait encore l’envie de mettre en avant leur marque de manière un peu écrasante des autres projets.
Pour répondre à ta question, je n’ai pas du tout la réponse. C’est un problème que je vois criant. Je ne pense pas forcément que ce n’est pas une bonne solution ce qu’a fait Elastic, et que c’est peut-être une surréaction par rapport au danger commercial dans lequel les a mis AWS. Peut-être que c’est la bonne.
Je pense que c’est une plaie ouverte qu’il va falloir suivre de très près. C’est là aussi qu’on voit le point de douleur réel du modèle économique de l’open source qui aujourd’hui est critiquable : les gens travaillent énormément d’heures, et au bout d’un moment quand tu dois choisir entre ton travail de salarié et ton travail pour la communauté, tu finis par faire un travail moyen ou bâclé pour la communauté.
Aujourd’hui, c’est problématique, par exemple sur le domaine de la sécurité, un développeur épuisé qui va commité un mauvais script dans un paquet va par exemple créer une faille d’entropie sur un paquet. C’est ce qui est arrivé sur un paquet SSH il y a quelques années.
Je pense effectivement qu’on a un gros problème à traiter ou au moins à faire évoluer sur le modèle économique de l’open source, et ce n’est pas facile.
Sachant que le changement de licence d’Elastic a aussi provoqué la fuite de beaucoup de développeurs sur la partie open source, parce que beaucoup de développeurs n’ont pas apprécié le changement qui les dépossédait un peu de ce qu’ils avaient fait. C’est le risque que je perçois dans les prochaines années, le cas Elastic n’est pas un cas isolé, c’est le cas de beaucoup de projets open source qui essaient souvent de survivre en poussant une offre payante managée à côté. Et à partir du moment où Amazon, Google, Microsoft, AliBaba se mettent à proposer leurs propres services managés qui reposent dessus, ils utilisent le service, mais n’y contribuent pas forcément. Côté Amazon, on pourrait citer AWS MSK par exemple, basé sur Kafka, ça me surprendrait qu’Amazon soit un énorme contributeur de Kafka, et de l’Apache fundation tout court d’ailleurs.
Un autre sujet que tu as abordé au tout début de cette interview : tu as parlé du télétravail, grâce notamment au projet Debian à faire du télétravail assez tôt. La pandémie actuelle a redistribué pas mal les cartes sur le télétravail, pas mal d’entreprises qui étaient contre, ou disaient que c’était impossible ont réussi à en mettre en quelques semaines. Néanmoins, pour beaucoup d’entreprises, ça reste encore une contrainte et non pas une conviction : elles le font, car elles n’ont pas le choix, et non pas parce qu’elles ont envie de le faire. Est-ce que de ton point de vue, tu penses que c’est quelque chose qui va évoluer dans un sens ou dans l’autre dans les prochaines années ?
En effet, on l’a vu au confinement de 2020 en France est devenu massif, et a été vraiment un choc pour beaucoup de salariés et d’entrepreneurs. Les gens se sont retrouvés confrontés à une culture et un usage qu’ils ne connaissaient pas.
Les entreprises s’y sont mises bon an, mal an, certaines ont bien réussi la transition : elles étaient prêtes, mais restées dans un usage présentiel par habitude tout simplement. Elles ont découvert les avantages du télétravail, elles en faisant déjà quasiment : quand les gens se réunissent dans un bureau et utilisent uniquement des outils pour du télétravail, on déjà à 70/80 % de télétravail on va dire.
Ça a été une catastrophe pour d’autres : les moyens techniques n’étaient pas en place, la culture des salariés, du middle management et du grand management n’étaient pas du tout prêtes, l’entreprise ne pouvait faire qu’un rejet de ce qui allait se passer. Ça a mené à des burnouts de salariés, à des impressions d’inutilité pour les managers, à une impression de fainéantise pour les dirigeants.
La détente, le retour à une préconisation du télétravail légère a été très intéressant. On a vu que certaines entreprises sont revenues dessus immédiatement, le lundi tout le monde devait revenir au bureau.
On a des entreprises qui sont revenues à un jour de télétravail, puis deux, trois. C’est moins que du télétravail à temps complet, mais ça permet d’ancrer le télétravail.
Il y a aussi le cas où les entreprises ont compris les avantages que ça apporte. Je pense notamment aux entreprises éditrices de logiciels, qui réalisaient qu’elles avaient un marché de développeur, qui n’était plus le marché local des développeurs français, mais le marché mondial, ce qui permettait de recruter de manière mondiale.
Il est un peu trop tôt pour le dire, mais je pense que le télétravail, face à cette épreuve "réelle" a réussi à imprégner beaucoup d’entreprises qui ne s’y serait mis que beaucoup plus tard, peut-être dix ans plus tard, je pense qu’en dix mois on fait ce qu’on aurait fait en dix ans.
Est-ce que c’est souhaitable ? Moi, je ne souhaite pas que les gens soient mal : des burnouts il y en a eu. Les métiers comme les nôtres s’y prêtent très bien, je connais des gens qui font du support technique pour lesquels ça ne se passe pas très bien : les gens ne sont plus sur place, donc c’est parfois plus compliqué.
Donc ça a été des contraintes au début, à la détente elles ont pu réfléchir à tout ça.
Je pense qu’on va sur une pente décroissante à la sortie de l’épidémie, parce que le réflexe de revenir en arrière est simple, mais on a aussi montrer que les entreprises n’allaient pas couler avec le télétravail, et ça va laisser quelque chose dans la tête des gens.
Et la recherche des développeurs, qui est aujourd’hui très difficile, pour les entreprises qui produisent du soft vont continuer à promouvoir le télétravail sur cette population qui veut être mobile, nomade numérique.
Tu indiques que les entreprises vont devoir le promouvoir pour pouvoir recruter. Du coup, est-ce qu’on ne reste pas dans quelque chose qui leur ait imposé indirectement, plutôt que dans une vraie conviction, une vraie volonté de mettre en place du télétravail ? Mais plutôt de dire on met du télétravail parce qu’on n’arrivera pas à recruter de toute façon.
Je vais prendre ma casquette d’entrepreneur.
Une entreprise c’est une suite d’habitudes. Ces habitudes, on les appelle des process, en gros c’est des recettes de cuisine qui disent en gros que pour un livreur, le matin il doit chercher les colis à tel endroit à l’entrepôt, passer à tel endroit, rendre le camion le soir, etc.
Ces process se sont formés face aux échecs de l’entreprise souvent.
Une entreprise apprend beaucoup dans la douleur et le fait qu’elle se retrouve face à une contrainte est assez naturel pour une entreprise, les contraintes légales par exemple.
Ça ne veut pas dire qu’à la fin, ça ne devient pas un composant à part entière de l’entreprise. En effet, c’est un peu vécu comme un traumatisme. Beaucoup de managers ont des problèmes avec le télétravail, freinent des quatre fers, car ils se sentent inutiles. Les développeurs poussent au télétravail pour avoir plus de liberté.
Je pense que tout ça va s’équilibrer, et en effet, je pense que ce qui est une contrainte aujourd’hui pour l’entreprise va s’intégrer dans son ADN si elle est obligée de le faire sur une base régulière, tout simplement parce qu’elle va y trouver un avantage au final.
Donc pour toi c’est une contrainte, mais une contrainte qui peut devenir une culture d’entreprise dans les mois/années à venir, comme le RGPD il y a quelques années, qui est maintenant devenu naturelles.
Dernière question, très ouverte. Tu nous as parlé d’open source. Tu nous as parlé d’open source dans le passé. Tu nous as dit ce que tu avais fait pour contribuer à l’open source, ce que tu as mis en place pour promouvoir l’open source. Maintenant si je te dis : dans un court terme, on va dire deux à cinq ans, si je te demandais comment tu vois l’open source dans deux à cinq ans?
C’est-à-dire quels sont les projets que tu vois émerger, les secteurs que tu vois plus ou moins se développer, tu me répondrais quoi ?
Le premier, on l’a abordé tout à l’heure, c’est le modèle économique de l’open source : on est dans un moment de crise où il va se passer quelque chose. Est-ce que ça va être une évolution des licences de base que l’on connaît comme a tenté Elastic, ressenti comme une trahison par les mouvements "durs" de l’open source ?
Est-ce que ça va être quelque chose de plus ouvert, une meilleure considération des entreprises, par forcément normalisé par une licence ? De nouveaux modèles de contribution économique aux projets ?
Je pense qu’on est à une étape charnière, où l’open source va chercher de nouveaux modèles économiques pour à la fois rétribuer les contributeurs qui sont de plus en plus investis sur des modèles de plus en plus complexes sur des projets de plus en plus importants et centraux.
Récemment avec le cas Log4j, qui a mis en exergue le fait que c’était très peu de développeurs qui maintenaient le paquet, qui a eu plusieurs failles majeures d’affilées. Ça a permis de mettre en avant le fait que ce paquet utilisé par des millions de sites, qui était pourtant maintenu par 3 personnes. L’un des premiers points qui a été abordé, c’est justement sur c’était du développement non rétribué et que c’était des gens qui faisaient ça sur leur temps libre.
Github tente un modèle de rémunération par des récompenses. On peut sponsoriser un développeur. C’est quelque chose qui bouge beaucoup aujourd’hui.
L’open source a beaucoup intégré les entreprises dont on doit trouver une solution et ça va se faire de soi-même, je pense, dans les 5 ans à venir.
L’autre point dans le secteur qui va se développer, c’est évidemment le cloud. Moi-même je travaille maintenant dans des missions où on me demande de travailler sur cinq clouds différents et je ne peux pas le faire comme ça. Je passe par des outils tiers, comme Terraform par exemple.
Dans le domaine du cloud et de son infrastructure, c’était plutôt un domaine où on avait tendance à utiliser plutôt des outils propriétaires liés aux matériels. Maintenant qu’on est dans le cloud, ça va être plus variable, et surtout dans le modèle multicloud. La flexibilité de l’open source va lui permettre de jouer un rôle important.
Le dernier projet qui est lié à l’open source, mais pas directement, c’est tout ce qui est réseau pair à pair. On a eu l’exemple du réseau social Mastodon, qui depuis 2017 s’est bien développé.
On a aussi des projets entiers qui communiquent. Par exemple, on peut faire communiquer Mastodon, qui pour rappel est un clone en logiciel libre qui ressemble à Twitter. On peut le faire communiquer avec d’autres outils, par exemple pour un générateur de site web pour faire un agrégateur de lien.
L’optique est d’éviter la centralisation des plateformes et d’éviter la centralisation TikTok, Facebook, Twitter, etc.
On a quelque chose à jouer. Ça évolue lentement parce que les plateformes trustent les utilisateurs et c’est difficile d’en sortir, mais on a quelque chose à faire.
Effectivement, c’est l’approche que j’ai avec Peertube aussi. C’est justement de montrer qu’un web sans les GAFAM existe, et tu penses vraiment que ce modèle, où on va essayer de s’exfiltrer des GAFAM, où va essayer de reprendre notre propriété sur notre contenu va être quelque chose qui va se développer dans les années à venir du coup ?
Oui ! Je pense que ça va aller lentement.
YouTube est devenu extrêmement sensible aux demandes de censures. Twitter suit le même chemin. Facebook est sans cesse attaqué par les législateurs américains parce qu’il serait trop permissif.
On a beaucoup de modèles, ça s’accélère.
Pour beaucoup de population, il n’existe pas d’alternative au logiciel libre, et je pense que de manière continue, pas forcément rapidement, mais continue, ces alternatives vont continuer à se développer.
Merci pour toutes ces réponses, notamment sur l’avenir de l’open source sur les prochaines années. On se recroisera sans doute sur le journal du hacker. J’espère aussi qu’on se recroisera sur d’autres projets open source, car il y a beaucoup à faire, et comme tu l’as dit, l’avenir se construit autour de l’open source.
Cela fait quelques années que je fais passer régulièrement des entretiens techniques. Dans ce billet, j’ai voulu vous compiler un peu mes astuces/remarques/points (rayez la mention inutile) afin que ces derniers se passent au mieux pour vous.
Comme indiqué dans le titre, ce billet s’adresse plus particulièrement aux profils juniors (sans aucune condescendance), mais chacun peut y trouver des points utiles.
Avant l’entretien
1) Se renseigner sur l’entreprise
Lorsque vous allez en entretien, cela signifie que vous envisagez de rejoindre une entreprise. Le mieux dans ce cas est de vous renseigner un minimum sur celle-ci. Cela passe par le site institutionnel de cette dernière, son (ou ses) blog(s), mais aussi des sites tiers qui permettent d’avoir les avis des employés actuels ou passés.
Cela permet d’avoir un discours pluriel et donc de savoir dans quoi l’on s’engage. Rien n’est pire qu’une entreprise au management toxique par exemple. Eventuellement, cela vous permet aussi de poser des questions supplémentaires lors de l'entretien pour en savoir plus sur l'entreprise.
2) Préparer sa présentation
C’est souvent ma première question en entretien : "J’ai votre CV devant moi, mais j’aimerais que vous m’en parliez vous-même". Non pas que je n’ai pas lu le CV (je lis les CV très attentivement au contraire), mais je veux savoir ce que vous voulez me présenter. La manière dont vous allez présenter votre CV va influencer l’entretien. Pour ma part, c’est ce qui me permet de voir les choses que vous avez réellement travaillées ou les buzzwords présents dans le CV.
De même, de manière assez naturelle, ça va permettre de voir ce que vous considérez comme important ou mineur dans votre expérience. Attention toutefois à ne pas tomber dans la récitation par cœur. Restez naturel, c’est votre expérience, donc la manière dont vous le racontez doit être aussi unique que votre CV l’est.
3) Attention au piège des buzzwords
Il peut être tentant de mettre sur votre CV une flopée de buzzwords de technologies à la mode. C’est en partie ce qui fera que vous serez remarqués.
Attention toutefois, lors de l’entretien technique vous aurez (souvent) quelqu’un avec un bon bagage technique. Son job : déceler le vrai du faux dans ce que vous dites savoir faire.
Un CV trop shiny est suspect sur quelqu’un avec peu d’expérience, et autant se le dire tout de suite, un expert verra en une à deux questions si vous essayez de le baratiner.
Si vous mettez une technologie, un sujet, une méthodologie, vous devez vous attendre à ce qu’on vous demande d’en parler, donc il faut que vous sachiez un minimum en parler, donc n’hésitez pas à réviser vos bases en amont. Tout ce qui est sur votre CV équivaut à une question possible.
4) Identifier les attentes
Si vous avez fait quelques recherches sur l’entreprise (premier point de cette section pour ceux qui n’ont pas suivi), vous savez quelles sont les attentes de l’entreprise. Vous savez donc quels sont les sujets que vous devez maîtriser mieux que d’autres, mais aussi comment orienter votre discours. Comme j’aime à le dire, un entretien est une vente : vous vous vendez à l’entreprise. Vendez donc un produit adapté à l’entreprise. Savoir que vous avez fait de la pêche est sans doute un point que vous avez aimé dans votre carrière, mais est-ce que ça vous apporte quelque chose pour manager un cluster Kubernetes ?
Bonus) Avoir des réalisations à présenter
Je le met en bonus, car ce n'est pas pour moi un vrai prérequis mais plutôt quelque chose qui peut aider à convaincre.
Il peut parfois être pertinent d'avoir du contenu que vous publiez et que vous pouvez partager avec le recruteur. Par exemple, pour ma part, j'ai déjà présenté ce blog.
Il peut aussi s'agir de repository GitHub, de vos contributions à de l'open source, d'intervention dans des conférences, etc.
Il s'agit simplement de bonus, mais c'est un bon élément pour démontrer vos compétences.
Pendant l’entretien
5) Posez des questions
L’entretien technique est aussi l’occasion pour vous, candidat, de mieux connaître l’entreprise. Un entretien va dans les deux sens, vous devez convaincre l’entreprise, mais l’inverse est aussi vrai. Il ne faut pas hésiter à poser des questions, sur le fonctionnement de l’entreprise, le quotidien des personnes au même poste, etc.
Ces questions vous permettront de savoir où vous mettez les pieds, c’est un point tout aussi important que convaincre votre interlocuteur.
6) Prenez des notes
N’hésitez pas à prendre des notes de ce qu’on vous donne comme information, si on vous demande de synthétiser votre réflexion, il ne faut pas non plus hésiter à schématiser : un bon schéma vaut mille mots !
Ce point est d’autant plus important si on vous donne un sujet de réflexion : notez les points que vous identifiez comme important, ça vous permettra de vous assurer de ne pas répondre à côté du sujet.
7) Moins de "Je", plus de "Nous"
Quand vous rejoignez une entreprise, vous rejoignez souvent une équipe, et vous en quittez souvent une autre.
Savoir ce que vous avez fait dans vos précédentes expériences est évidemment important, mais la manière dont vous le présentez l’est tout autant.
Personnellement, je me méfie beaucoup des candidats qui utilise "Je" à chaque phrase plutôt que "Nous". En tant que junior, il est assez rare d’avoir tout fait en solo, il n’y a aucune honte à l’indiquer. Au contraire, cela peut être rassurant de savoir que vous "ne jouez pas perso". Une entreprise, c’est un ensemble de gens qui sont censés aller dans le même sens.
Attention toutefois, le but n'est pas de vous effacer complétement, il est important de savoir ce que vous savez faire de vous même, en solo!
8) "Je ne sais pas" est une réponse acceptable
C’est l’une des premières remarques que je fais en entretien : "Je ne sais pas" est une réponse acceptable. Il n’y a aucune honte à ne pas avoir réponse à tout, au contraire, c’est humain.
Par contre, si vous me dites que vous êtes expert Docker, et qu’une première question de base (par exemple, comment limiter le CPU utilisé par un container) a comme réponse "Je ne sais pas", ce n’est pas forcément rassurant.
9) Parfois, il n’y a pas de bonne réponse
Pour poursuivre le point précédent, parfois, il n’y a pas de bonne réponse. Dans les mises en situation que je fais en entretien, la solution m’importe souvent peu. Ce qui va m’intéresser bien plus par contre est la réflexion qui va mener à l’idée.
Petit exemple, vous me dites que vous allez héberger une solution sur AWS, ma prochaine question va être "Pourquoi AWS, et pas GCP ?". Le but est de comprendre le cheminement qui vous a conduit à ce résultat, pas forcément le résultat en lui-même.
10) Sortez du lot, mais attention
Le but d’un entretien est évidemment de sortir du lot, il faut que vous montriez qu’il vaut mieux vous embauchez vous que quelqu’un d’autre, mais attention, être trop atypique peut aussi jouer contre vous. Le but est que vous rejoignez une équipe, une entreprise et rien n’est pire qu’un électron libre. Sortir du lot, se démarquer est bien, mais il faut savoir où se trouve les limites, se démarquer trop peu aussi effrayer votre employeur potentiel. Restez vous même, tout en fixant éventuellement des limites.
Après l’entretien
11) Faire confiance à son ressenti
Comme je l’ai dit plus haut, un entretien va dans les deux sens. C’est pourquoi il est important de noter aussi son ressenti. Si vous n’avez pas un bon feeling suite à l’entretien, faites vous confiance. Mieux vaut "rater" une opportunité que de s’engager dans une entreprise où l’on ne va pas se sentir bien. C’est un point qu’on sous-estime souvent, mais le mental est aussi important que le salaire que vous demandez.
Être dans une entreprise ayant des comportements toxiques finira par vous peser à un moment ou à un autre… Je sais de quoi je parle à ce sujet.
12) Ne pas hésiter à demander un feedback
Que l’entretien soit positif ou non, il ne faut pas hésiter à demander un retour. Il y a toujours des points sur lesquels on peut s’améliorer, avoir un regard extérieur peut parfois vous permettre de les mettre en exergue.
À titre d’exemple, suite à mes entretiens chez WeScale, voici ce que j’avais eu comme feedback :
La faute de frappe prouve que c'est l'original :)
Je n’ai aucune gêne à les partager, ce sont des points que j’ai accueillis très favorablement. Savoir on l’on a "réussi" l’entretien, mais aussi identifier les axes d’amélioration est primordial pour continuer d’évoluer. Cela permet aussi d’en savoir plus sur ce que l’entreprise a vu suite à vos échanges.
Pour résumer
Un entretien est bidirectionnel, ne l’oubliez pas. Si vous voulez maximiser vos chances, n’hésitez pas à le préparer un minimum.
Il n’est pas nécessaire de connaître l’entreprise sur le bout des doigts, mais simplement de savoir ce qui vous attend en avance.
De même, faites confiance à votre instinct, si vous avez un mauvais ressenti suite à votre entretien, il est peut-être nécessaire de vous demander si c’est ce que vous voulez au quotidien.
Et vous, avez-vous d’autres astuces à partager ? N’hésitez pas à réagir dans les commentaires !
L’année 2022 commence, l’occasion pour moi de vous livrer ma vision des tendances dans l’IT et la sécurité.
Comme souvent dans mes billets, il s’agit de mon avis, et vous avez le droit de ne pas être d’accord avec moi.
Dans tous les cas, n’hésitez pas à donner votre point de vue dans les commentaires, aucune inscription n’est nécessaire.
La part du télétravail va augmenter
On l’a vu depuis le début de la pandémie du Covid, le télétravail permet aux entreprises de continuer leur activité malgré les aléas sanitaires.
Même si c’est encore partagé, de nombreuses entreprises ont dû "lâcher du lest" à ce propos et accepter du télétravail, à minimum partiel.
Cette pandémie a aussi été, pour beaucoup de monde, l’occasion de se recentrer sur ses priorités, et le télétravail offre plus de souplesse pour sa vie privée. Cela va même jusqu’à une part non négligeable de personnes qui quittent leur travail pour faire la même chose ailleurs… mais à distance !
Ce que j’espère, pour ma part, est que cela ne va pas contribuer à la précarisation de nos métiers, en ne voyant dans le télétravail qu’une manière de réduire les coûts.
C’est l’un des points que j’avais remonté en fin d’année.
Aussi, il est encore nécessaire de voir si cela va survivre à la pandémie. Actuellement, beaucoup d’entreprises le font, car elles y sont fortement incitées : si elles ne le font pas, elles recrutent bien plus difficilement. Une fois cette pandémie passée (du moins je continue d’espérer qu’elle va passer), il est probable que les "vieux démons" du présentéisme reviennent. Reste à voir si certains auront compris que leurs équipes sont tout aussi efficaces à distance !
La part de la cybersécurité dans les budgets IT va continuer de grossir
Ces dernières années, la part de budget allouée à la cybersécurité a augmenté dans beaucoup d’entreprises.
Avec une fin d’année mouvementée au niveau de la sécurité, notamment avec les failles log4j, la sécurité des entreprises est revenue sur le devant de la scène.
Le nombre d’attaques ne faisant qu’augmenter d’année en année, il va être nécessaire d’investir massivement dans ce domaine.
Il reste pour moi un principal souci : il n’y a actuellement pas assez de monde formé pour répondre à ce besoin sur le marché. Même si les formations en cybersécurité se développent de plus en plus, il est probable qu’il faille encore quelques années avant de trouver plus facilement de la main-d’œuvre dans ce domaine, ce qui va donc faire encore monter les prétentions salariales/TJM pendant un petit moment.
La blockchain va commencer à se montrer dans les entreprises
Mot bullshit pour certain, l’avenir pour d’autres : la blockchain.
Je ne parle pas ici de ces implications spéculatives (Bitcoin, Etherum et leurs petits copains), mais du protocole en lui-même.
Certaines entreprises ont tenté le coup en cette fin d’année avec des NFT, et certaines ont aussi fait marche arrière devant leur communauté.
Toutefois, la blockchain a pour moi de vrais intérêts dans l’industrie, notamment pour la traçabilité des informations. Par exemple, dans le domaine alimentaire, cela permettrait de tracer de manière fiable la chaine complète d’un aliment, que le consommateur pourrait consulter. L’inaltérabilité et la fiabilité de ce protocole pour stocker un suivi en fait l’enveloppe parfaite.
Je fais partie des gens qui observent encore ce protocole actuellement. Pour ma part, je considère qu’on a aujourd’hui une ébauche de ce que sera la blockchain d’ici quelques années. On le voit avec l’évolution de ce protocole sur les 5 années passées, et je pense qu’il va continuer d’avancer pour être plus rapide, et continuer d’aller vers une sobriété énergétique indispensable à l’avenir de l’humanité.
L’écologie va être un argument commercial
Bon, en vrai c’est déjà le cas avec le greenwashing qui traine ces dernières années.
Toutefois, quand AWS annonce qu’ils vont mettre à disposition le compte rendu énergétique auprès de leur client chaque année et le fait que la "sustainibility" est été intégrée aux piliers d’AWS est une étape dans la bonne voie de mon point de vue.
Maintenant, j’espère que d’autres clouds providers vont emboiter le pas, et surtout que cela va avoir un impact sur le fonctionnement des entreprises.
Savoir l’impact que l’on a est la première étape pour le réduire.
Les IA vont continuer à se perfectionner
Autre mot bullshit ces dernières années : l’IA.
Derrière ce mot, on peut tout cacher, tant que c’est automatique !
Toutefois, pour moi, je vois surtout le machine learning (et le deep learning) qui vont continuer de se développer. Cela fait quelques années que les géants de la tech l’ont compris : l’IA accélère les décisions et sait anticiper les besoins.
Attention toutefois : l’IA reste guidée par ce qu’on lui donne pour apprendre, et peut donc avoir les mêmes biais que les humains.
C’est le résultat d’une expérience d’Amazon il y a quelques années par exemple, en voulant créé une IA pour accélérer le recrutement, basé sur les décisions de leurs recruteurs humains, ils se sont aperçu que le scoring des profils féminin était toujours plus faible.
La raison : les recruteurs rejetaient plus facilement les profils de femmes, donc l’IA a appris depuis ce modèle.
L’IA, c’est aussi le deepfake, les "vous aimerez aussi" des sites Internet, le développement simplifié (avec GitHub CoPilot par exemple) et bien d’autres domaines.
À suivre donc !
Commençons cette nouvelle année !
Voilà donc mes 5 plus grandes prédictions pour cette année. Je ne pense pas avoir pris de gros risques, car ce sont des sujets incontournables pour nombre d’entreprises.
Il ne faut pas oublier l’effet de mode aussi : certaines entreprises vont utiliser des technologies parce que les concurrents ou les bigtech vont le faire. C’est à nous, professionnels de l’IT, de savoir les guider pour éviter ces dérives. Évitons un énième effet Kubernetes partout/Modèle spotify (rayer la mention inutile).
Rendez-vous en 2023 pour voir si j’ai vu juste !
Et vous quelles sont vos prédictions ?
D’accord, pas d’accord, n’hésitez pas à indiquer dans les commentaires vos prédictions pour l’année 2022, il y a sans doute des points que je n’ai pas couverts et votre avis compte aussi !
Je ne vais pas vous faire un énième post pour parler de cette faille, mais plutôt parler de mon expérience sur le terrain sur l’impact de cette dernière au niveau opérationnel.
L’importance d’avoir un inventaire à jour
J’en ai parlé sur Twitter, mais pour moi, cette faille met en exergue le fait que beaucoup d’entreprises manquent d’un inventaire à jour de leurs ressources.
L'asset management est primordial si vous voulez faire de la sécurité!
La faille majeure #log4j le rappelle, il faut patcher vite, mais pour le faire il faut avoir un inventaire à jour!
Encore une fois, le plus important n'est pas forcément l'application ;)
Lorsqu’une faille comme celle-ci se déclare, il est important d’être en mesure d’identifier rapidement quelles sont les ressources en risques. Mais avoir un inventaire à jour ne se limite pas aux machines, mais aussi à leur contenu.
C’est d’autant plus important lorsqu’on exploite la puissance du cloud, avoir des machines volatiles rend d’autant plus complexe leur gestion.
Pour ça il existe plusieurs solutions.
Faire uniquement de l’infra as code
Ce point va sembler trivial à beaucoup d’entre vous, mais faire uniquement de l’infra as code simplifie énormément les choses pour visualiser rapidement ce qu’on déploie, sur quel projet, quelle machine, quel compte, etc.
Dans un pipeline CI/CD c’est le rôle d’un SAST (Static application security testing) de repérer les failles courantes au moment de la compilation des nouveaux projets, toutefois, il faut de l’outillage pour les projets déjà compilés, par exemple, sur GitHub, Dependabot m’a indiqué assez rapidement les projets dans lesquels il avait identifié l’utilisation de la librairie.
Toutefois, ce point n’est clairement pas suffisant. Ce n’est pas parce que je ne définis pas explicitement une librairie qu’elle n’est pas utilisée.
Scanner les artefacts déjà créés
Si vos applications sont déjà compilées, il existe souvent sur vos gestionnaires de librairies des solutions pour scanner ces derniers.
Toutefois, ce n’est toujours pas suffisant. Sur vos serveurs, vous n’utilisez pas forcément que des packages que vous maitrisez et référencez vous-même.
Par exemple, vous pouvez exploiter une image AWS d’un éditeur sur le marketplace, ou avoir des applications tierces déployées dans votre infrastructure.
Scanner en continu vos serveurs
C’est là qu’entre en jeu le troisième niveau de scan : vous pouvez scanner en continu vos machines pour identifier rapidement les serveurs en danger.
Il existe pour cela des outils comme Nessus Tenable ou encore Rapid7 InsightVM. Le rôle de ces outils va être de scanner vos serveurs et vous remonter les machines en risque.
Une simple recherche avec l’identifiant d’une CVE vous permet d’identifier rapidement les serveurs impactés.
Comment j’ai vécu cette étape
Comme beaucoup dans l’infosec ces derniers jours, cette première étape a été compliquée. Même avec de l’outillage, on prend toujours le risque de passer à côté de certaines ressources.
Je travaille dans une petite équipe et nous avons réagi au mieux, mais vu le risque encouru avec cette vulnérabilité, nous refaisons plusieurs contrôles. Ce point est épuisant, car nous devons faire nombre d’actions manuelles, tout n’est pas forcément simplement automatisable.
C’est une étape laborieuse, épuisante (mentalement), mais indispensable et critique.
Une fois les serveurs identifiés je fais quoi ?
Maintenant que je sais quelles sont mes ressources touchées par la vulnérabilité log4j, je fais quoi ?
Première chose qu’on oublie souvent : on ne panique pas !
C’est un comportement que je vois souvent lors d’incidents de sécurité, pourtant il est d’autant plus important de garder la tête froide qu’une erreur peut couter cher !
Patcher, patcher, patcher…
La solution sera souvent la même ici : patcher ou mettre à jour l’applicatif. Néanmoins, à ce jeu, tous les éditeurs ne sont pas aussi sérieux.
Sur ce point, j’ai vu plusieurs comportements :
Les éditeurs très réactifs et transparents sur les risques
Les éditeurs qui indiquent qu’ils ne savent pas (ce qui n’est pas forcément pour me rassurer soit dit en passant).
Les éditeurs qui disent être impactés, mais mettent plusieurs jours à sortir une version avec le fix nécessaire
Ceux qui disent qu’ils ne sont pas impactés pour finalement indiquer le contraire
Ceux qui préfèrent indiquer qu’ils ne sont pas impactés alors qu’ils sont loin de java (par exemple HashiCorp et ses outils écrits en GoLang)
Dépendre d’autres équipes
À mon poste, je ne suis pas celui qui patche, mais dans l’équipe qui va identifier les risques, les mesurer et demander les actions nécessaires aux autres équipes (Dev, Ops, DataOps, etc.)
C’est une posture qui peut être frustrante, car on dépend de gens sur lesquels on n’a aucun pouvoir de priorisation et tout le monde ne perçoit pas forcément les risques de ces failles.
C’est pourquoi il est important d’avoir (une fois de plus) une posture pédagogue, et de bien expliquer les risques et pourquoi il est important de réagir vite.
Et c’est aussi à cette étape qu’il est important de bien tracer toutes les demandes et faire le suivi associé.
L’une des solutions temporaires peut parfois être de mitiguer le risque pour réduire autant que possible l’impact de la lenteur de tiers, cela peut passer : par des règles sur un WAF, des modifications de packages directement sur les machines (même si je ne suis pas fan de cette solution), changer l’exposition de certaines machines (passer des machines derrière un VPN par exemple) ou encore interrompre certains services temporairement.
La solution temporaire dépendant bien entendu de l’évaluation du risque associé.
Comment j’ai vécu cette étape
Comme je l’ai évoqué, j’ai eu un peu de frustration devant la non-réponse de certaines équipes, ou l’impression qu’on s’en f... . Pour certaines équipes, je suis un incident parmi d’autres déjà en cours, et je ne fais que rajouter une pièce dans la machine.
Cette étape n’est pas forcément simple, mais je trouve que cela reste plus simple qu’avoir l’inventaire.
L’après log4j
Pour l’instant la tempête log4j n’est pas encore finie, avec une faille découverte avant-hier à l’heure où j’écris ces lignes.
Investir dans la sécurité
Cette tempête comme d’autres avant elles (Spectre, Meltdown, Heartbleed, etc.) est l’occasion pour les équipes sécurité de rappeler l’importance de certains investissements :
Avoir une équipe sécurité qui se tient à jour
Avoir de l’outillage pour identifier rapidement les failles
Avoir un inventaire à jour
Sensibiliser les équipes à l’importance des bonnes pratiques de sécurité
J’ai même rappelé ce point (sur Twitter une fois de plus) dernièrement :
A tout ceux qui pensent que la #sécurité informatique est un coût... Vous avez tort!
La sécurité est un #investissement, très vite rentabilisé que ce soit sur des attaques évitées ou en image de marque.
C'est ce qui inspire confiance à vos clients/utilisateurs!
Cette faille rappelle la dure réalité des projets open source : beaucoup de projets sont clairement exploités par de nombreuses énormes sociétés qui reposent dessus sans jamais contribuer que ce soit au code ou au moins financièrement.
Log4j est une librairie exploitée par des millions d’applications dans le monde, pourtant elle est maintenue par peu de personnes.
De nombreux Tech gravitant dans l’univers open source ont fait le même constat :
1/7 Depuis le début du week-end, une faille, nommée log4shell et jugée comme la plus importante faille de sécurité de ces 10 dernières années, agite le monde de la tech. L'immense majorité des entreprises de la tech est touchée, allant de Microsoft à Spotify en passant par Tesla. pic.twitter.com/o2gsKeORAy
Cela n’est pas sans rappeler des batailles récentes :
Elastic.co VS AWS
MongoDB VS AWS
Faute de trouver une solution viable, la solution est souvent de passer par la case légale en mettant des clauses empêchant l’utilisation par ces entreprises, car elles exploitent la richesse de ces projets sans jamais rien donner en contrepartie.
Sur les réseaux sociaux, blog et autres publications, on parle très souvent de nos réussites (moi le premier). Aujourd’hui, j’ai décidé de vous parler d’un de mes "échecs" (notez les guillemets) récents : le jour où j’ai compris que je ne faisais pas du bon code.
Résumé d’un drame en trois actes.
Situation initiale : seul au monde
J’ai commencé chez mon client actuel (le groupe SeLoger) en octobre 2019. À ce moment, je remplace quelqu’un de mon ESN (WeScale) qui quitte ce client.
Ma mission consiste a évaluer la sécurité AWS des comptes, puis de proposer des solutions, voire les mettre en place.
L’un des piliers que je propose et développe (en repartant de ce que mon prédécesseur avait fait) est donc de mettre un IAM (Identity and Access Management) fort sur AWS.
Vu mon passé d’Ops/FinOps/Architecte, l’automatisation, la fiabilité et la vitesse d’exécution sont des critères importants.
De même, je ne veux pas créer un gouffre entre les équipes DevOps et moi et j’ai donc besoin d’un outil que tout le monde (ou presque) puisse prendre en main.
J’ai donc développé plusieurs outils, principalement en python, dont le job principal est de déployer des permissions et de faire des liens avec des utilisateurs, de manière automatisée.
Je commence donc l’onboarding des applications, et de 25 repositories exploitant ces permissions, on arrive au bout d’un an à plusieurs centaines.
C’est là que les choses commencent à se gâter…
L’élément perturbateur : le scaling
Je commence à percevoir les limites de ce que j’ai mis en place :
Les permissions IAM ne sont pas optimisées, et sont parfois redondantes
Je tape parfois des limites de tailles de policies AWS suite au point précédent (J'en ai d'ailleurs parlé dans le passé)
Le déploiement des droits utilisateurs tombe parfois en timeout (et dure plusieurs heures !)
Je dois ajouter des fonctionnalités, mais mon script est devenu un gros tas de scotch au fur et à mesure des patches
De là, mon constat : un refacto est nécessaire. Si je veux pouvoir continuer d’ajouter des fonctionnalités quand les nouveaux besoins se manifestent, il me faut une base de code remise à plat.
Je défends donc cette idée auprès de mon manager (client) qui comprend effectivement l’intérêt et me donne donc le go pour faire ce travail.
Tout seul, on va vite, ensemble, on va loin
Nous sommes à ce moment en octobre-novembre 2020. Ce refacto est donc dans mon backlog, et il est prévu que je m’attarde dessus fin décembre/début janvier.
Au début de l’année, du renfort qui arrive. Un de mes collègues de WeScale arrive sur la mission pour me prêter main forte. Ce dernier a un bagage plus teinté développeur, là où j’ai un bagage très teinté Ops de mon côté.
Je lui présente donc un peu ce que j’ai fait, et je perçois assez vite qu’il voit des choses complexes ou qui ne sont pas à l’état de l’art.
J’essaie de le rassurer en lui disant que je travaille sur une remise au propre de tout ça pour repartir sur des bases saines.
Je travaille donc sur mon refacto, et assez vite, je lui soumets donc en code review mon code. J’échange avec lui en partageant la PR, et là, je me rends compte que la réaction n’est pas celle que j’attendais.
En effet, en échangeant avec lui, je perçois que ça reste bien trop complexe, et pas vraiment "clean", même sur ma nouvelle version.
Sur le coup, mon ego en prend un coup, et je me braque un peu. C’était en soirée, on arrête là, en se disant qu’on en reparlera au calme le lendemain.
Bien entendu, le soir, je cogite. Je me rends assez vite compte qu’il n’a pas tort : je ne suis pas un développeur. C’est le constat que je fais, jusqu’à présent, j’ai scripté des choses pour répondre à des besoins, mais je n’ai jamais vraiment développé.
Le lendemain, en discutant, je lui explique donc ce point : j’ai besoin d’aide pour savoir ce que je dois (re) voir. S’en suit une (très) longue discussion dans lequel il m’expose certains points qui pour lui ne vont pas :
Mon code est un seul script, ce qui empêche de l’étendre facilement
Le code est dans le même repository que la configuration des projets, ce qui ne lui permet pas d’avoir son cycle de vie propre
En l’état, on ne peut pas tester ce que j’ai fait
Le découpage de mon code n’est pas clair, certaines fonctions ont une complexité trop élevée
Une fois de plus, grosse claque pour l’ego, bien que les propos soit bienveillants, ce que j’entends c’est "ton code c’est de la merde" (ce qui n’était pas du tout le discours de mon collègue).
Le dénouement : apprendre à développer
Je n’ai pas de honte à le dire, ça a été une période assez violente pour moi, j’ai en effet dû appréhender beaucoup de concepts de développement assez rapidement :
Structurer physiquement mon code (structure des répertoires)
Structurer fonctionnellement mon code (logique du code)
Apprendre à packager proprement
Apprendre la base des tests unitaires
Basculer sur une logique d’objet
Revoir l’algorithmie
Et j’oublie sans doute des sujets. De plus, je suis donc dans une grosse remise en question sur la qualité de mon travail.
L’autre point que j’ai dû apprendre est de faire du développement "partagé", que quelqu’un d’autre doit être en mesure de comprendre/reprendre. Jusqu’à présent, bien que je sois en équipe, je développais souvent pour les besoins de mes projets, en solo.
La semaine suivante, je relivrais une préversion de mon script, qui était devenu entre temps une vraie application python, avec son repository, son pipeline de test, des precommit, et un push sur un Nexus du paquet final.
J’ai senti dès lors que le positionnement de mon collègue avait changé. Déjà, nous avions validé ensemble (dans les grandes lignes) la logique du code, ce qui faisait que l’ensemble était de fait plus lisible. Ensuite, j’avais aussi pris en compte au maximum ses remarques, et j’avais même poussé certains points plus loin que ce qu’il m’avait indiqué.
La structure même du code était, même pour moi, bien plus pertinente, et je pouvais voir facilement comment l’étendre en fonction des besoins.
Après quelques aller-retour sur des points qu’il avait remarqués (wording, algorithme, axes d’amélioration du code, etc.), ma PR était validée, et nous poussions la nouvelle version de l’application (dont 95 % du code avait changé) en production.
En conclusion : ce que j’ai appris
Pour conclure ce billet, je dirais que l’un des points les plus importants que j’ai appris durant ces derniers mois, c’est qu’il n’y a pas de honte à ne pas savoir. Pour ma part, je suis dans une démarche d’amélioration continue, et j’aime apprendre de nouvelles choses. Je considère que c’est une grosse partie de la richesse de nos métiers : nous n’avons jamais fini d’apprendre.
De plus, j’ai aussi compris qu’on ne s’improvise pas développeur, il y a beaucoup de concepts à appréhender :
Lisibilité du code
Testing
Algorihmie
Complexité
Documentation
Développer aujourd’hui, mais préparer demain en ayant un code potentiellement extensible
Ce sont des points sur lesquels je suis encore en train de monter en compétence (notamment la partie test qui est loin d’être simple pour quelqu’un qui débute).
De plus, cela a changé aussi ma manière de développer, je commence à avoir le réflexe de créer quelques tests avant d’écrire le code associé, je découpe beaucoup plus mon code en petites fonctions atomiques qui n’ont qu’un rôle bien défini, j’essaie d’utiliser des structures optimisées en fonction de mon besoin et j’en passe.
Enfin, l’un des points importants est que la critique peut parfois faire mal, mais c’est ce qui permet d’avancer. À ce sujet, je partage d’ailleurs beaucoup de choses remontées sur le blog jesuisundev par Mehdi Zed :
J’espère que ce billet vous a plu, et n’oubliez pas : l’échec, même temporaire, n’est pas une fatalité, c’est en faisant des erreurs que j’ai le plus appris pour ma part ! En soi, le code que j’avais fourni à l’origine n’était pas catastrophique, il répondait à mon besoin à l’instant T, mais il ne permettait pas de répondre aux besoins futurs.
Aujourd’hui, quand je regarde le code que j’ai fourni ces derniers mois, je sens bien que je ne suis plus au même niveau, et j’avoue que suis fier d’arriver un livrer un code bien plus propre et maintenable.
Dernièrement Facebook a eu un incident majeur et a disparu du net pendant plusieurs heures.
Les réactions que cela a suscitées, dans la sphère technique, m’ont quelque peu surpris, donc nous allons parler dans ce billet des pannes chez les big tech.
Par big tech, j’entends ces boites que l’on pense bien trop grandes pour avoir le moindre incident visible de l’extérieur.
Facebook : Tu me vois, tu me vois plus !
Facebook a rencontré un incident réseau impressionnant et très simple en même temps. Une erreur de manipulation a conduit à la suppression des routes BGP vers Facebook.
Ce sont ces routes qui permettent d’indiquer à Internet comment arriver à Facebook.
L’incident peut sembler anodin, mais repropager des routes BGP peut prendre du temps, surtout pour une infrastructure de la taille de Facebook.
Point ayant empiré la situation : Facebook ayant perdu son réseau, il était nécessaire d’aller en datacenter pour accéder aux machines, datacenter qui était impossible d’accès vu qu’il nécessitait un accès réseau pour l’authentification.
We’ve done extensive work hardening our systems to prevent unauthorized access, and it was interesting to see how that hardening slowed us down as we tried to recover from an outage caused not by malicious activity, but an error of our own making.
AWS : Une erreur de configuration Kinesis plonge Internet dans le noir
J’en avais parlé sur ce blog à l’époque, AWS a rencontré en fin d’année dernière un incident majeur, suite à l’ajout de stockage sur leur moteur Kinesis, pour les usages internet (IAM notamment), un incident majeur a paralysé une énorme partie d’Internet pendant plusieurs heures.
The new capacity had caused all of the servers in the fleet to exceed the maximum number of threads allowed by an operating system configuration. As this limit was being exceeded, cache construction was failing to complete and front-end servers were ending up with useless shard-maps that left them unable to route requests to back-end clusters
Vu de l’extérieur, l’incident semble assez bête en fait, un problème de dimensionnement des machines qui a conduit à une indisponibilité mondiale.
Google GCP : Je ne te connais pas
Quelques semaines après l’incident AWS, Google rencontre aussi un incident majeur : l’authentification de l’ensemble de ses applications ne répond plus.
Que ce soit YouTube, GCP, Google Workspace, plus aucun utilisateur ne parvient à se connecter.
De par l’intégration des services de Google un peu partout, l’impact a été visible par beaucoup de monde.
Une fois de plus, l’entreprise a été transparente sur la cause de cet incident dans son communiqué de presse :
Google uses an evolving suite of automation tools to manage the quota of various resources allocated for services. […] An existing grace period on enforcing quota restrictions delayed the impact, which eventually expired, triggering automated quota systems to decrease the quota allowed for the User ID service and triggering this incident.
Azure AD et les incidents distribués
En septembre/octobre 2020, Azure AD a rencontré un incident rendant le service d’authentification de Microsoft inaccessible (en grosse partie).
La root cause : une double anomalie, un package en test (slow ring) déployé en production, et un déploiement en parallèle sur l’ensemble des serveurs au lieu de le déployer en rolling update.
Azure AD is designed to be a geo-distributed service deployed in an active-active configuration with multiple partitions across multiple data centers around the world, built with isolation boundaries. Normally, changes initially target a validation ring that contains no customer data, followed by an inner ring that contains Microsoft only users, and lastly our production environment. These changes are deployed in phases across five rings over several days.
In this case, the SDP system failed to correctly target the validation test ring due to a latent defect that impacted the system’s ability to interpret deployment metadata. Consequently, all rings were targeted concurrently. The incorrect deployment caused service availability to degrade.
Pourquoi tu me parles de ces incidents ?
La bienveillance : connait pas
Dans un premier temps, j’ai constaté que la bienveillance de beaucoup de communautés techniques disparaît lorsque l’on parle des GAFAM. Sans en être un grand fan, je n’oublie pas que ce sont des femmes et des hommes comme mes collègues et moi qui sont derrière. Beaucoup sont passionnés par leur travail et le niveau requis pour rentrer dans ces entreprises est loin d’être anodin.
Pour autant, nombre de messages sur les réseaux sociaux considéraient que c’était "amateur" que d’avoir ce type d’incident.
Pour avoir connu nombre d’incidents majeurs dans ma carrière, parfois, il ne s’agit pas d’incompétence, mais d’un concours de circonstances imprévu et difficilement prévisible !
Personne n’est too big to fall
Point intéressant à retenir, même des colosses comme les GAFAM rencontre des incidents impactant. La différence majeure pour moi reste le facteur d’échelle : chez les GAFAM, l’incident est directement très visible.
Personnellement, je trouve cela rassurant de se dire que même ces boites aussi énormes rencontre des incidents somme toute assez classiques.
Les entreprises valorisent leurs erreurs
Pour chacun de ses incidents, on a pu constater un post mortem clair et transparent sur ces derniers. Permettant ainsi de mieux appréhender la portée de ces anomalies et pourquoi leur résolution à parfois pris du temps.
Mais on voit aussi que les entreprises communiquent de suite sur la manière dont elles vont éviter que cela se reproduise.
Le poids du legacy
Le legacy, cette dette technique éternelle que l’on voit dans toutes les entreprises (ou presque). Il serait idiot de penser qu’il n’y a pas de legacy ou de manque de documentation chez les GAFAM.
Quand bien même ils ont des processus bien huilés (en tout cas en public), comme toutes les boites, ils ont un historique et des composants qui sont anciens et/ou mal documentés.
La différence majeure étant le facteur d’échelle, du legacy chez Microsoft n’a pas le même poids que chez une entreprise de taille plus modeste.
En conclusion
Ce billet a avant tout pour but de mettre un peu en avant ces incidents et la toxicité de certaines communautés Tech autour de ces derniers.
Les GAFAM ne sont pas invincibles et rencontre des incidents d’exploitation comme toutes les entreprises. D’un côté, je dirais même que c’est rassurant de se dire que cela leur arrive aussi !
Connexion
