Blog

Arrivé à la fin des années 2000, le DevOps est l’un de ces termes qui ont explosé dans le marché de l’IT Web. Depuis, il semble avoir convaincu les entreprises, au point où une majorité en font ou pensent à en faire¹. Dès lors, vu la foule d’offres d’emplois DevOps et l’explosion des salaires², nous autres techniciens y pensons forcément : Comment prendre le train du changement ? Autrement dit, comment devenir DevOps ? Nous allons voir ça.

J’ignore si tous mes confrères et consœurs indépendantes font pareil, mais en tant qu’entrepreneur, je construis les choses doucement, en fonction de ma double contrainte « cadre temps / cadre argent ». En conséquence, même si je me fixe un cap, les événements n’apparaissant jamais de façon spectaculaire et il est difficile de les voir survenir. Pas le temps de s’arrêter, il y a toujours de nouvelles briques à ajouter à notre construction ; comme le disait Audiard : « Un intellectuel assis va moins loin qu’un con qui marche », alors je marche.

Passé la toute première connexion (et le potentiel TOFU), l’usage de SSH est lié à un utilisateur : c’est l’utilisateur qui cherche à se connecter pour faire ses opérations sur le serveur distant.

Pour cette connexion, on connaît habituellement deux options : le mot de passe et la clé SSH, mais puisqu’un mot de passe ne sera jamais aussi sécurisé qu’une clé SSH, on favorise cette dernière. Mais même elle a des défauts notables.

Un serveur virtuel (ou vhost) est une fonctionnalité offerte par les logiciels de serveur Web permettant de répartir sur un seul serveur applicatif une ou plusieurs applications. C’est peu ou prou le socle d’un reverse proxy : offrir un point d’entrée unique pour protéger l’accès des vraies applications.

La configuration d’un tel vhost n’oppose aucune difficulté, mais cette configuration ne suffit pas pour le routage. Comme le dit si bien la documentation d’Apache :

Dans l’illustration de l’article « À quoi joue la sécurisation d’un système d’information », quelque chose a dû vous surprendre : passé la deuxième colonne de classe de caractères, il est plus long de déchiffrer un mot de passe lorsqu’on descend d’un cran vers le bas plutôt que quand on avance d’un cran vers la droite. Autrement dit, il est plus sécurisant de rallonger notre mot de passe plutôt que de le rendre plus complexe. Mais alors pourquoi ? Cela voudrait-il dire que quand il s’agit de mot de passe, la taille ça compte ?

Personnellement, rsync me fascine. Au premier regard, c’est une simple copie à travers le réseau, mais sous le capot c’est plus que ça : s’il a écrasé tous les autres sur le même secteur, c’est parce qu’il fait de la synchronisation différentielle. C’est ça sa killer feature.

À l’ère où nous avons des réseaux de diverses bandes passantes et des fichiers de toutes tailles, un mécanisme de transfert intelligent comme celui de rsync est bienvenu. Au lieu de copier tous les fichiers et gâcher de précieuses ressources, il sélectionne les fichiers qui doivent être transmis pour mener au résultat visé, le clonage parfait des deux répertoires de travail.

L’une des règles les plus importantes en sécurité, c’est de ne pas ignorer les alertes. Prenons un exemple de la vie de tous les jours : imaginons que votre activité se porte bien et que votre administrateur système ajoute un serveur à l’infrastructure. Un jour, vous tentez de vous y connecter et vous tombez sur le message suivant :

> ssh ca.redwatch.io

The authenticity of host 'ca.redwatch.io (172.18.0.3)' can't be established.
RSA key fingerprint is SHA256:JlEdkzIPBxqBZ95UZ/fBAwtWhJlj8NQtXseDRd+5V+o.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

La plupart d’entre nous a appris à ignorer cette alerte et à valider, un peu comme des CGUs barbantes à l’inscription d’un service. Cette validation sans plus de précaution a un nom, elle s’appelle le TOFU (ou Trust On First Use). Et si c’était grave ? Et si, en réalité, nous faisions confiance à la mauvaise personne ?

Quand on programme, arrive un moment où une situation de répétition survient. Dans ce cas-là, se pose la question « récursion vs itération » : autrement dit, doit-on voir cette répétition comme une séquence à recommencer ou comme un problème constitué de lui-même ? C’est un choix très personnel, basé entre autres sur l’aisance du développeur avec la pratique et ce qu’il y projette (soyons honnêtes, nous sommes sujets à des biais).

La sécurité de l’information est comme le jeu du chat et de la souris. Du point de vue de la souris, l’objectif du « jeu » est sa survie, mais pas de n’importe quelle façon : elle n’est biologiquement pas armée pour distancer le chat, donc son but est de trouver une cachette le plus rapidement possible pour échapper à son poursuivant.

En IT, à quel jeu joue la cible des attaques ? Elle souhaite empêcher les récupérations malveillantes de son information, mais comme pour la souris, comment ça se traduit ? Elle pourrait tout barricader, partout, contre tout. Mais au-delà de l’impossibilité de penser à toute situation actuelle ou future, ça représente un coût infini.

Le sujet du versionnement et les erreurs induites par semver m’importe, ça n’a pas dû vous échapper depuis la publication du billet Oubliez ce que vous pensez savoir sur semver. C’est pour cette raison que j’ai repris la conception d’un outil que j’avais commencé il y a 5 ans : checkbreak. Comme je l’évoquais, le problème de semver est le défaut de connaissances du responsable de la release, qu’il soit théorique ou conjoncturel. C’est donc ce que checkbreak vise à palier : expliquer ce qu’est une rupture de compatibilité et où la trouver pour faciliter le versionnement.