Document en cours de validation

Ce texte est un projet de travail. Certaines mentions restent à compléter et l'ensemble doit être validé par un professionnel du droit avant de faire foi. Il ne constitue pas un engagement contractuel en l'état.

Sécurité & divulgation responsable

Dernière mise à jour {{À VALIDER : date}}
Cette page décrit les pratiques de sécurité de RingSync et notre politique de divulgation responsable des vulnérabilités.

01Avertissement important

Ce document est un projet de travail. Il doit être relu et validé par un professionnel du droit qualifié et par l'équipe sécurité avant toute publication.

02Notre engagement en matière de sécurité

La sécurité est au fondement de la conception produit de RingSync. Le service est construit sur une architecture sans stockage de contacts : les données de contact de l'annuaire transitent en mémoire par notre proxy et sont écrites directement sur les appareils des collaborateurs — elles ne sont jamais persistées dans la base de données RingSync.

Les tokens OAuth (identifiants applicatifs Microsoft) sont chiffrés au repos dans Supabase Vault (chiffrement AES-256 en enveloppe). Ils ne sont déchiffrés en mémoire que le temps de chaque appel API proxysé.

Toutes les données en transit sont protégées par TLS 1.2 ou supérieur. Les tokens de session mobile sont stockés dans l'enclave sécurisée de l'appareil via Expo SecureStore (iOS Keychain / Android Keystore).

L'infrastructure principale de RingSync est hébergée dans l'Union européenne. {{À VALIDER : préciser la région et le fournisseur d'infrastructure}}.

{{À VALIDER : SOC 2 Type II — audit en cours, certification attendue pour {{À VALIDER : date}}}}.

03Points forts de sécurité de l'architecture

  • Aucun accès direct à la base de données depuis le code client : toutes les opérations en base passent par des API routes côté serveur utilisant des credentials service-role.
  • Row-Level Security (RLS) sur toutes les tables Supabase : chaque administrateur ne peut lire que les données appartenant à sa propre organisation.
  • Credentials applicatifs pour Microsoft Graph : RingSync utilise le flux OAuth client_credentials côté serveur ; les tokens Microsoft personnels des collaborateurs ne sont pas stockés.
  • Wipe sélectif : lors du déprovisionnement d'un utilisateur, seuls les contacts tagués pour cet annuaire spécifique sont supprimés de l'appareil — les contacts des autres annuaires ne sont pas affectés.
  • Révocation de session : les JWT mobiles peuvent être révoqués individuellement via le flag session_revoked_at, avec effet immédiat au prochain appel API.

04Politique de divulgation responsable

RingSync accueille favorablement les signalements de vulnérabilités de sécurité par la communauté des chercheurs en sécurité. Nous vous demandons de :

  • Nous signaler la vulnérabilité avant toute divulgation publique, en nous laissant un délai raisonnable pour l'analyser et la corriger.
  • Ne pas exploiter la vulnérabilité au-delà de ce qui est strictement nécessaire pour en démontrer l'existence.
  • Ne pas accéder aux données d'autres clients, les modifier ou les supprimer.
  • Ne pas effectuer de tests de déni de service ni de scan automatisé sans autorisation écrite préalable.

Pour soumettre un signalement, utilisez le canal Sécurité & signalement de vulnérabilités accessible depuis /contact. N'envoyez pas les signalements de vulnérabilités à l'adresse support générale.

Nous nous engageons à : accuser réception de votre signalement dans les 24 heures ; vous communiquer une première évaluation de triage dans les 72 heures ; vous tenir informé de l'avancement ; vous citer dans nos remerciements sécurité (sauf si vous préférez rester anonyme).

Nous ne disposons pas actuellement d'un programme de bug bounty rémunéré. {{À VALIDER : si un programme HackerOne / Bugcrowd est envisagé}}.

Clé PGP pour les signalements chiffrés : {{À VALIDER : empreinte de clé PGP ou suppression de cette mention si non applicable}}.

05Réponse aux incidents

En cas d'incident de sécurité confirmé affectant des données clients, RingSync procédera à : la containment de l'incident ; la notification des clients concernés dans un délai de {{À VALIDER : durée — 72 heures recommandé par le RGPD pour la notification à l'autorité}} à compter de la prise de connaissance de la violation ; la notification à la CNIL (ou à l'autorité de contrôle compétente) lorsque l'art. 33 RGPD l'exige.

{{À VALIDER : politique interne de gestion des incidents — AIPD, registre des violations}}.