Architecture de sécurité actuelle

Architecture actuelle de la préversion privée de Dossira

Ce document décrit le comportement que nous pouvons actuellement vérifier dans le code source de l’application. Il ne s’agit pas d’une liste de contrôles prévus.

1. Périmètre de l’application

Dossira repose actuellement sur un espace de travail de fichiers lié à une organisation avec :

• navigation dans les dossiers et fichiers ;
• téléversement, aperçu et téléchargement ;
• opérations courantes sur les fichiers ;
• appartenance interne à l’espace de travail ;
• partages externes créés par le propriétaire ;
• E2EE optionnel pour les opérations prises en charge sur le contenu des fichiers.

Les commentaires, les décisions, un registre d’activité de room, le scellement, l’export d’audit, la facturation et l’application de quotas ne font pas actuellement partie de la surface produit de la préversion privée.

2. Authentification et accès des destinataires

Membres internes

Les membres internes inscrits peuvent choisir une passkey sur les appareils compatibles via le système d’identité hôte. Le même sélecteur de connexion fournit également la connexion par e-mail et mot de passe ainsi que par lien magique ; les passkeys sont donc privilégiées plutôt qu’obligatoires ou exclusives.

La disponibilité des passkeys dépend de la prise en charge de WebAuthn et d’un authentificateur disponible. Dossira ne publie pas de garantie universelle concernant les navigateurs, la synchronisation des appareils ou la récupération. Les passkeys de connexion sont également distinctes des clés personnelles et d’espace de travail utilisées par l’E2EE optionnel.

Destinataires externes

Les destinataires externes utilisent actuellement :

• le partage par e-mail confirmé avec vérification par PIN ; ou
• un lien public explicitement créé.

Les destinataires externes ne reçoivent pas actuellement le même flux de passkey que les membres. L’expiration, la révocation, la prolongation et la réémission des partages sont implémentées.

La révocation arrête l’accès ultérieur via le partage Dossira. Elle ne peut pas effacer les fichiers déjà téléchargés ou copiés hors du service.

3. Chiffrement du transport et de l’infrastructure

Les points de terminaison web et API de production revus utilisent HTTPS. La configuration de maillage de services revue utilise un mTLS strict entre les services du maillage, et la documentation d’infrastructure actuelle indique des disques chiffrés pour les serveurs d’application, de base de données, de stockage objet, de bascule et de sauvegarde.

Ces contrôles protègent les données en transit et sur les disques serveur sous-jacents. Ils sont distincts de l’E2EE optionnel côté client pour les charges utiles de fichiers et ne signifient pas que chaque objet stocké utilise une clé applicative contrôlée par le client.

4. Périmètre E2EE optionnel

L’application prend en charge l’E2EE optionnel d’espace de travail dans le chemin de fichier avec stockage préalable pour le téléversement, l’aperçu et le téléchargement des charges utiles de fichiers.

Limites importantes :

• l’E2EE est optionnel, pas le comportement par défaut de chaque espace de travail ;
• il protège les opérations prises en charge sur les charges utiles de fichiers, pas toutes les données de l’espace de travail ;
• les noms de fichiers et les métadonnées de dossiers restent hors du périmètre E2EE ;
• les flux de partage invité ne fournissent pas encore de prise en charge E2EE équivalente ;
• les opérations de fichiers adossées au miroir n’utilisent pas le même chemin E2EE.

Le site web ne prétend donc pas que Dossira est aveugle aux noms de fichiers, à toutes les métadonnées ou au contenu partagé avec des invités.

L’accès aux clés d’espace de travail chiffré et la récupération dépendent du flux configuré pour les membres et les clés d’espace de travail, et doivent être testés pour le déploiement. Dossira ne publie pas de garantie universelle de récupération par le fournisseur, d’aveuglement du fournisseur ou d’accès entre appareils.

5. Périmètre d’hébergement

Dossira est fourni par une société norvégienne. Les données clients et les identités des utilisateurs sont hébergées sur l’infrastructure Hetzner en Allemagne et en Finlande. Dossira n’utilise ni AWS, ni Microsoft Azure, ni Google Cloud pour cet hébergement.

Pour les rôles de responsable/sous-traitant, les fournisseurs de services et les informations de transfert, consultez la Politique de confidentialité et l’Accord de traitement des données.

6. Enregistrements d’activité et déclarations d’audit

Le système sous-jacent conserve des enregistrements opérationnels étroits :

• les ressources et versions téléversées conservent des champs créateur et horodatage ;
• les tickets de partage conservent des détails de création, mise à jour, expiration et révocation ;
• les défis par e-mail confirmé conservent l’état d’envoi, de tentative, de consommation et d’invalidation.

Le produit actuel n’expose pas de registre complet d’événements visible par le client ni d’export d’audit. En particulier, cet audit n’a pas vérifié d’événements durables visibles par le client pour chaque entrée de room, entrée échouée, aperçu de fichier, téléchargement de fichier, changement d’appartenance, action de scellement/clôture ou export.

Nous ne prétendons donc pas actuellement que :

• chaque accès est enregistré dans un registre visible par le client ;
• chaque action clé est disponible pour audit ;
• un enregistrement complet d’activité peut être exporté.

7. Cycle de vie de room et scellement

Un cycle de scellement de room ou de clôture et export n’est pas implémenté. Il n’existe actuellement aucune transition en lecture seule au niveau de la room, aucun verrouillage de version déclenché par scellement, aucun manifeste de clôture ou export, aucune action de réouverture, aucune règle de facturation ni aucun acteur/horodatage de scellement. L’accès invité externe en lecture seule est une capacité de partage, pas un scellement de room.

Les espaces de travail actuels ne doivent pas être décrits comme scellés, immuables, inviolables, permanents ou juridiquement concluants.

8. Signaler une vulnérabilité

Si vous pensez avoir trouvé une vulnérabilité, utilisez la page Contact et indiquez que le signalement concerne la sécurité. N’incluez pas de contenu client confidentiel dans un premier signalement.