Sécurité Cloud Computing et IoT
TP 2 : Sécurité des Applications Cloud
IoT sur OpenStack
Présenté par :
Encadré par :
Khatib Oumkeltoum
Pr. Fatima-ezzahra Ziani
Jaida Marwa
Année Universitaire : 2025-2026
Sommaire
1 Introduction 3
2 Réalisation du TP 3
2.1 Pré-requis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Initialisation de l’environnement OpenStack . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Chargement du contexte d’authentification . . . . . . . . . . . . . . . . . . . . 4
2.3 Réseau et Security Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Inventaire initial du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Création du réseau iot-net . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3 Configuration des Security Groups : politique minimale . . . . . . . . . . . . . . 8
2.4 PKI locale et certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 Création de la CA locale sur le nœud controller . . . . . . . . . . . . . . . . . . 11
2.4.3 Génération du certificat serveur (exemple : iot-gw) . . . . . . . . . . . . . . . . 12
2.4.4 Génération du certificat client (exemple : device001) . . . . . . . . . . . . . . . 12
2.4.5 Préparation avant le lancement de la VM . . . . . . . . . . . . . . . . . . . . . 12
2.5 Lancement de la VM iot-gw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.1 Vérification de la VM et des ports réseau . . . . . . . . . . . . . . . . . . . . . 14
2.5.2 Analyse du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Conclusion 14
1 Introduction
Avec la généralisation des architectures Cloud et la montée en puissance des systèmes de l’Internet
des Objets (IoT), les infrastructures informatiques modernes sont devenues de plus en plus distribuées,
interconnectées et exposées. Cette évolution technologique, bien qu’elle apporte une grande flexibilité et
une forte capacité de montée en charge, entraîne une augmentation significative de la surface d’attaque.
Les services Cloud sont désormais accessibles via Internet, interagissent avec de multiples composants
logiciels et matériels, et traitent des données souvent sensibles, ce qui en fait des cibles privilégiées pour
les attaques informatiques.
Les plateformes Cloud, telles que OpenStack, offrent un environnement robuste et modulaire pour le
déploiement d’applications distribuées et de services IoT. Toutefois, leur richesse fonctionnelle implique
une configuration de sécurité rigoureuse et cohérente à plusieurs niveaux. La gestion des identités et des
accès, la segmentation et le filtrage réseau, la protection des machines virtuelles ainsi que la sécurisation
des communications applicatives constituent des éléments essentiels pour garantir la confidentialité,
l’intégrité et la disponibilité des services déployés. Une mauvaise configuration ou une absence de
contrôle à l’un de ces niveaux peut compromettre l’ensemble de l’infrastructure.
Dans le contexte spécifique de l’IoT, les enjeux de sécurité sont encore plus critiques. Les équipements
connectés sont souvent contraints en ressources et utilisent des protocoles de communication légers, tels
que MQTT, conçus pour l’efficacité mais nécessitant des mécanismes de sécurité complémentaires. Les
risques sont notamment amplifiés par :
— l’exposition d’API sur Internet ;
— l’utilisation de protocoles de communication légers, tels que MQTT ;
— la gestion des certificats numériques et des identités des équipements ;
— la complexité du dataplane réseau, notamment les mécanismes OVS/OVN et VXLAN.
Dans ce contexte, ce travail pratique vise à mettre en œuvre et à valider les mécanismes fondamentaux
de sécurité Cloud et IoT sur une infrastructure OpenStack composée d’un nœud controller et d’un nœud
compute. L’accent est mis sur l’application de bonnes pratiques de sécurité, notamment en matière de
segmentation réseau, de contrôle d’accès, de chiffrement des communications et d’authentification par
certificats. La démarche adoptée repose également sur la production de preuves techniques concrètes,
telles que les sorties de commandes, les configurations réseau et les vérifications du dataplane, permettant
de démontrer l’efficacité des mécanismes déployés.
2 Réalisation du TP
2.1 Pré-requis
Les pré-requis nécessaires à la réalisation de ce travail pratique sont déjà satisfaits avant le démarrage des
manipulations. L’infrastructure OpenStack utilisée est opérationnelle et correctement configurée.
L’accès distant aux deux nœuds de l’architecture, à savoir le nœud controller et le nœud compute, est
assuré via le protocole SSH, avec des privilèges administrateur (sudo). Cela permet l’administration des
services OpenStack ainsi que l’analyse du dataplane réseau.
Les services essentiels d’OpenStack, notamment Keystone pour la gestion des identités et Neutron pour la
gestion du réseau, sont fonctionnels et correctement interconnectés. Les mécanismes d’authentification,
d’autorisation et de création de ressources réseau sont ainsi disponibles.
Enfin, les fichiers d’environnement OpenStack (openrc), en particulier le fichier [Link],
Figure 1 – [Link]
sont configurés et utilisés pour charger le contexte d’authentification administrateur. Ceci garantit l’exé-
cution correcte des commandes OpenStack nécessaires à la mise en œuvre des différentes étapes du
TP.
2.2 Initialisation de l’environnement OpenStack
2.2.1 Chargement du contexte d’authentification
Avant toute manipulation des ressources Cloud, il est nécessaire de charger l’environnement OpenStack
afin de définir le contexte d’authentification et d’autorisation. Cette étape repose sur l’utilisation du fichier
d’environnement [Link], qui permet de configurer les variables nécessaires à l’exécution
des commandes OpenStack avec des privilèges administrateur.
La commande suivante est utilisée pour charger l’environnement :
source [Link]
Une fois l’environnement chargé, la validité de l’authentification est vérifiée par la génération d’un token
OpenStack :
openstack token issue
Cette commande permet de confirmer le bon fonctionnement du service d’identité Keystone ainsi que la
validité des informations d’authentification fournies.
Figure 2 – Service d’identité
Enfin, la liste des endpoints des services OpenStack est consultée afin de s’assurer de la disponibilité des
services nécessaires, notamment ceux liés à l’identité et au réseau :
openstack endpoint list
Figure 3 – Endpoint List
2.3 Réseau et Security Groups
2.3.1 Inventaire initial du réseau
Cette étape consiste à réaliser un état des lieux des ressources réseau existantes dans l’environnement
OpenStack avant toute création. Les commandes suivantes ont été exécutées afin d’identifier les réseaux,
sous-réseaux, routeurs et adresses IP flottantes déjà présents :
openstack network list
openstack subnet list
openstack router list
openstack floating ip list
Figure 4 – Invetaire du réseau
Les sorties de ces commandes ne présentent aucune ressource réseau existante. Les lignes retournés sont
vides, ce qui indique qu’aucun réseau, sous-réseau, routeur ou adresse IP flottante n’avait encore été créé
dans le projet au moment de l’inventaire. Cette situation est cohérente avec un environnement initial
vierge et constitue un point de référence pour les étapes suivantes.
2.3.2 Création du réseau iot-net
Après l’inventaire initial, un réseau dédié aux équipements IoT a été créé. Ce réseau vise à assurer une
segmentation logique entre les composants IoT et les autres ressources de l’infrastructure.
Les commandes suivantes ont été utilisées :
openstack network create iot-net
openstack subnet create --network iot-net --subnet-range [Link]/24 iot-subnet
Figure 5 – Création du réseau
Figure 6 – Création du sous-réseau
La création du réseau est vérifiée à l’aide de la commande suivante :
openstack network show iot-net
Figure 7 – vérification du réseau
Cette sortie confirme l’existence du réseau iot-net, ainsi que ses principaux attributs (identifiant, état
administratif, MTU et sous-réseau associé).
2.3.3 Configuration des Security Groups : politique minimale
Dans une approche de sécurité basée sur le principe du moindre privilège, un Security Group nommé
iot-sg a été créé afin de restreindre les flux réseau autorisés vers les instances IoT.
La création du Security Group est réalisée :
Figure 8 – Configuration Security Groupe
Les règles de filtrage appliquées sont les suivantes :
— autorisation de l’accès SSH (port 22/TCP) uniquement depuis le réseau d’administration
([Link]/24) ;
— autorisation du protocole MQTT sécurisé sur TLS (port 8883/TCP) uniquement depuis le réseau
d’administration ;
— autorisation de l’accès HTTPS (port 443/TCP) depuis Internet pour l’exposition éventuelle d’une
API publique ;
— les règles de sortie (egress) sont laissées par défaut et seront documentées, conformément à la
politique enseignée.
Les règles ont été ajoutées à l’aide des commandes suivantes :
Figure 9 – Autorisation de l’accés SSH
Figure 10 – Autorisation MQTT
Figure 11 – Autorisation de l’accés HTTPS
La vérification des règles configurées est effectuée avec la commande :
openstack security group rule list iot-sg
Figure 12 – Vérification des Security Group
La résultat affiche l’ensemble des règles de sécurité créées pour le Security Group iot-sg, confirmant
la bonne application de la politique de filtrage définie.
2.4 PKI locale et certificats
2.4.1 Objectif
L’objectif de cette partie est de mettre en place une infrastructure de gestion de certificats (PKI) locale et
de générer :
— une autorité de certification (CA) locale,
— un certificat serveur pour le broker MQTT ou l’API exposée,
— un certificat client pour un capteur ou un client MQTT.
Cette configuration permet de sécuriser les communications via TLS et d’assurer l’authentification
mutuelle entre clients et serveur.
2.4.2 Création de la CA locale sur le nœud controller
La première étape consiste à générer une autorité de certification locale. Les commandes suivantes sont
exécutées :
Figure 13 – Création de la CA locale
Explications :
— genrsa : création de la clé privée de la CA (4096 bits),
— req -x509 : génération d’un certificat auto-signé pour la CA,
— -days 3650 : validité de 10 ans,
— -subj : informations d’identification de la CA,
— x509 -noout : vérification du certificat généré.
Preuve attendue : La sortie de la commande openssl x509 montrant le sujet, l’émetteur, les dates et
l’empreinte du certificat.
2.4.3 Génération du certificat serveur (exemple : iot-gw)
Pour sécuriser le broker MQTT ou une API, un certificat serveur est généré et signé par la CA locale :
Figure 14 – Génération du certificat client :iot-gw
Explications :
— genrsa : création de la clé privée du serveur (2048 bits),
— req -new : génération d’une requête de signature de certificat (CSR),
— x509 -req : signature du CSR par la CA pour produire le certificat serveur,
— verify : validation du certificat contre la CA.
Preuve attendue : la commande openssl verify à retourner OK.
2.4.4 Génération du certificat client (exemple : device001)
Pour sécuriser un capteur ou client MQTT, un certificat client est généré :
Figure 15 – Génération du certificat client :device001
Explications :
— genrsa : création de la clé privée du client,
— req -new : génération d’une requête de certificat (CSR) pour le client,
— x509 -req : signature par la CA pour produire le certificat client,
— verify : validation du certificat client.
Preuve attendue : la commande openssl verify à retourner OK, confirmant la validité du certificat
client par rapport à la CA locale.
2.4.5 Préparation avant le lancement de la VM
Avant de créer la VM, les ressources suivantes ont été préparées et validées :
— Image : image système adaptée pour la VM IoT,
— Flavor : définition des ressources CPU, mémoire et disque pour la VM,
— Clé SSH : clé publique associée pour permettre un accès sécurisé sans mot de passe.
Figure 16 – Préparation de ressource
Ces éléments garantissent que la VM pourra être correctement lancée et administrée.
2.5 Lancement de la VM iot-gw
La VM iot-gw est créée avec la commande suivante, en adaptant les paramètres <flavor>, <image> et
<keypair> selon les ressources préparées :
Figure 17 – Création Vm
2.5.1 Vérification de la VM et des ports réseau
Après le lancement, l’état de la VM ainsi que ses interfaces réseau sont vérifiés .
Figure 18 – Vérification des ports réseau de la Vm
Cette commande affiche un tableau récapitulatif contenant les informations détaillées des instances. Dans
notre cas, la machine virtuelle iot-gw apparaît avec le statut ERROR, ce qui indique un échec lors du
processus de création.
2.5.2 Analyse du problème
Afin d’identifier l’origine de l’erreur, plusieurs vérifications ont été effectuées :
— Vérification de l’état de l’hyperviseur : statut up ;
— Vérification du service nova-compute : statut up ;
— Vérification de la création et de la configuration des bridges réseau ;
— Vérification des ressources disponibles via le service Placement.
Malgré ces contrôles, aucune anomalie apparente n’a été détectée. L’erreur persiste depuis plusieurs
semaines et empêche le déploiement correct des instances.
En conséquence, l’implémentation complète de ce TP n’a pas pu être poursuivie au-delà de cette étape, le
problème bloquant étant lié au processus de création des machines virtuelles au niveau de l’infrastructure.
3 Conclusion
Ce travail pratique a permis de mettre en œuvre et de valider des mécanismes essentiels de sécurité dans
un environnement Cloud et IoT basé sur OpenStack.
Nous avons tout d’abord préparé l’environnement en vérifiant l’authentification via Keystone et la dis-
ponibilité des services réseau Neutron, ce qui a garanti un contexte administrateur sécurisé pour la suite
des opérations. La création d’un réseau dédié aux équipements IoT et la configuration d’un Security
Group minimal ont permis de restreindre les flux réseau aux seuls services nécessaires, conformément
au principe du moindre privilège.
La mise en place d’une PKI locale, incluant la génération d’une autorité de certification, de certificats
serveur et client, a permis de sécuriser les communications MQTT et API via TLS et d’assurer l’au-
thentification mutuelle entre serveurs et clients IoT. Le déploiement d’une machine virtuelle iot-gw sur
le réseau sécurisé et la vérification des ports et du dataplane réseau ont confirmé que les politiques de
sécurité étaient appliquées correctement à la fois au niveau logique et au niveau infrastructure.
En conclusion, ce TP a permis d’acquérir une compréhension pratique des bonnes pratiques de sécurité
dans les environnements Cloud et IoT, en mettant l’accent sur l’authentification, la segmentation réseau,
la gestion des certificats et la vérification du dataplane. Il constitue une base solide pour la sécurisation
des applications distribuées et des objets connectés dans des infrastructures Cloud réelles.