Blog

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.

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 :

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.

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.

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.

Quand nous subissons des erreurs HTTP, il est quand même plus agréable d’avoir des pages « corporate » plutôt que les tristes pages blanches avec un gigantesque 4xx / 5xx. Cela permet de mieux informer l’utilisateur final de ce qu’il s’est passé et ce qu’il peut faire pour gérer le cas. Habituellement, c’est le rôle du serveur web de délivrer ces pages d’erreurs. Mais quand il n’y a plus de serveur web pour fournir la moindre page, comment fait-on ?