Skip to content
Propriété et hébergement canadiens. Vos documents restent au Canada.
Sécurité

La page à remettre à votre évaluateur en sécurité

Tout ce qui suit se trouve également ailleurs sur ce site ou dans nos ententes. C’est rassemblé ici parce qu’un questionnaire se remplit d’une traite, et non en parcourant un site Web.

Où la solution fonctionne

Sur du matériel que Nimble possède et exploite. Aucun hyperscaler en dessous, et il n’existe aucune option d’hébergement chez le client ni d’infonuagique apportée par le client.

Installations canadiennes

Des installations certifiées Protégé B à Aurora, Ottawa et Winnipeg, dotées de personnel canadien détenant une cote de sécurité. Vos documents y sont stockés, traités et sauvegardés.

Compétence juridique canadienne

Nimble est de propriété canadienne et n’a aucune société mère étrangère : aucun tribunal ni aucune loi d’un autre pays, CLOUD Act américain compris, ne dispose donc d’un moyen de contraindre l’entreprise qui exploite les serveurs.

Exploitation auditée

Nimble est auditée SOC 2 Type II, aligne son infrastructure sur l’ITSG-33 et se conforme à la LPRPDE, à la LPRPS, à la LAIPVP et à l’ITSP.10.033.

Chiffrement

En transit et au repos, le volet « au repos » allant plus loin que ce que l’expression désigne habituellement.

En transit
Tout ce qui circule entre un navigateur et NimbleSign passe par TLS, y compris les liens qu’ouvrent les signataires et les rappels webhook que reçoivent vos systèmes.
Au repos
Les documents et les images de signature sont chiffrés en AES-256-GCM sous une clé détenue par le déploiement, chacun avec son propre nonce aléatoire. Le mode GCM authentifie en plus de chiffrer : un bloc altéré ou déchiffré avec la mauvaise clé échoue bruyamment plutôt que de produire un résultat plausible.
Les clés se renouvellent sans migration
Chaque objet stocké consigne la clé sous laquelle il a été écrit : un renouvellement met l’ancienne clé à la retraite au lieu de rechiffrer l’ensemble du parc, et savoir quels objets en dépendent encore relève d’une requête plutôt que d’un balayage du système de fichiers.
Les identifiants stockés aussi
Les paramètres marqués comme secrets, tels qu’un mot de passe SMTP ou un identifiant d’API, sont chiffrés sous la même clé et ne peuvent jamais être relus depuis la console qui les définit.

Qui voit quoi

Trois rôles, et une frontière organisationnelle qu’aucune requête ne franchit.

Les rôles

Un administrateur gère les comptes et voit toute l’organisation. Un expéditeur envoie des enveloppes et ne voit que les siennes. Un lecteur consulte l’organisation sans rien modifier.

Vérifié trois fois

Une requête est autorisée au niveau de la page, de nouveau dans le service qui la traite, puis une troisième fois dans la requête de données, restreinte à l’organisation de l’appelant avant son exécution. L’API REST passe par les mêmes services : sa portée est donc identique.

Démontré, et non affirmé

Une suite de tests existe uniquement pour échouer si une organisation peut lire ou modifier les données d’une autre, à chacune des couches. Elle s’exécute à chaque compilation.

L’accès

Votre personnel se connecte. Vos signataires, jamais.

Mots de passe
Douze caractères au minimum, sans règle de catégories de caractères ni changement obligatoire, car ces deux exigences poussent les gens vers un mot de passe prévisible et un papillon adhésif. Ce qui est refusé, ce sont plutôt les formes utilisées pour atteindre douze caractères : un mot courant complété par des chiffres, un caractère répété, une suite sur le clavier, ou le nom ou le courriel du compte lui-même.
Vérification en deux étapes
Des codes d’application d’authentification standard, accompagnés de codes de récupération à usage unique. Une organisation peut l’exiger de chaque membre : un compte non inscrit s’inscrit alors avant la fin de la connexion plutôt qu’après.
Ou votre propre fournisseur d’identité
L’authentification unique auprès de l’annuaire que vous exploitez déjà : les arrivées et les départs se gèrent là où vous les gérez déjà, et il n’y a pas de second mot de passe à administrer.
Les sessions prennent fin quand vous le décidez
Désactiver un compte ou changer son mot de passe invalide ses sessions en cours : l’accès cesse au moment où vous le révoquez, et non à l’expiration fortuite d’un témoin.
Les signataires ne créent aucun compte
Un signataire ouvre un lien à usage unique et confirme un code. Aucun mot de passe à réutiliser, aucun compte à compromettre, et rien à installer.

Ce qui est consigné

Chaque étape d’une enveloppe, dans un ordre qui ne peut être modifié discrètement par la suite.

Une chaîne, pas un journal

Chaque événement est chaîné par empreinte au précédent. Supprimer ou modifier une entrée rompt la chaîne, et la rupture est détectable par quiconque détient l’enveloppe terminée.

Scellée à l’achèvement

Une enveloppe terminée porte un sceau numérique couvrant à la fois les documents et le certificat, avec un horodatage de confiance lorsqu’il en est configuré un.

Et elle se vérifie

Le certificat indique la réussite ou l’échec de la vérification par rapport à cette chaîne : une modification après coup ne paraît pas seulement suspecte, elle échoue à un contrôle que n’importe qui peut exécuter.

Si quelque chose tourne mal

Aucun système n’est parfaitement sûr, et une page qui laisse entendre le contraire ne mérite pas d’être lue. Si une atteinte à nos mesures de sécurité crée un risque réel de préjudice grave, nous en avisons les personnes touchées ainsi que le Commissariat à la protection de la vie privée du Canada, comme l’exige la LPRPDE, de même que les clients touchés sans délai indu.

Le responsable de la protection de la vie privée de Nimble en répond, et il est également la personne responsable de la protection des renseignements personnels au sens de la loi québécoise.

L’engagement intégral, dans la politique de confidentialité

Et si vous partez

Pendant 30 jours après la fermeture d’un compte, vous pouvez exporter vos enveloppes terminées et leurs certificats dans des formats courants. Le contenu est ensuite supprimé des systèmes actifs selon notre calendrier de conservation, les sauvegardes expirant selon un cycle défini.

Tout ce qui a déjà été téléchargé continue de fonctionner. Un document scellé se vérifie de lui-même, sans nous et sans compte.

Ce que nous ne prétendons pas

Un évaluateur qui découvre une lacune que nous avons passée sous silence ne fait plus confiance au reste de la page. Voici donc les nôtres.

NimbleSign ne détient aucune certification qui lui soit propre
Protégé B, SOC 2 Type II et ITSG-33 décrivent Nimble et l’infrastructure sur laquelle NimbleSign fonctionne. Ce ne sont pas des certifications de produit, et nous préférons le dire plutôt que de laisser un écusson le sous-entendre.
Ce n’est pas une signature électronique sécurisée
Une signature NimbleSign est une signature électronique valide au sens de la LPRPDE ainsi que des lois ESIGN et UETA. Un petit nombre d’usages fédéraux exigent une « signature électronique sécurisée », une norme plus étroite fondée sur des certificats délivrés par une autorité reconnue par le gouvernement. C’est autre chose, et ce n’est pas ce dont il s’agit ici.
Aucune norme d’accessibilité n’est revendiquée
Nous décrivons ce que le produit fait réellement plutôt que de nommer une norme pour laquelle nous n’avons pas été audités.
Aucun taux de disponibilité n’est publié
Cette page ne comporte aucun engagement de niveau de service, parce qu’aucun n’a été fixé. Si votre évaluation en exige un, demandez-le : vous obtiendrez une réponse plutôt qu’un chiffre rédigé pour un site Web.

Il vous reste un questionnaire à remplir ?

Envoyez-le-nous. Nous préférons y répondre plutôt que de vous laisser deviner à partir d’un site Web, et les réponses viennent des personnes qui exploitent la solution.

D’où cela provient : la politique de confidentialité régit les renseignements personnels et les conditions d’utilisation régissent le service. En cas de divergence entre la présente page et l’une ou l’autre, l’entente prévaut.