Architecture BECLM et infrastructure de déploiement | BeCLM

Architecture

Architecture macro

Pour des raisons de sécurité, le schéma ci-dessus est une vision macro de l’architecture identifiant néanmoins les grands principes

Application Front – UI Utilisateur : Réparti sur plusieurs nœuds dans plusieurs zones, pour à la fois garantir la performance d’usage et la disponibilité
Application Back – Accès aux données et traitement : Réparti également sur plusieurs nœuds dans différentes zones.
Les traitements sont effectués sur des nœuds distinct pour ne pas perturber l’application lors des hautes charges de calcul
API Gateway isolée et en haute disponibilité
Déploiement GCP => Base de données mongo Atlas en cluster sur 3 nœuds pour les données en principal avec cryptage au niveau des disques. Réplication Mongo pour le premier niveau de sauvegarde et sauvegarde externe sur un hébergement distinct
Déploiement OVH => Base de données mongo en cluster sur 3 nœuds pour les données en principal. Réplication Mongo pour le premier niveau de sauvegarde et sauvegarde externe sur un hébergement distinc

L’architecture permet de garantie un haut niveau de performance pour l’utilisateur et pour les accès aux systèmes :

Navigation sur l’application Web avec 95% en moins de 1s (3s max sur les pages les plus complexes représentant moins de 5% de l’application
Temps de réponse API garantie en moins de 500 ms (150 ms en moyenne)

SÉCURITÉ INFRASTRUCTURE

Chiffrement du trafic réseau HTTPS

Tout le trafic réseau entre le client et le serveur est en HTTPS via le protocole TLS 1.3. Les anciennes versions de ce protocole sont désactivées pour des raisons de sécurité.

Nous analysons le certificat via l’outil Qualys SSL Labs pour en vérifier le bon fonctionnement

API Gateway

Les API sont implémentées au sein d’une API Gateway permettant

Surveillance de l’API.
Rate limiting (personnalisable par consommateur).
Traçabilité des appels.
Authentification via différents supports (basic auth, oidc, keycloak, etc)
Sécurité (restrictions par IP, user agent, consommateur, referer, etc)

Monitoring

L’application est surveillée à l’aide de Prometheus / Grafana

Suivi des recommandations de sécurités pour les composants externes (MongoDB, Nginx, K8S, etc…)

Les recommandations de sécurité fournies par les différents composants externes que nous utilisons sont suivies comme :

· La désactivation de l’affichage des versions sur des pages d’erreur.

· Le déploiement sur un réseau privé (pas d’IP publique sur les noeuds K8S sauf pour le load balancer).

· L’activation de l’authentification sur les bases de données (en plus du réseau privé).

Gestion de la configuration des secrets

Les secrets utilisés par l’application et les différents composants externes sont stockés dans un coffre-fort numérique.

Aucune clé, secret ou mot de passe ne sont stockés en clair sur git.

SÉCURITÉ APPLICATIVE

Analyse des CVE

Une analyse des CVE est régulièrement faite par l'équipe à l’aide des outils OWASP Dependency-Check et Trivy,

L’outil dependabot de GitHub permet en complément l'ouverture de pull-request automatiques en cas de détection de CVE.

Gestion de l’authentification

Lors de la mise en place du système d’authentification, les critères suivants sont mis en place pour se protéger de diverses attaques externes :

Mise en place d’une politique de mot de passe solide pour l’ensemble des utilisateurs (10 caractères minimum, lettres minuscules, majuscules, chiffres et caractères spéciaux).
Mise en place de double authentification sur l’authentification.
Mécanisme anti-bruteforce sur la connexion à l’application via un captcha et/ou un nombre d’essais limité par IP et compte.
Mise en place de message d’erreur générique ne permettant pas de détecter si un email/identifiant est déjà enregistré dans le système.

La mise en place d’une authentification par délégation à une application tierce avec OAuth2 est également possible.

Antivirus

Afin d'éviter que l’application ne serve de relai malveillant à des attaquants, nous mettons en place un antivirus qui analyse les fichiers envoyés vers le serveur. En cas de fichier vérolé une alerte sera automatiquement envoyée à l'équipe technique.

Entêtes de sécurité

Toujours dans l’objectif de se protéger contre les attaques malveillantes, les entêtes de sécurité suivants sont mis en place pour bloquer certains types d’attaques :

X-Content-Type-Options : Permet de bloquer le “MIME Sniffing” du navigateur et de suivre uniquement les instructions de l’entête Content-Type.
X-Frame-Options : Permet de bloquer l’utilisation d’iframe de son application sur des sites externes pour éviter le risque qu’un attaquant mette en place l’application dans une iframe invisible pour ensuite lancer une attaque clickjacking dans le but de faire exécuter des actions à un utilisateur sans qu’il s’en aperçoive.
Referrer-Policy : Permet de restreindre les informations envoyées à des domaines externes.
Permissions-Policy : Permet de contrôler finement l'autorisation de fonctionnalité du navigateur par les scripts javascripts.
Content-Security-Policy : Permet une prévention face à des attaques XSS et au chargement de ressources externes non voulu par le client (image, script, font, frame, média, etc...).

Une fois les entêtes mis en place, nous analysons l’application à l’aide de l’outil https://securityheaders.com/ pour vérifier que les entêtes sont bien appliqués.

Téléchargement de fichier CSV / XLSX

L’injection formula permet d’exécuter des formules sur un poste client après exécution d’un fichier CSV ou XLSX. Certaines formules permettent même de télécharger des fichiers malveillants.

Pour s’en protéger, l’application filtrera automatiquement les caractères en début de cellule : “=”, “+”, “-”, “@”.

Liste blanche d’envoi de fichier vers le serveur

Pour les fichiers transmis vers le serveur, nous mettons en place une liste blanche pour que seuls des fichiers avec une extension valide et un poids maximum puissent être envoyés.

Traçabilité des actions

Nous mettons systématiquement en place des logs dans un environnement externalisé (Google Cloud Logs)

La mise en place de ces logs permet :

D’assurer un suivi des actions utilisateurs.
De remonter les actions en cas d’attaque malveillante.
Faciliter le travail des développeurs pour le débug.

Les logs doivent contenir les éléments suivants afin de nous permettre d’être conformes aux points cités précédemment :

Trace ID : UUID généré dans le cadre d’une requête et transféré de module en module ou sur les différents threads auquel la requête a accès.
Adresse IP de l’utilisateur.
ID technique de l’utilisateur.
Log métier pour les actions de lecture, création, modification et suppression

Infrastructure de déploiement

Beclm dispose de deux infrastructures de déploiement indépendante, sur lesquels sont déployés deux environnements de production (choix du client) contenant des versions applicatives identiques:

même version
même rythme de mise à jour
même niveau de contrôle et de

Infrastructure GCP: Infrastructure données et traitement répartis sur 3 data centers localisés en Ile de France

Infrastructure OVH : Infrastructure données et traitement dans un data center à gravelines avec un backup externalisé en France sur un site distant

Les deux infrastructures de production permettent de respecter les mêmes engagements de services :

SLA équivalent entre infra GCP et OVH
Niveau de Sécurité et contrôle accès équivalent entre infra GCP et OVH
Redondance et niveau de service équivalent entre infra GCP et OVH
Plan de sauvegarde et rétention des données équivalent entre infra GCP et OVH

Les seules écarts concernent :

Cryptage de la base au niveau des disques : aujourd’hui disponible uniquement sur l’infra GCP via un secret Beclm. Le service de cryptage de la base devrait être disponible chez OVH fin 2025
Sauvegarde externe :
- Infrastructure OVH : Sauvegarde externe cryptée chez un prestataire externe déporté (autre datacenter en France) - IKOULA
- Infrastructure GCP : Sauvegarde externe cryptée dans un data center GCP différent