Blog

En programmation orientée objet, les participants de l’environnement sont représentés comme des encapsulations autonomes décrivant complètement les attributs et les comportements du sujet. Ainsi, sans que ce soit un prérequis absolu à la POO, il est pratique de faire hériter des objets d’autres pour éviter la répétition ; on dit alors que l’objet A est fils de l’objet B. Seulement voilà, il arrive qu’en réalité A n’est pas vraiment un fils de B. Comment reconnaître ce cas, en quoi c’est grave et comment régler le problème ?

Combien cat consomme en mémoire vive ? Cette consommation croît-elle avec la taille du fichier ? Ces questions peuvent paraître triviales, mais posez-vous la question de la fréquence où vous utilisez cet outil… et la fréquence où vous vous interrogez sur le poids du fichier que vous faites ingérer à cat. On ne se pose tout simplement pas la question, précisément parce que l’outil ne bronche pas ; tout passe, et sur toute machine. C’est génial, mais alors pourquoi ?

Il existe une diversité de systèmes de numérotation des logiciels, du plus simple (n+1) au plus exotique (suivant les décimales de Pi). Dans le lot, semver décrit une numérotation en trinôme M.m.p où M représente des changements non rétro-compatibles, m représente des changements rétrocompatibles et p représente des correctifs. Puisque chaque système vise à bien communiquer aux consommateurs, semver semble la solution parfaite.

Semble seulement, car en fait cet idéal de communication parfaite n’est pas atteint ; le problème est la nature d’un changement rétro-incompatible. Dans la théorie, une rupture de compatibilité est simple : il s’agit d’une possibilité enlevée au consommateur.

Une architecture réseau digne de ce nom applique le principe de moindre privilège : chaque réseau est de préférence isolé et spécifique à un usage. Mais parfois, il existe des serveurs à mi-chemin entre deux réseaux, comme par exemple un serveur web1 devant accéder à son propre réseau « web », mais également au réseau « backend ». Dans ce cas, nous devons mettre en place un routage.

Pour un contexte aussi simple, le routage le plus rapide et le plus pratique est le routage statique. Pour en créer un de toute pièce, imaginons donc que nous ayons une topologie de réseau comme suit :

Si vous avez lu le billet évoquant le chiffrement at rest, une question a dû vous traverser l’esprit : si une table chiffrée ne permet pas sa recomposition, comment la migrer légitimement sur un autre serveur ?

Afin de garantir l’intérêt du chiffrement au repos et se prémunir d’un accès au disque, un accès logique au serveur MySQL est nécessaire à tout transfert. La commande MySQL qui permet cet export est :

FLUSH TABLE utilisateurs FOR EXPORT

Grâce à elle, nous allons pouvoir répéter le processus du billet précédent (structure -> discard -> import), à la différence que nous avons désormais des informations clés pour poursuivre.

Dans le billet Qu’est-ce-que c’est le streaming à débit adaptatif ? nous avons vu en quoi l’assouplissement des contraintes de qualité était primordial pour l’universalité du streaming.

Rentrons maintenant dans la technique. Dans le streaming simple, le fichier est découpé en segments (ou chunks) de telle sorte que le fichier global n’a pas besoin d’être téléchargé entièrement pour commencer la lecture, uniquement le segment. Ce sont ces éléments qui sont placés dans le buffer.

… et pourquoi c’est nécessaire ?

La qualité de nos fichiers multimédia augmente avec le temps, c’est indéniable. Nous étions à 480p au début d’Internet, à 720p il y a peu, et désormais en 4k. Forcément, le poids augmente en conséquence : la prochaine évolution, la 8k, pèse un poids estimé à 589Mo par minute.

Nous savons tous intuitivement comment ces fichiers multimédia se lisent sur Internet : la vidéo se bufferise et si le préchargement avance plus vite que la lecture de la vidéo, tout roule. Sinon ça mouline :

Lorsqu’on produit une pile technique avec plusieurs environnements, nous devons variabiliser les configurations de nos outils pour différencier les contextes d’exécution. Pour cela, comment procède-t-on ? Est-on condamné à créer autant de fichiers que d’environnements (ex: mysql.{local,testing,prod}.cnf) pour ne téléverser et n’exploiter que le bon ?

Ça pose des problèmes évidents, dont le plus grave est que vous ne verrez que le fichier X est mauvais qu’au moment de l’utiliser, donc après son déploiement, pas avant.

Dans l’article précédent, nous avons vu qu’une table non chiffrée « at rest » pouvait être considérée comme librement accessible : la facilité avec laquelle nous l’avons piraté était insolente.

Chiffrer une base de données MySQL 8 au repos signifie que le chiffrement se fait de façon totalement transparente : les données en clair ne sont qu’en RAM, les fichiers sur le disque sont chiffrés avant écriture, et déchiffrés avant lecture. La consommation habituelle reste inchangée.

En tant que base de données, MySQL est un composant sensible d’une pile technique, il est donc important de le protéger des attaques. Le chiffrement au repos (dit aussi « data at rest » ou « Transparent Data Encryption ») est l’un de ces mécanismes de protection, permettant de se prémunir d’un vol de disque.

Nous verrons bientôt comment mettre en place ce chiffrement au repos d’un serveur MySQL, mais avant cela, voyons plutôt pourquoi cette protection est importante. Pour ce faire, nous allons nous mettre dans la peau d’un pirate informatique attaquant un serveur MySQL 8.