Architecture de sécurité
Autorisée, chiffrée, visible et arrêtable localement.
E-mail vérifié, MFA facultative pour les utilisateurs standard, MFA obligatoire pour les admins, clés d’appareil, participants précis, tickets, baux courts et permissions explicites limitent chaque session.
De la preuve du compte au transport authentifié
- 01
Vérifier le compte et renforcer l’accès admin
Les utilisateurs standard emploient un lien magique d’e-mail vérifié et peuvent ajouter passkey ou TOTP. Chaque admin doit fournir une passkey récente ou un TOTP actif; la récupération seule n’autorise ni accès ni action admin.
- 02
Inscrire une clé d’appareil
L’appareil génère une clé P-256 non exportable et transmet seulement identité publique et métadonnées limitées.
- 03
Autoriser les participants
La demande nomme visionneuse et hôte; l’hôte accepte et accorde localement.
- 04
Lier et renouveler brièvement
Un ticket unique lie les empreintes et les baux exigent une autorité continue.
Plan de contrôle
Identité et autorisation
Comptes, sessions d’e-mail vérifié, enregistrements facultatifs de passkey et TOTP, renforcement admin obligatoire, clés publiques, droits, demandes, tickets, baux, signalisation limitée et audit sans contenu.
Plan de données terminal
Contenu et clés privées
Clés privées, écran, entrées, presse-papiers, fichiers et matériel de session restent chiffrés entre terminaux.
Limites de sécurité
- Aucune installation, capture ou entrée furtive.
- Aucun keylogging, shell, VPN général, proxy arbitraire ou transfert libre.
- Aucun contournement des permissions.
- Aucune fonction d’administration pour voir ou déchiffrer les sessions.
- Aucun stockage du contenu par le service ou TURN.
- Aucune connexion automatique liée au même compte.
Signaler directement un problème de sécurité
Indiquez origine, versions, reproduction minimale et heure. Retirez jetons, clés et contenu.
security@reallexi.io