L’isolation
Tous les clients partagent une seule base de données, et chaque table contenant des données de clients porte un identifiant d’organisation. Les requêtes filtrent dessus sans exception, et cet identifiant est lu dans le jeton de session vérifié plutôt que dans quoi que ce soit fourni par la requête — il n’y a donc aucun paramètre à altérer.
Il existe une suite de tests dont l’unique objet est de tenter des lectures et des écritures entre clients et de vérifier qu’elles échouent toutes.
Deux jeux de clés
Les sessions clients et nos propres sessions d’exploitation sont signées avec des clés différentes, et cette séparation est structurelle plutôt qu’esthétique. Notre couche de données traite une condition absente comme « aucune condition », de sorte qu’un jeton valablement signé mais dépourvu de ses attributs correspondrait autrement à un compte quelconque. Des clés différentes font qu’un tel jeton échoue à la signature et n’atteint jamais ce code.
La console d’exploitation
La console qui nous sert à administrer les clients est sur son propre nom d’hôte, exige un deuxième facteur sans possibilité de s’y soustraire, et n’a aucune route d’inscription — les comptes sont créés à la main. Sa session vit dans un témoin que le JavaScript de la page ne peut pas lire, parce que cette console peut énumérer tous les clients et qu’une session durable volée y compterait bien davantage que celle d’une seule personne.
Les sessions
Les jetons d’accès sont de courte durée et les jetons de rafraîchissement sont rotatifs. Réutiliser un ancien est traité comme un vol et révoque toute la chaîne plutôt que de refuser cette seule requête. Les échecs répétés de connexion verrouillent le compte lui-même, et non l’adresse d’où ils venaient, parce que verrouiller par adresse est trivial à contourner en les répartissant.
Quand un flux appelle vos systèmes
Un flux d’appel peut adresser une requête sortante — pour vérifier quelque chose avant de décider où acheminer un appelant. C’est une chose réellement dangereuse à autoriser, alors elle passe par un pare-feu qui nous est propre : HTTPS uniquement, et seulement vers des hôtes qu’un administrateur a explicitement ajoutés, avec refus par défaut.
La vérification de l’adresse se fait à l’intérieur de la résolution de nom plutôt qu’avant, de sorte que l’adresse approuvée est bien celle à laquelle on se connecte. Vérifier d’abord et se connecter ensuite laisse une fenêtre pendant laquelle un nom peut être repointé. Les redirections relancent toute la vérification, puisqu’un hôte autorisé répondant par une redirection vers une adresse interne est la façon habituelle de contourner ce genre de contrôle.
L’enregistrement
À deux canaux, et la politique appartient à l’organisation plutôt qu’à l’individu : toujours, au choix de la personne, ou jamais, plus le droit ou non d’arrêter un enregistrement en cours. L’écoute est permissionnée séparément de l’enregistrement.
Ce que nous n’avons pas
Aucune certification de sécurité indépendante. Aucune authentification fédérée. Aucun journal d’événements administratifs exportable — les actions sont attribuables dans nos propres journaux, mais il n’existe aucun rapport que vous puissiez extraire vous-même. Aucun calendrier de conservation configurable pour l’instant, et les demandes de suppression sont traitées à la main plutôt qu’au moyen d’une exportation en libre-service.
Chacun de ces points est sur la liste. Si l’un d’eux est ce sur quoi votre processus d’approvisionnement va réellement buter, demandez-le et je vous dirai où il en est vraiment plutôt que ce qui serait commode.