Séparation par réseaux Docker :

• Le conteneur mariadb (DB) est uniquement rattaché au réseau db_net (IPv4 : 172.21.0.3)
• Le conteneur php est connecté aux deux réseaux (dmz et db_net) afin de servir l'application web et d'accéder à la DB
• Le conteneur nginx est uniquement sur le réseau dmz, empêchant tout accès direct à la base de données

Configuration dans docker-compose.yml (web) : voir fichier docker-compose.yml

Test depuis le conteneur nginx :

• Un ping vers mariadb échoue ✗ (isolation confirmée)

Test depuis le conteneur php :

• Le ping vers mariadb réussit ✓ (accès autorisé)

• Création de l'utilisateur non privilégié via le fichier user.sql
• Configuration de résolution DNS : utilisation du fichier my-resolve.cnf pour désactiver la résolution des noms
• Montage du volume my-resolve.cnf dans le docker-compose
• Sécurisation des credentials : utilisation d'un fichier .env pour éviter d'afficher les mots de passe en clair

Vérification des privilèges :

• L'utilisateur peut exécuter SELECT ✓
• L'opération INSERT est refusée ✗ (privilèges limités confirmés)

Dans le fichier docker-compose.yml, nous déclarons un volume externe monté sur /var/lib/mysql, où est stockée la base de données.

Caractéristiques :

• La directive external: true indique que ce volume est géré en dehors de Docker Compose
• Le volume existe déjà sur l'hôte
• Avantage : Même si nous supprimons et reconstruisons le conteneur, les données contenues dans ce volume seront conservées

Commande :

docker logs [id du docker mariadb]

Cette commande permet d'afficher les logs en temps réel du conteneur MariaDB pour le monitoring et le débogage.

Génération effectuée avec les outils OpenSSL standard.

Problématique identifiée : Le certificat auto-signé n'étant pas validé par une autorité de certification reconnue, le navigateur affiche une alerte indiquant que la connexion n'est pas sécurisée.

Explication :

• Le certificat n'est pas digne de confiance
• L'authenticité du site ne peut pas être garantie
• Cela met en évidence l'importance des autorités de certification (CA) dans l'écosystème PKI

Fichier nginx.conf :

• Utilise un certificat et une clé fournis par Let's Encrypt
• Garantit l'authenticité du site
• Les directives ssl_certificate et ssl_certificate_key pointent vers les fichiers de certificat
• Redirection automatique : les serveurs configurés sur le port 80 redirigent automatiquement les requêtes HTTP vers HTTPS

Résultat : Toutes les connexions se font de manière sécurisée.

Examen des logs /var/log/letsencrypt/letsencrypt.log :

Les éléments suivants devaient être identifiés :

• Les trois challenges ACME proposés par Let's Encrypt
• Le token utilisé
• La configuration nginx temporaire utilisée par certbot pour répondre au challenge
• L'URL où se trouve le token sur le serveur nginx
• La composition du certificat reçu
• L'emplacement des fichiers du certificat et de la clé privée générées par certbot

Note : Les logs temporaires ne sont plus disponibles suite à un redémarrage récent.

Changements apportés :

• Ajout des clés SSL
• Ouverture du port 443

Vérifications effectuées :

• Le site web possède un certificat signé par Let's Encrypt
• Le certificat est accepté par le navigateur
• Examen avec OpenSSL : identification des champs de signature du CA dans les "Signature Algorithm"

Site concerné : blog.l2-2.ephec-ti.be

Problème identifié : Avec un certificat ne couvrant que www, le sous-domaine blog n'est pas compris dans la couverture certificat.

Solution proposée : Utilisation d'un certificat wildcard pour couvrir à la fois :

• www.l2-2.ephec-ti.ephec.be
• blog.l2-2.ephec-ti.ephec.be

Preuve de fonctionnement : On peut observer sur le certificat la présence du caractère * devant .l2-2.ephec-ti.be, ce qui confirme l'utilisation du wildcard.

Avantage : Ce certificat couvre tous les sous-domaines du domaine principal.