Chiffrement, isolation, hébergement régional —
sécurisé dès la conception.

Le chiffrement chez SDEN est concret. En transit, chaque point de terminaison public termine TLS 1.3 avec des suites de chiffrement modernes (ECDHE pour l'échange de clés, des chiffrements AEAD comme AES-GCM et ChaCha20-Poly1305), avec préchargement HSTS demandé là où la propriété du domaine le permet. Le trafic interne de service à service à l'intérieur de notre infrastructure gérée est lui aussi chiffré par TLS ; nous ne présumons pas qu'un réseau privé est un réseau de confiance.

Au repos, les données sont chiffrées avec AES-256 au moyen des services de gestion de clés gérés par le fournisseur infonuagique (AWS KMS, GCP KMS ou équivalent) par défaut, avec des clés gérées par le client (CMK / BYOK) offertes sur demande pour les mandats où le modèle de menaces et le contexte réglementaire l'exigent. Les clés sont rotées selon un calendrier documenté et sur demande à la suite de tout changement d'accès. Nous ne livrons pas de produits qui stockent des secrets dans des variables d'environnement sur une seule machine virtuelle en appelant cela « chiffré au repos » — la distinction compte et nous la traitons comme un veto de revue de code.

L'authentification du personnel SDEN est imposée par un facteur multiple adossé au matériel (WebAuthn / FIDO2) pour chaque compte ayant accès aux systèmes de production, aux données client ou au code source. L'approvisionnement des comptes passe par un processus documenté d'arrivée / mutation / départ avec des revues d'accès trimestrielles. Il n'y a aucun identifiant partagé vers un système de production ; chaque action est attribuable à une personne nommée.

Pour les applications que nous livrons, l'authentification unique par OIDC (Google Workspace, Microsoft Entra ID, Okta, Auth0) est l'option par défaut offerte aux clients d'entreprise. Là où l'authentification unique n'est pas disponible, l'authentification par mot de passe est imposée avec le hachage recommandé par l'OWASP (Argon2id ou scrypt), une limitation de débit à la couche de bourrage d'identifiants, et un facteur multiple obligatoire pour tout compte à portée administrative. Le contrôle d'accès par rôles fonctionne au moindre privilège ; la permission par défaut de tout nouveau rôle est zéro, et chaque octroi est documenté.

Les journaux d'audit sont conservés au minimum douze mois et sont à preuve d'altération — le flux de journaux lui-même est en ajout seul et exporté vers une destination isolée, de sorte qu'une compromission de l'application ne puisse pas réécrire rétroactivement la piste d'audit. PLACEHOLDER : confirmer la fenêtre de conservation configurée pour chaque environnement avant publication.

La multilocation est l'endroit où surviennent la plupart des failles de sécurité des SaaS — et presque toujours parce que l'isolation était imposée dans le code applicatif plutôt qu'à la couche des données. L'architecture par défaut de SDEN l'impose aux deux. L'identifiant de locataire se propage dans l'application comme un type obligatoire (et non un champ optionnel), de sorte qu'une requête qui oublie de se restreindre à un locataire est une erreur de compilation TypeScript plutôt qu'une fuite de données à l'exécution. À la base de données, les politiques de sécurité au niveau des lignes de PostgreSQL imposent la même frontière — même un compte de service qui se comporte mal ne peut pas lire d'un locataire à l'autre sans une dérogation explicite et auditée.

Là où le modèle de menaces justifie le coût, nous livrons des clés de chiffrement au repos par locataire, de sorte qu'une compromission au niveau de la base de données des données d'un locataire ne puisse pas déchiffrer celles d'un autre. Les sauvegardes sont de même restreintes par locataire, avec la procédure de restauration documentée et éprouvée. La matrice d'accès intercatlocataires est testée par intégration avant chaque version : chaque point de terminaison est invoqué avec les identifiants d'un locataire contre les enregistrements d'un autre, et les refus attendus sont affirmés automatiquement.

La juridiction d'hébergement est une décision de protection des données, pas une décision d'approvisionnement. Chaque produit que nous livrons est déployé dans la région que le client exige, parce que la posture SOC 2 / CCPA / PIPEDA et l'absence de mécanismes de transfert transfrontalier sont toutes plus simples quand les données ne quittent pas leur région d'origine en premier lieu. Les fournisseurs que nous utilisons le plus souvent — AWS (us-east- / ca-central-), GCP (us- / northamerica-) et Azure dans les régions américaines, canadiennes et de l'UE — ont tous signé des ententes de traitement des données que nous pouvons transmettre aux clients sans renégociation.

Là où le modèle de menaces ou le contexte réglementaire d'un client exige un déploiement verrouillé à une région (États-Unis, Canada ou UE), nous le configurons pour qu'il reste dans cette région ; là où un basculement multirégional est requis, nous le configurons avec des frontières de résidence documentées. Nous ne changeons pas en silence la région d'hébergement d'une sauvegarde ou d'un nœud périphérique de CDN sans divulgation — l'engagement de résidence dans la DPA, c'est la résidence en production.

Les sauvegardes sont chiffrées (AES-256), prises selon un calendrier adapté à l'objectif de point de récupération (RPO) des données, et stockées dans une région distincte de la principale, de sorte qu'une panne régionale n'emporte pas la récupération avec elle. PLACEHOLDER : confirmer le RPO configuré et l'objectif de temps de récupération (RTO) par produit avant toute publication externe — les valeurs par défaut typiques sont un RPO ≤ 24 heures et un RTO ≤ 8 heures pour les produits SaaS que SDEN exploite.

Les procédures de restauration sont éprouvées. Une sauvegarde qui n'a jamais été restaurée est un espoir, pas un plan de récupération ; nous menons des exercices de restauration périodiques contre un environnement de préproduction et nous en documentons le résultat. Quand nous remettons un produit à un client, le guide de restauration fait partie du livrable.

Sécurisé dès la conception n'est pas un slogan chez SDEN ; c'est un ensemble de pratiques imposées par le même pipeline d'intégration continue qui exécute la suite de tests. À l'étape de conception de chaque projet, le modèle de menaces est mis par écrit — les actifs que nous protégeons, les adversaires contre lesquels nous les protégeons, les frontières de confiance par lesquelles transitent les données. Le résultat oriente les décisions d'architecture, le modèle de contrôle d'accès et les choix de dépendances.

Dans le pipeline, chaque demande de tirage exécute une analyse de composition logicielle (SCA) contre l'arbre de dépendances pour repérer les paquets vulnérables connus, des tests statiques de sécurité applicative (SAST) contre le code pour les motifs du OWASP Top 10, et une détection de secrets pour s'assurer que des identifiants n'atterrissent jamais dans le dépôt. La protection des branches exige une version réussie et l'approbation d'un réviseur avant la fusion ; les validations signées sont exigées sur la branche principale ; les images de conteneur sont analysées et les images de base sont épinglées à une étiquette maintenue selon une cadence de rafraîchissement documentée.

Les vulnérabilités de sécurité trouvées dans un logiciel bâti par SDEN peuvent être signalées de manière confidentielle à [email protected] — voir la section de contact ci-dessous. Nous nous engageons à une fenêtre de réponse définie : un accusé de réception en un jour ouvrable, un premier triage en trois jours ouvrables, et un calendrier de divulgation coordonnée convenu avec la personne qui signale avant toute communication publique.

À l'interne, les incidents suivent un processus de réponse documenté : un seul commandant d'incident est nommé à la déclaration, la communication passe par un canal dédié avec des mises à jour horodatées, une mise à jour de statut destinée au client est publiée quand l'impact est visible pour le client, et un post-mortem écrit est produit dans les dix jours ouvrables suivant la résolution. Le post-mortem est sans blâme, nomme les facteurs contributifs, et arrive avec des éléments d'action suivis dans le même carnet de tâches que le travail de fonctionnalités. Les incidents graves déclenchent une notification aux clients touchés avec l'échéancier et la correction, conformément à la fenêtre de notification de brèche applicable (CCPA, PIPEDA et lois des États) le cas échéant.