Modèle de sécurité
Hosted Kanera est conçu avec des contrôles en couches sur la sécurité des applications, l'infrastructure, la surveillance, la gestion des accès et l'examen opérationnel.
Kanera auto-hébergé donne à votre équipe le contrôle de l'environnement d'exécution. Ce contrôle signifie également que votre organisation est responsable du renforcement du déploiement, de l’application des correctifs, des sauvegardes, de l’exposition du réseau et de la surveillance.
Contrôles d'application actuels
Les contrôles ci-dessous décrivent la mise en œuvre actuelle de Kanera examinée le 20 août 2026. Ils ne constituent pas une déclaration selon laquelle Kanera détient une certification de sécurité ou une opinion d'audit indépendante. Nous mettons à jour cette section lorsque les contrôles ou l'architecture changent sensiblement.
- Les mots de passe sont hachés avec Argon2id en utilisant une configuration explicite en mémoire dure. La vérification de la connexion utilise également un chemin à synchronisation temporelle pour réduire les signaux d'énumération des comptes.
- Les jetons d'actualisation sont aléatoires, stockés uniquement sous forme de hachages SHA-256, alternés lors de leur utilisation et révoqués en tant que famille lorsqu'une réutilisation est détectée. Le cookie d'actualisation de production est HttpOnly, Secure, SameSite=Lax et limité aux routes d'authentification.
- L'authentification multifacteur à mot de passe unique basée sur le temps comprend des secrets cryptés, des codes de récupération à usage unique stockés sous forme de hachages, une protection contre la relecture et une tentative de verrouillage. Les administrateurs de l'organisation peuvent exiger la MFA pour que les membres et les invités du tableau accèdent à leurs données.
- L'authentification, la réinitialisation du mot de passe, la MFA, l'API publique, le MCP et d'autres routes sensibles utilisent des limites de débit ou des contrôles de tentatives. Cloudflare Turnstile peut protéger les flux d'inscription et de réinitialisation de mot de passe hébergés.
- Les autorisations d'organisation, d'espace de travail, de tableau, d'invité, de clé API et OAuth sont appliquées côté serveur. Les clés API Workspace ont des étendues de lecture, d'écriture ou d'administration ; les clés personnelles suivent les autorisations actuelles du propriétaire ; OAuth utilise des URI de redirection exacts et PKCE.
- Les clés API, les jetons OAuth, les codes de vérification, les jetons d'invitation et les secrets client sont stockés sous forme de hachages. MFA et les secrets d’intégration configurés sont chiffrés au repos.
- Les réponses HTTP utilisent des contrôles, notamment HSTS, une protection contre le reniflage de type de contenu, des restrictions de trame, une stratégie de référencement, une stratégie de sécurité du contenu et une stratégie d'autorisations.
- L'accès au support multi-locataires est limité aux administrateurs de plateforme autorisés, limité dans le temps, révocable, visiblement indiqué dans le produit et enregistré avec l'opérateur, l'organisation cible, la raison, l'adresse IP, l'agent utilisateur, l'heure de début, d'expiration et de fin. Les mutations administratives sont écrites dans une piste d’audit distincte.
Responsabilités d'auto-hébergement
- Exécutez Kanera derrière HTTPS avec des certificats de confiance.
- Gardez Kanera, les dépendances, les systèmes d'exploitation, les conteneurs, les bases de données et les proxys inverses à jour.
- Limitez l’accès administratif, protégez les secrets et alternez les informations d’identification si nécessaire.
- Activez et configurez les outils de sauvegarde auto-hébergés en option de Kanera, ou fournissez un processus de sauvegarde équivalent, puis testez régulièrement la restauration.
- Examinez l’exposition du réseau, les règles de pare-feu, les autorisations de stockage et les informations d’identification d’intégration.
Vos responsabilités en matière de sécurité
- Utilisez un mot de passe unique et activez l'authentification multifacteur lorsqu'elle est disponible ou requise par votre organisation.
- Gardez vos navigateurs, appareils, déploiement Kanera et outils connectés à jour et protégez les appareils et les sauvegardes contre tout accès non autorisé.
- Accordez aux utilisateurs, aux clés API, aux clients OAuth ou MCP, aux webhooks et autres intégrations uniquement les autorisations dont ils ont besoin et vérifiez régulièrement cet accès.
- Supprimez les utilisateurs et les intégrations inutilisés, révoquez les informations d'identification et les sessions qui, selon vous, pourraient être compromises, et signalez rapidement les accès non autorisés suspectés aux comptes.
- Examinez les pratiques de sécurité et de confidentialité des fournisseurs tiers avant d'envoyer des informations confidentielles, personnelles ou réglementées via une intégration.
Protection des données
Les propriétaires d'espace de travail contrôlent quels utilisateurs sont invités, quel accès ils reçoivent et quel contenu est placé dans Kanera.
Kanera ne doit pas être utilisé pour stocker des données hautement réglementées, sauf si votre organisation a examiné le déploiement, la configuration, les conditions contractuelles et les exigences légales pour cette utilisation.
Pour Kanera hébergé, nos engagements contractuels en matière de sécurité, de notification d'incident, de sous-traitant secondaire, d'assistance, d'audit et de suppression sont définis dans l'addendum sur le traitement des données. Nous informons sans délai les clients concernés d’une violation confirmée des données personnelles et fournissons les informations raisonnablement disponibles pour étayer leur réponse.
Signalement des vulnérabilités
Envoyez par e-mail les vulnérabilités suspectées à [email protected] ; n’utilisez pas une question publique. Incluez le composant, la version, l'URL, le point de terminaison ou le mode de déploiement concerné ; des étapes de reproduction ou une preuve de concept minimale ; impact probable ; demandes, journaux ou captures d'écran pertinents avec les secrets supprimés ; et vos coordonnées préférées et si vous souhaitez un crédit public. Notre objectif est d’accuser réception d’un rapport dans un délai de 3 jours ouvrables et de fournir une première évaluation ou une demande de plus d’informations dans un délai de 10 jours ouvrables. Ce sont des objectifs, pas des garanties.
Sont concernés l'authentification et l'autorisation, l'isolation des locataires, l'accès au tableau privé, les secrets stockés et les fuites de jetons, les téléchargements et la gestion des fichiers, les API, OAuth, MCP, les webhooks, les fonctionnalités en temps réel, les limites de facturation et le déploiement auto-hébergé par défaut. L'ingénierie sociale, le spam, les résultats qui dépendent uniquement de paramètres de développement intentionnellement faibles et les tests de déni de service en production sans autorisation écrite sont hors de portée.
Nous ne publions pas actuellement de clé PGP et le courrier électronique ordinaire n'est pas un canal de reporting crypté de bout en bout. N’envoyez pas d’informations d’identification en direct ou de données personnelles. Demandez dans le premier e-mail si vous avez besoin de notre part pour organiser un échange plus sécurisé de preuves sensibles.
Règles de sécurité et divulgation
Si vous agissez de bonne foi, testez uniquement les comptes, les données et les systèmes que vous possédez ou avez l'autorisation explicite de tester, restez dans le champ d'application ci-dessus, évitez les violations de la vie privée et les interruptions de service, accédez uniquement aux données minimales nécessaires pour démontrer le problème, arrêtez et signalez si vous rencontrez les données d'une autre personne, ne conservez pas ou ne divulguez pas ces données et respectez la loi applicable, nous traiterons la recherche comme autorisée aux fins de notre politique et n'engagerons aucune action en justice contre vous pour la recherche elle-même. Il ne s’agit pas d’une autorisation de tester des systèmes ou des infrastructures tiers hors de notre contrôle, de recourir à l’ingénierie sociale ou à des attaques physiques, ni d’exiger un paiement.
Veuillez nous donner une opportunité raisonnable d'enquêter et de remédier à la situation avant toute divulgation publique. Nous travaillerons avec vous sur un calendrier de divulgation en fonction de la gravité, des utilisateurs concernés, de la disponibilité des correctifs et des besoins de déploiement, et nous visons à vous tenir informé des étapes importantes. Si vous pensez qu'une divulgation urgente est nécessaire, expliquez le risque à [email protected] afin que nous puissions nous coordonner.
Supprimez les données de test et les preuves confidentielles lorsqu’elles ne sont plus nécessaires. Si vous accédez involontairement à des données personnelles, des informations d'identification ou du contenu client, arrêtez les tests, ne les copiez pas et ne les partagez pas, et dites-nous à quoi vous avez accédé afin que nous puissions répondre de manière appropriée.
Historique des versions
La version 2 entre en vigueur le 20 août 2026. Elle distingue l'examen de la mise en œuvre de la certification indépendante et relie l'incident contractuel et les engagements de sécurité dans le DPA. La version 1 est entrée en vigueur le 16 juillet 2026.