Sécurité des données
SecureCodingHub est conçu avec la sécurité à chaque couche. Cette page couvre comment nous protégeons les données de votre organisation.
Chiffrement
Toutes les données sont protégées avec un chiffrement standard de l'industrie :
En transit
Toutes les données sont chiffrées en utilisant TLS 1.2+ entre votre navigateur et nos serveurs. Aucune transmission en clair.
Au repos
Toutes les données au repos sont chiffrées en utilisant le chiffrement AES-256. Les sauvegardes de base de données sont chiffrées.
Infrastructure
- Hébergé sur AWS (région US)
- Application et base de données sur des réseaux isolés
- Correctifs et mises à jour de sécurité réguliers
- Protection DDoS via AWS Shield
- Surveillance et alertes automatisées
Gestion des données
Voici ce que nous stockons comme données et pourquoi :
| Type de données | Stockées | Objectif |
|---|---|---|
| E-mail et nom de l'utilisateur | Oui | Identification du compte |
| Progression et scores des challenges | Oui | Suivi de formation |
| Préférences technologiques | Oui | Personnalisation |
| Tokens d'authentification | Temporaire | Gestion de session |
| Mots de passe | Non | Nous utilisons l'authentification sans mot de passe |
| Code source | Non | Les challenges sont uniquement côté client |
Conformité
- Conforme RGPD — traitement de données avec base d'intérêt légitime / contrat
- Les utilisateurs peuvent demander l'export ou la suppression des données
- Rétention des données : comptes actifs retenus indéfiniment, comptes supprimés purgés après 90 jours
- Sous-traitants listés dans notre politique de confidentialité
Contrôle d'accès
- Contrôle d'accès basé sur les rôles dans chaque organisation (
org_adminetlearner) - Isolation des données au niveau de l'organisation (multi-tenant) — chaque enregistrement porte une portée
organizationIdimposée dans la couche d'accès aux données - Authentification par token SCIM pour les API de provisionnement (conditionnée à la configuration préalable de SSO)
- Limitation de débit par clé API sur la surface REST publique et webhook (60 requêtes/minute et 1 000 requêtes/heure par clé) ; un limiteur IP séparé sur le formulaire de contact web anonyme (5 / 15 minutes)
- Tokens bearer JWT pour les points de terminaison admin et apprenant orientés navigateur ; clés API hachées à longue durée de vie pour la surface publique — détails complets dans Authentification
Signature de webhook
Les webhooks sortants de SecureCodingHub vers vos points de terminaison sont signés avec HMAC-SHA256 en utilisant un secret par point de terminaison qui est affiché à l'administrateur une fois à la création du point de terminaison et jamais renvoyé. L'en-tête de signature a la forme t=<unix_seconds>,v1=<hex> ; la charge utile signée est <t>.<raw_body>. Les récepteurs devraient rejeter toute livraison dont l'horodatage est à plus de 5 minutes de l'horloge du récepteur pour se défendre contre la rediffusion, et comparer les signatures en temps constant.
La livraison est au-moins-une-fois. Les livraisons échouées (toute réponse non-2xx ou échec réseau) sont retentées avec un backoff exponentiel sur un calendrier 1m / 5m / 30m / 2h / tentative finale. Après cinq tentatives échouées, le point de terminaison est automatiquement désactivé et l'administrateur d'organisation est notifié via le journal d'audit. Les exemples de code de configuration et de vérification vivent à API → Webhooks.
Gestion des secrets au niveau de l'application
Trois types de secrets sont gérés au niveau de l'application ; leur gestion sur disque est décrite ici pour complétude aux côtés du chiffrement au niveau du stockage ci-dessus.
| Secret | Stockage | Durée de vie |
|---|---|---|
| Clés API publiques | Seuls le hash SHA-256, le préfixe de 9 caractères (scs_live_) et les quatre derniers caractères sont persistés. Le token complet est affiché une fois à la création et ne peut pas être récupéré à nouveau depuis le serveur. | Indéfinie par défaut. Une date d'expiration optionnelle peut être définie à la création. La révocation prend effet immédiatement. |
| Secrets de signature de webhook | Stockés en clair aux côtés de l'enregistrement du point de terminaison webhook car le serveur a besoin de la valeur brute pour signer chaque livraison sortante. Affichés une fois à la création et jamais renvoyés via l'API. La rotation nécessite la suppression et la recréation du point de terminaison. | Vit aussi longtemps que le point de terminaison webhook. |
| Codes magiques (OTP e-mail) | Le code à 6 chiffres est persisté en clair sur la ligne de code magique. Les codes sont à usage unique et liés à l'e-mail de l'utilisateur ; la ligne est marquée comme consommée après la première vérification. | Chaque code expire 10 minutes après l'émission. Les codes expirés non consommés restent sur la table comme piste d'audit jusqu'à ce que le nettoyage les efface. |
| Secrets client SSO / certificats SAML | Stockés en clair sur l'enregistrement SchSsoConfig car le serveur a besoin des valeurs brutes pour négocier avec l'IdP. Non exposés via aucun point de terminaison de lecture après l'enregistrement de la configuration. | Vit aussi longtemps que la configuration SSO. |
Signalement des vulnérabilités
Si vous découvrez une vulnérabilité de sécurité, contactez security@securecodinghub.com. Nous prenons tous les rapports au sérieux et visons à répondre dans les 48 heures.
Classification des données chez SecureCodingHub
Nous traitons les données de notre environnement comme tombant dans trois compartiments pratiques. Les données client sont des informations qui appartiennent à votre organisation et que vos utilisateurs ont saisies ou générées via la plateforme : identifiants de compte, adresses e-mail des apprenants, attributions de rôle, progression de formation, scores sur les challenges individuels et préférences technologiques. Ce compartiment est celui qui intéresse votre DPO et celui que nous traitons comme le niveau de plus haute sensibilité en interne.
La télémétrie opérationnelle est le deuxième compartiment. Elle couvre les journaux de requêtes, les métriques de performance anonymisées, les traces d'erreur avec identifiants personnels supprimés et les compteurs utilisés pour faire ressortir les tableaux de bord de fiabilité à l'échelle de la plateforme. Ces données sont nécessaires pour faire fonctionner le service en toute sécurité et sont retenues sur une fenêtre glissante plus courte que les données client. Le troisième compartiment est le contenu de challenge lui-même — les échantillons de code vulnérables, les indices et les solutions de référence que nous écrivons et livrons à vos utilisateurs. Ce contenu est notre propriété intellectuelle, non la vôtre, et il n'est pas mélangé avec les enregistrements de votre organisation.
Les fenêtres de rétention diffèrent en conséquence. Les comptes client actifs sont retenus pendant que le contrat est en vigueur. À la suppression du compte, nous purgeons les données client identifiables sur une horloge de 90 jours, le décalage existant pour qu'une suppression accidentelle puisse être inversée dans la fenêtre. La télémétrie opérationnelle s'écoule sur un cycle plus court mesuré en semaines, non en mois. L'inventaire complet des données et les spécificités de rétention sont disponibles aux clients sous NDA via le canal de demande listé ci-dessous, et sont résumés pour les utilisateurs finaux dans la politique de confidentialité.
Comment le chiffrement est superposé
Le chiffrement sur SecureCodingHub n'est pas un contrôle unique — il est superposé, et chaque couche suppose que les autres peuvent échouer. Les données en transit entre vos utilisateurs et la plateforme sont protégées par un chiffrement de couche transport avec sélection de chiffrement moderne imposée au répartiteur de charge, avec les protocoles faibles et les chiffrements sujets à la rétrogradation désactivés. La même posture de transport s'applique au trafic entre les services d'application et nos magasins de données gérés ; rien à l'intérieur du VPC de production ne se déplace en clair à travers une frontière réseau.
Les données au repos sont chiffrées au niveau de la couche de stockage en utilisant les services de chiffrement fournis par notre plateforme d'hébergement, avec la gestion des clés gérée par le service de clé géré du même fournisseur plutôt que par du matériel de clé au niveau de l'application versionné dans notre code. Les sauvegardes héritent de la même posture de chiffrement que le magasin principal. Nous gardons délibérément la description ici au niveau de la politique plutôt que de publier des algorithmes spécifiques, des longueurs de clé ou des cadences de rotation sur une page publique, car publier ces valeurs invite des dépendances fragiles et offre aux attaquants une liste de cibles. Les spécificités sont disponibles sous NDA pour les revues d'achats.
L'isolation des tenants est la troisième couche. Chaque enregistrement dans le niveau des données client est limité à un identifiant d'organisation, et ce confinement est imposé dans la couche d'accès aux données plutôt que de se reposer uniquement sur des filtres au niveau de l'application. L'effet pratique est qu'un bug de requête dans une fonctionnalité ne peut pas accidentellement exposer les données d'une autre organisation via l'API, car la portée manquante se présenterait comme aucun résultat plutôt que comme les mauvais résultats. Le contrôle d'accès basé sur les rôles à l'intérieur d'une organisation est imposé par la même couche d'accès aux données, donc la portée d'organisation et le rôle d'un utilisateur déterminent ensemble quels enregistrements sont visibles avant que tout filtre au niveau de l'application ne s'exécute.
Posture des sous-traitants et de la résidence des données
SecureCodingHub est aujourd'hui hébergé uniquement dans les régions US. C'est un choix opérationnel délibéré pendant que nous sommes à notre échelle actuelle — exécuter une seule région principale simplifie notre réponse aux incidents, réduit la surface que les auditeurs doivent parcourir et garde notre liste de sous-traitants courte. Pour les organisations qui nous évaluent depuis l'extérieur des US, c'est le fait unique le plus important à faire ressortir à votre délégué à la protection des données dès le départ : les données traversent une frontière américaine par conception, et des garanties contractuelles incluant les clauses contractuelles standard sont mises à disposition pour soutenir ce transfert.
Si nous ajoutons un déploiement résident UE dans le futur, les changements seront matériels plutôt que cosmétiques. Une région principale distincte implique un ensemble distinct de sous-traitants avec des opérations résidentes UE, un ensemble distinct de destinations de sauvegarde et un avenant de traitement de données mis à jour reflétant le nouveau flux. Nous ne rétroporterons pas les organisations existantes vers une nouvelle région silencieusement ; tout déménagement serait une migration opt-in avec préavis et une fenêtre de basculement définie. La liste actuelle des sous-traitants, l'énoncé de posture régionale et un résumé de test d'intrusion actuel sont disponibles sur demande à security@securecodinghub.com. Nous répondons directement aux questionnaires de sécurité fournisseur plutôt que via des portails de confiance partagés uniquement, et nous n'exigeons pas que la partie demandeuse soit un client payant pour recevoir une liste actuelle des sous-traitants.