Mise en œuvre d’un SIEM/SOC pour une API Médicale -
Samia Errabite
Contexte du projet
Dans le cadre du développement d’une API médicale (Fast API/Python), la sécurité des données de santé est une priorité absolue. Une simple faille de code peut permettre à un utilisateur malveillant d’accéder aux dossiers d’autres patients.
L’objectif de ce projet est de mettre en place une architecture de SIEM pour ne plus seulement “subir” les attaques, mais les détecter instantanément via un centre de contrôle (SOC).
Mise en place de l’infrastructure
Tout projet de cybersécurité commence par une structure rigoureuse. J’ai commencé par créer une arborescence dédiée pour isoler les flux de données.
- Commandes utilisées :
mkdirpour les dossiers ettouchpour initialiser les fichiers de logs. - Fichiers cibles :
api_python.logpour mon backend etapp_php.logpour tester d’autres sources.
Mon API Python a été configurée pour écrire chaque action critique (connexion base de données, démarrage, erreurs) dans le fichier local. On peut voir ici que le système trace chaque opération SQL.
Pour envoyer ces logs vers le Cloud, j’ai choisi Filebeat. Contrairement à un envoi direct depuis Python, File Beat offre des avantages majeurs :
- Agent ultra-léger qui ne ralentit pas l’application.
- En cas de coupure réseau, les logs sont gardés en mémoire
Après avoir récupéré les credentials (cloud.id et cloud.auth) sur la console Elastic Cloud, je les ai injectés dans le fichier de configuration filebeat.yml avant de valider la communication avec le serveur distant via la commande de test, confirmant ainsi que le pont sécurisé entre mon API et mon SOC était opérationnel.
Centralisation sur Elastic Cloud
J’ai déployé une instance Elastic Cloud. Cette infrastructure permet de stocker les logs de manière sécurisée et déportée du serveur applicatif.
Détection d’Attaque en Temps Réel (IDOR)
Pour tester l’efficacité de mon SOC, j’ai simulé une attaque IDOR (Insecure Direct Object Reference).
- Le Code : J’ai ajouté une règle de sécurité qui génère un
logging.warning("ALERTE SOC")si un utilisateur tente d’accéder à un ID de patient qui n’est pas le sien. - La Détection : Dès que l’attaque est lancée, elle remonte instantanément dans Kibana Discover.

Réponse aux Incidents
Une fois l’alerte IDOR détectée sur Kibana, la phase de remédiation s’active. Voici les mesures de protection à automatiser :
- Blocage Immédiat : Bannissement automatique de l’adresse IP de l’attaquant au niveau du Pare-feu (WAF).
- Neutralisation du compte : Suspension temporaire du compte utilisateur pour stopper l’exfiltration de données.
- Patching : Correction de la faille dans le code Python (ajout d’une vérification d’autorisation
if user_id != patient_id).
Conclusion et déploiement ansible
Ce projet démontre qu’une surveillance active est indispensable pour protéger des données sensibles. Pour une mise en production réelle, ce système est totalement scalable : grâce à Ansible, je pourrais automatiser le déploiement de Filebeat sur des centaines de serveurs en quelques secondes, garantissant une visibilité totale sur toute une infrastructure.
Exemple de playbook :
‘’’- name: Installation et Configuration du SOC Agent (Filebeat)
hosts: servers_medicals
become: yes
vars:
# On utilise des variables pour ne pas mettre les secrets en clair
elastic_cloud_id:”."
elastic_cloud_auth: “elastic:MON_MOT_DE_PASSE_SECURISE”
tasks:
- name: 1. Téléchargement de l’agent Filebeat
apt:
name: filebeat
state: present
update_cache: yes
\- name: 2\. Configuration du fichier filebeat.yml
copy:
dest: /etc/filebeat/filebeat.yml
content: |
filebeat.inputs:
\- type: log
enabled: true
paths:
\- /home/user/Documents/Projet\_SOC/logs/\*.log
cloud.id: "{{ elastic\_cloud\_id }}"
cloud.auth: "{{ elastic\_cloud\_auth }}"
\- name: 3\. Activation et démarrage du service Filebeat
systemd:
name: filebeat
state: restarted
enabled: yes
\- name: 4\. Vérification du statut du SOC
debug:
msg: "L'agent Filebeat est déployé et connecté au Cloud Elastic \!" '''