Tenues à l’écart
Les appels de plusieurs entreprises sont dans la même base de données, et chaque dossier porte l’entreprise à qui il appartient. Quelle entreprise vous êtes vient de votre session, jamais de ce qu’une requête raconte, alors il n’y a rien à trafiquer.
Une suite de vérifications automatisées n’existe que pour lancer la session d’une entreprise contre les dossiers de toutes les autres, et prouver que tout échoue.
Notre personnel se connecte autrement que le vôtre
Les sessions de votre monde et celles dont nous nous servons pour administrer les clients sont signées avec deux clés différentes. Si une session arrivait un jour sans dire à qui elle appartient, c’est cette séparation qui la fait échouer net au lieu de la faire correspondre à quelqu’un par accident.
Comment nous entrons
La console qui nous sert à administrer les clients a sa propre adresse, demande toujours un deuxième facteur, et n’a aucune façon de s’inscrire : nous créons chaque compte à la main. Sa session est gardée là où les scripts de la page ne peuvent pas la lire, parce que cette console peut énumérer tous les clients et qu’une session volée y compterait bien plus que celle d’une seule personne.
Rester connecté
Vous restez connecté grâce à un laissez-passer de courte durée qui se renouvelle de lui-même. Un ancien laissez-passer réutilisé est traité comme un vol et met fin à toute la session, pas seulement à cette requête-là. Trop de mauvais mots de passe verrouillent le compte, et non l’adresse d’où ils venaient, parce qu’une adresse se change facilement.
Chacun peut ajouter une application d’authentification à son propre compte, et l’activer ou la désactiver met fin à toutes les sessions ouvertes, y compris celle qui a fait le changement.
Quand votre menu consulte votre système
Votre menu téléphonique peut consulter votre propre système à propos d’un appelant avant de décider où l’envoyer. C’est une chose risquée à permettre, alors elle passe par un pare-feu qui nous est propre : seulement sur une connexion sécurisée, et seulement vers les adresses que vous avez approuvées. Tout le reste est refusé.
L’adresse est vérifiée au moment de la connexion, pas avant, de sorte que ce que nous avons approuvé est bien ce que nous atteignons. Une redirection repasse par toute la vérification.
L’enregistrement
Les deux côtés d’un appel sont enregistrés séparément. C’est l’entreprise qui fixe la règle, pas chaque personne : toujours, au choix de la personne, ou jamais, plus le droit ou non pour la personne en ligne d’arrêter un enregistrement en cours. Réécouter un enregistrement est une permission distincte de celle d’en faire un.
Ce qui tourne en dessous
Chaque table bornée à un locataire porte un identifiant de locataire, chaque requête filtre dessus, 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. La suite d’isolation lance la session d’un locataire contre chaque routeur borné et exige que tout échoue ; c’est une suite parmi les plus de 1 100 vérifications automatisées qui tournent à chaque construction.
Les sessions des clients et celles d’exploitation sont signées avec des clés séparées parce que notre couche de données traite une condition indéfinie comme une condition omise : un jeton valablement signé mais dépourvu de ses attributs correspondrait autrement à un compte quelconque. La clé d’exploitation est dérivée de la clé des clients par HMAC sur une chaîne de domaine plutôt que posée comme un second secret, de sorte qu’il n’y a aucun déploiement sans la séparation.
La console d’exploitation est sur son propre nom d’hôte, exige un code à usage unique fondé sur l’heure sans possibilité de s’y soustraire, n’a aucune route d’inscription, et garde sa session dans un témoin httpOnly. Les jetons d’accès des clients sont de courte durée et les jetons de rafraîchissement sont rotatifs ; rejouer un jeton de rafraîchissement déjà utilisé révoque toute la chaîne, et les échecs répétés de connexion verrouillent le compte plutôt que l’adresse.
Le pare-feu de sortie du bloc HTTP est une liste d’autorisation avec refus par défaut, HTTPS uniquement, et la vérification de l’adresse se fait à l’intérieur de la résolution DNS plutôt qu’avant, de sorte que l’adresse approuvée est bien celle à laquelle on se connecte. Chaque redirection relance 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.
Les questions qu’on nous pose
Où sont hébergées mes données ?
Chez AWS dans us-east-1, soit la Virginie du Nord, aux États-Unis. Pas une région canadienne, et il n’y a pas d’option d’hébergement canadien ni européen. L’audio des appels est chez Twilio, sans région fixée. Si vous êtes une entreprise québécoise, nous transmettre des renseignements personnels constitue une communication hors Québec, et la Loi 25 vous demande de l’évaluer avant de commencer plutôt qu’après.
Mes données sont-elles chiffrées ?
Le trafic est chiffré en transit, et les mots de passe sont hachés avec bcrypt plutôt que conservés sous une forme que nous pourrions relire. L’audio des enregistrements et des messages vocaux est détenu par Twilio plutôt que sur un stockage à nous, et nous en gardons une référence et ses détails ; la liste des sous-traitants nomme qui reçoit quoi plutôt que de vous laisser le deviner.
Qui, chez Ringfully, peut écouter un enregistrement ?
Rien dans la console qui nous sert à administrer les clients n’en joue un. Elle énumère les comptes, leurs numéros et leurs réglages, et elle n’a aucune façon de se connecter à la place d’une de vos personnes. Dans votre propre entreprise, réécouter un enregistrement est une permission à part, distincte de celle qui permet d’en faire un, et chaque écoute et chaque téléchargement sont inscrits au journal que vos administrateurs peuvent lire et exporter.
Qu’arrive-t-il à mes données si je pars ?
Demandez-le dans les trente jours suivant la fin et nous vous remettons une copie de vos données, puis nous les supprimons, y compris des sauvegardes à leur cycle ordinaire ; passé ce délai, nous pouvons les supprimer sans redemander. Tant que vous êtes avec nous, la suppression tourne déjà selon un calendrier que vous fixez, avec trente jours pour les enregistrements et quatre-vingt-dix pour les messages vocaux quand personne n’a rien fixé, appliqué par une tâche nocturne. Il n’y a aucune archive derrière tout ça : raccourcir une durée supprime au prochain passage, et c’est irréversible.
Que faites-vous s’il y a une atteinte ?
Nous vous prévenons sans retard injustifié dès que nous le savons, avec ce que nous avons à ce moment-là : ce qui s’est produit, quelles catégories et approximativement combien d’enregistrements, les conséquences probables, et ce que nous faisons. Ensuite nous vous tenons au courant à mesure plutôt que d’attendre un portrait complet. Quand une atteinte présente un risque réel de préjudice sérieux, les personnes touchées et l’autorité compétente en sont avisées aussi, et nous tenons un registre des incidents qu’ils atteignent ou non ce seuil.
Ce que nous n’avons pas
Aucune certification de sécurité indépendante, et aucune authentification fédérée. Ce sont les vraies lacunes. Ce qui les accompagnait ne tient plus : les administrateurs exportent eux-mêmes le journal d’événements, les durées de conservation se configurent par catégorie de données et une tâche nocturne les applique, et une demande d’exportation ou d’effacement des données d’une personne se traite depuis le produit plutôt qu’à la main.
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 nous vous dirons où il en est vraiment plutôt que ce qui serait commode.