Une défense en profondeur, couche par couche.
Aperçu général de la structure de la plateforme de messagerie BroadNet — de l'API aux interconnexions avec les opérateurs — pour une sécurité appliquée à tous les niveaux, et non ajoutée en périphérie. Ce document est volontairement non confidentiel : il illustre la structure de l'architecture, et non sa topologie interne.
Les couches, en termes simples.
Applications et canaux clients
Vos applications et campagnes communiquent via des interfaces documentées et versionnées. Aucune information relative à un locataire en aval n'est jamais exposée à un autre.
Passerelle API et SDK
Côté public. Des jetons d'accès Bearer propres à chaque compte authentifient chaque requête API ; la limitation du débit par locataire, la liste blanche d’adresses IP et un pare-feu d’application Web (WAF) automatisé protègent la plateforme.
Plateforme de messagerie
Traitement mutualisé avec isolation par locataire, mise en file d'attente durable et orchestration de la distribution. Les modifications d'état sont consignées dans les journaux d'audit.
Intelligence de routage
Le routage basé sur le moindre coût et la qualité sélectionne un chemin légal et conforme pour chaque destination, avec détection des routes grises et réaffectation si une route se dégrade en dessous de son objectif de service.
Sécurité et pare-feu
Des défenses de niveau télécom — pare-feu SMS, pare-feu SS7, protection de l'identification de l'expéditeur, analyse des appels flash et des abus de mots de passe à usage unique — sont appliquées par défaut aux routes propres à BroadNet.
Interconnexions des opérateurs
1,000+ connexions directes aux opérateurs assurent des liaisons directes dans 86 pays, avec des routes partenaires identifiées sur le reste des 200+ pays desservis, garantissant ainsi que le trafic aboutit sur des routes légitimes et contractuelles.
Cinq plans défensifs, en profondeur.
Les couches numérotées ci-dessus décrivent le chemin emprunté par un message. Ces cinq plans décrivent les mécanismes de contrôle qui s'appliquent à chaque point de ce chemin — chacun étant conçu de manière à ce qu'une défaillance dans un plan soit contenue par le suivant.
Bordure et réseau
Le périphérique public termine le protocole TLS 1.3, absorbe les attaques par compression volumétrique et vérifie la validité des requêtes avant même qu'elles n'atteignent la logique applicative. Aucun élément en aval ne fait confiance au réseau sur lequel il est arrivé.
- Limitation du débit par locataire et par point de terminaison avec contrôle des pics de débit
- Options de liste blanche d'adresses IP et de TLS mutuel pour les liaisons SMPP et API
- Pare-feu d'applications web (WAF) automatisé filtrant les schémas d'injection et d'abus courants
- Absorption des attaques DDoS et élimination des anomalies au niveau de la connexion en périphérie
Application et identité
Chaque requête est authentifiée et autorisée individuellement. L'identité est établie grâce à des jetons d'accès Bearer propres à chaque compte ; les rôles définis par leur portée déterminent les actions autorisées ; la mutualisation est implémentée dans le code, et non par convention.
- Jetons d'accès Bearer par compte pour l'API ; jetons de courte durée pour les sessions interactives
- Contrôle d'accès basé sur les rôles avec étendues par défaut de privilèges minimaux
- Isolation par locataire afin qu'aucun locataire ne puisse accéder aux données d'un autre locataire
- Webhooks chiffrés TLS pour les flux entrants DLR et MO
Données et stockage
Le contenu des messages, les métadonnées de livraison et les journaux d'audit sont chiffrés au repos et conservés selon les délais contractuels et réglementaires. Les actions modifiant l'état des messages sont consignées dans un journal d'audit en mode ajout uniquement.
- Chiffrement AES-256 des données au repos sur les supports de stockage principaux et les sauvegardes
- Journalisation d'audit en ajout uniquement des actions modifiant l'état
- Les périodes de conservation des données sont conformes aux dispositions contractuelles et réglementaires régionales
- Sauvegardes chiffrées et testées par rapport aux objectifs de récupération définis
Gestion des clés
Les clés sont générées, stockées, renouvelées et mises hors service au sein d'une infrastructure de gestion de clés dédiée. Le code applicatif contient des références, et non les données brutes des clés ; le renouvellement ne nécessite donc aucune interruption de service.
- Gestion centralisée des clés, séparée des secrets de l'application
- Rotation programmée des clés et révocation immédiate en cas de suspicion de compromission
- Séparation des tâches relatives à la garde des clés et à l'accès administratif
- Le chiffrement de l'enveloppe garantit que les clés de données sont elles-mêmes protégées par des clés maîtresses
Surveillance et réponse
L'observabilité couvre l'ensemble de la pile réseau et non un seul point critique, ce qui permet de détecter les anomalies au plus près de leur origine. Un centre d'opérations réseau (NOC) fonctionnant 24 h/24 et 7 j/7 associe la détection à une procédure de réponse aux incidents documentée.
- Centre d'opérations réseau (NOC) 24h/24 et 7j/7 avec alertes couvrant la périphérie, la plateforme, le routage et les interconnexions
- Analyses en temps réel du trafic lié aux routes grises, aux abus d'identifiants d'expéditeur et aux abus OTP
- Réponse documentée aux incidents avec classes de gravité et escalade nommée
- Analyse des causes profondes (RCA) et rapport de cause d'interruption (RFO) après les incidents majeurs
Commandes conformes aux normes.
Un exemple de correspondance entre chaque couche et les familles de contrôles des normes ISO/IEC 27001, SOC 2 et ISO 22301. Il s'agit d'un exemple et non d'une déclaration complète d'applicabilité — l'ensemble des contrôles audités est partagé sous accord de confidentialité.
| Layer | Contrôles représentatifs | Norme de référence |
|---|---|---|
| Périphérie et réseau | TLS 1.3, WAF, limitation du débit par locataire, liste blanche d'adresses IP, absorption des attaques DDoS | ISO 27001 A.8 · SOC 2 CC6.6 |
| Application et identité | Authentification de l'API par jeton Bearer, RBAC au moindre privilège, isolation par locataire | ISO 27001 A.8 / A.9 · SOC 2 CC6.1–CC6.3 |
| Données et stockage | AES-256 au repos, journaux d'audit en ajout uniquement, fenêtres de rétention, sauvegardes chiffrées | ISO 27001 A.8 · SOC 2 CC6.1 / C1.1 |
| Gestion des clés | KMS centralisé, rotation planifiée, révocation, séparation des tâches | ISO 27001 A.8.24 · SOC 2 CC6.1 |
| Surveillance et réponse | Centre d'opérations réseau (NOC) 24h/24 et 7j/7, télémétrie intercouches, IR documentée, RCA/RFO | ISO 27001 A.5.24–A.5.28 · SOC 2 CC7.2–CC7.4 |
| Continuity | Sauvegardes, objectifs de reprise testés, gestion de la continuité des activités | ISO 22301 · SOC 2 A1.2 |
Les normes cartographiées font référence à l'ISO/IEC 27001:2022, annexe A, au SOC 2 Trust Services Criteria et à l'ISO 22301. Voir Conformité pour la liste de certification et le Centre de confiance Demander des preuves.
Cryptage et gestion des clés.
La robustesse du chiffrement dépend de la manière dont ses clés sont gérées. Les données sont protégées en transit et au repos, et les clés qui les protègent résident dans une infrastructure dédiée, distincte du code applicatif et des données elles-mêmes.
En transit
TLS 1.3 sur toutes les interfaces externes — API, SMPP et webhooks — avec des suites de chiffrement modernes et des options d'épinglage de certificats pour les liaisons d'entreprise.
Au repos
Le chiffrement AES-256 est utilisé pour les serveurs principaux et les sauvegardes. Le contenu des messages et les métadonnées de leur acheminement sont conservés pendant des périodes conformes aux contrats et à la réglementation régionale.
Cycle de vie des clés
Gestion centralisée des clés avec rotation programmée, révocation rapide, séparation des tâches et chiffrement de l'enveloppe afin que les clés de données soient elles-mêmes protégées par des clés maîtresses.
Modèle de menaces et défense en profondeur.
La défense en profondeur implique qu'aucun point de contrôle ne supporte à lui seul une charge importante. Pour chaque objectif réaliste d'un attaquant, plusieurs avions doivent être mis hors service avant qu'il y ait impact.
Vol d'identifiants ou fuite de clé API
Les limites de privilèges minimaux restreignent le rayon d'action ; les jetons à courte durée de vie et la révocation rapide réduisent la fenêtre d'opportunité ; l'isolation par locataire empêche le déplacement latéral vers un autre locataire.
Injection via des routes grises et usurpation de l'identifiant d'expéditeur
Le pare-feu SMS et la protection par identification de l'expéditeur classent et bloquent le trafic illégitime avant sa destination ; les interconnexions directes entre opérateurs garantissent que le trafic légitime emprunte les routes contractuelles.
Abus OTP / inflation artificielle du trafic
L'analyse comportementale et la détection des abus flash-call / OTP freinent les schémas gonflés au débit de ligne, avant qu'ils ne puissent être monétisés en aval.
Attaques de la couche de signalisation (SS7)
Le pare-feu SS7 inspecte et filtre les signaux pour se défendre contre le suivi de localisation, l'interception et les tentatives de fraude au niveau du réseau.
Exposition des données en transit ou au repos
TLS 1.3 protège les données en transit et AES-256 protège les données au repos ; les clés résident dans une infrastructure de gestion des clés dédiée, distincte des données qu'elles protègent.
Abus interne ou administratif
Le contrôle d'accès basé sur les rôles, la séparation des tâches en matière de gestion des clés et la journalisation d'audit en ajout uniquement permettent de rendre les actions privilégiées responsables et vérifiables.
Surveillance à tous les niveaux
L'observabilité et la surveillance 24h/24 et 7j/7 couvrent l'ensemble de la chaîne plutôt que de se concentrer sur un seul point critique, permettant ainsi de détecter les anomalies au plus près de leur origine. Les outils spécifiques et les seuils d'alerte sont communiqués aux évaluateurs sous accord de confidentialité.
Cryptage intégral
Le protocole TLS 1.3 protège les données en transit et le protocole AES-256 protège les données au repos à tous les niveaux. Les détails relatifs à la gestion des clés et aux contrôles sont disponibles sous accord de confidentialité ; consultez les certifications pour connaître le périmètre audité.
Les détails des contrôles certifiés, l'emplacement des centres de données, les objectifs précis de reprise d'activité et la topologie interne sont couverts par le périmètre audité de BroadNet et partagés sous accord de confidentialité. Voir ISO/CEI 27001 et ISO 22301
Voici le lien.
Cette vue d'ensemble correspond à l'architecture du système. Les preuves, les certificats, et les engagements opérationnels qui la sous-tendent sont disponibles dans le Centre de confiance et sur les pages Conformité et sécurité.
Certificats, sous-traitants et demandes de preuves.
ISO 27001 / 9001 / 22301 et cadres régionaux.
L'ensemble complet des contrôles sur lesquels repose cette architecture.
Classes de gravité, processus d'escalade et d'analyse des causes profondes.
Foire aux questions.
S'agit-il de l'architecture de sécurité complète ?
Non. Cette page est volontairement un aperçu non confidentiel : elle présente la structure de l’architecture et les contrôles à chaque niveau, et non la topologie interne, l’emplacement des centres de données ou les objectifs précis de reprise d’activité. Les détails des contrôles certifiés sont communiqués aux évaluateurs sous accord de confidentialité et couverts par le périmètre d’audit de BroadNet.
À quelles normes la plateforme est-elle certifiée ?
BroadNet est certifié ISO/IEC 27001 (sécurité de l'information), ISO 9001 (qualité) et ISO 22301 (continuité d'activité). Le tableau de correspondance des contrôles présenté sur cette page établit des liens entre les contrôles représentatifs et les familles de contrôles ISO 27001, SOC 2 et ISO 22301, permettant ainsi aux évaluateurs de visualiser la conformité de chaque niveau.
Comment le chiffrement est-il géré lors du transit et au repos ?
TLS 1.3 protège les données en transit et AES-256 protège les données au repos, aussi bien sur les serveurs principaux que sur les sauvegardes. Les clés sont générées, stockées, renouvelées et supprimées au sein d'une infrastructure de gestion de clés dédiée, utilisant le chiffrement d'enveloppe afin que les clés de données soient elles-mêmes protégées par des clés maîtres.
Appliquez-vous vos propres pare-feu SMS et SS7 au trafic BroadNet ?
Oui. Les protections de niveau télécom — pare-feu SMS, pare-feu SS7, protection de l'identification de l'expéditeur et analyse des abus de mots de passe à usage unique — sont appliquées par défaut aux routes propres à BroadNet, et ne sont pas proposées uniquement en option pour les réseaux tiers.
Comment puis-je demander le détail des contrôles audités ?
Les détails des contrôles nommés, l'emplacement des centres de données, les objectifs précis de reprise d'activité et la topologie interne sont communiqués à des évaluateurs qualifiés sous accord de confidentialité. Accédez au Centre de confiance ou à la page Conformité, ou contactez l'équipe de sécurité pour demander le dossier de documentation.