Aller au contenu

Sécurité

Ce qui protège une clé, une session, et le réseau entre les deux

Relay est une infrastructure : les décisions de sécurité ont été prises dès le premier jour plutôt qu’ajoutées après coup. Cette page décrit les mécanismes plutôt que les adjectifs — tout ce qui s’y trouve est vérifiable sur l’API que vous vous apprêtez à intégrer.

identifiants

Trois identifiants, dont deux ne peuvent jamais se croiser

La séparation est structurelle, elle ne repose sur aucune vérification. /v1 résout son bearer dans le stockage des clés d’API et n’y trouvera jamais de session : une session ne peut donc pas publier ; une clé n’est pas une session, elle ne peut donc pas administrer une organisation. Ni l’une ni l’autre n’est une règle qu’on pourrait oublier d’appliquer.

  • Clé d’organisation

    Bearer, longue durée

    Émise pour une organisation, limitée à un environnement, et stockée uniquement sous forme d’empreinte SHA-256 — le texte en clair n’est affiché qu’une fois, à l’émission, et ni nous ni le support ne pouvons le retrouver. Elle autorise à publier, lire, confirmer et infirmer pour cette organisation, et rien d’autre.

  • Ticket de flux

    Paramètre de requête, 300 secondes

    Un EventSource de navigateur ne peut pas poser d’en-tête Authorization : votre serveur émet donc un ticket à partir de votre clé et ne remet que lui au navigateur. Il vit dans un stockage distinct de celui des clés, si bien qu’il ne peut jamais autoriser une publication, et le pire qu’une URL divulguée puisse donner, c’est cinq minutes de flux en lecture seule.

  • Session de la console

    Cookie HttpOnly, humain

    Une session signée qui identifie une PERSONNE, jamais une organisation. Elle est posée en HttpOnly, si bien que le jeton n’atteint jamais JavaScript ; chaque lecture de la console passe par navigateur → notre serveur → Relay, et chaque modification est une server action.

comptes

Il n’y a pas de mot de passe, et c’est la position la plus solide

Dans tout système doté d’un lien de réinitialisation, contrôler la boîte mail donne déjà le contrôle du compte. Un mot de passe est donc une seconde chose à voler, qui ne donne rien de plus — la connexion se fait par un code à usage unique envoyé par e-mail, et le second facteur, optionnel, en est un vrai.

Un second facteur au moment où il compte

Activez TOTP et chaque émission de clé exige un code de confirmation, pas seulement une session ouverte. Les codes de récupération sont la seule issue en cas d’authentificateur perdu ; ils sont décomptés et peuvent être réémis depuis la page de votre compte.

Émettre une clé est un acte de propriétaire, et il ne passe pas inaperçu

Seul un propriétaire peut émettre une clé, uniquement pour l’organisation du chemin, et tous les autres propriétaires reçoivent un e-mail dans les secondes qui suivent. L’émission silencieuse est la défaillance qui compte — une clé dont on ne vous a rien dit est une clé que personne ne surveille.

Un journal d’audit en ajout seul

Clés émises et révoquées, membres invités, retirés et partis, rôles modifiés, paramètres édités — chaque action est enregistrée avec l’adresse e-mail de la personne qui l’a faite. Les lignes sont écrites, jamais modifiées, et chaque organisation consulte le sien.

Le dernier propriétaire ne peut pas partir

Une organisation sans propriétaire est une organisation que personne ne peut récupérer : la route refuse. Le même type de garde couvre les redirections après connexion, résolues par l’analyseur d’URL plutôt que par une comparaison de préfixe.

environnements

L’isolation de la sandbox est une frontière à sens unique, délibérément

Chaque identifiant porte son environnement dès la première clé qu’une organisation émet, et un événement hérite de l’environnement de l’identifiant qui l’a publié. L’asymétrie est voulue, et elle mérite d’être énoncée précisément.

Ce que la frontière garantit

Un consommateur live ne reçoit que des événements live. Rien de ce qui est publié avec une clé sandbox n’atteint jamais un abonné live, et une clé sandbox ne peut ni confirmer, ni contester, ni toucher de quelque manière un événement live — la tentative est refusée avec un statut distinct, pour qu’une intégration mal configurée échoue bruyamment plutôt que de ne rien faire en silence.

Ce qu’elle n’est pas

Ce n’est pas de la confidentialité. Une clé sandbox LIT le trafic live, à dessein : une sandbox vide est une sandbox où personne ne peut tester un filtre, alors vos tests d’intégration tournent sur le vrai flux national dès la première requête. Traitez les identifiants sandbox comme des identifiants de production pour l’accès en lecture.

les données

La donnée la plus sûre est celle qui n’a jamais été collectée

Une position de véhicule devient une donnée personnelle dès qu’elle peut être rattachée à quelqu’un. La réponse de Relay n’est pas de flouter les positions — l’imprécision détruirait la valeur de savoir sur quelle voie se trouve un obstacle — c’est qu’il n’existe aucune trace à reconstituer.

  • Aucune trajectoire, jamais

    L’API reçoit des événements ponctuels isolés. Aucun champ ne porte de trace : il n’y a donc aucun trajet à réassembler, et rien qui puisse fuiter.

  • Aucun identifiant de véhicule ni de conducteur

    Le contrat n’a aucun champ pour cela. C’est une absence, pas une pseudonymisation, et l’absence est la propriété la plus forte.

  • Aucune identité d’émetteur transmise

    Ni l’organisation, ni même un pseudonyme stable — un pseudonyme stable pour toujours est une carte de couverture de flotte à laquelle il ne manque que la légende. Nous attribuons en interne, pour la confiance et la facturation ; personne sur le réseau ne le peut.

  • Les jetons de signalant sont salés à l’arrivée

    Une confirmation porte un jeton de signalant choisi par le client, pour que des véhicules distincts puissent être comptés. Il est salé avec l’organisation dès son arrivée, et la valeur brute n’est jamais stockée.

Le détail complet, base légale et durée de conservation comprises, se trouve sur la page de confidentialité.

signalement

Signaler une vulnérabilité

Écrivez-nous : nous accusons réception sous deux jours ouvrés. Dites-nous ce que vous avez trouvé et comment le reproduire ; nous vous dirons ce que nous faisons et dans quel délai.

Les tests sur l’environnement sandbox sont bienvenus et ne demandent aucun accord préalable — émettez une clé sandbox dans la Console et allez-y. Merci de ne lancer aucun test de charge ni de déni de service contre l’environnement live, et de n’accéder à aucune donnée appartenant à une autre organisation ; si vous trouvez un moyen de le faire, c’est précisément le signalement que nous attendons.

Les certifications, les accords de traitement des données et les engagements contractuels de niveau de service se traitent accord par accord plutôt que d’être publiés comme des affirmations générales — abordez-les lors de la discussion contractuelle et nous répondrons par écrit.