Assurance et ingénierie de sécurité de Lira RDP Security
La sécurité fait partie intégrante de l’ingénierie de Lira : cloisonnement des espaces clients, communications de l’agent, authentification, gestion des erreurs et surveillance opérationnelle sont conçus puis vérifiés par des tests reproductibles.
Preuves examinées le 26 août 2026
L'assurance de sécurité en bref
Tests internes guidés par l’OWASPLes risques et les contrôles applicables sont évalués à l’aide des recommandations de l’OWASP.
545 réussis545 tests de sécurité et de régression du backend ont réussi ; un test distinct de connexion directe à PostgreSQL avec RLS a également réussi sur une base temporaire.
6/6Les artefacts Windows signés de l’agent 2.7.33 ont été vérifiés avec Authenticode.
Isolement des espaces clientsLes autorisations de l’API et les protections de la base de données font respecter les limites de chaque espace client.
Canal sortant initié par l’agentLe canal principal de l’agent établit des connexions HTTPS/WSS sortantes sécurisées et ne nécessite aucun port d’administration entrant. WinRM reste une voie distincte et facultative pour le diagnostic et la récupération.
Méthode d’assurance de la sécurité
Vyvick effectue des évaluations internes de la sécurité des applications à l'aide du Top 10 de l'OWASP comme base de référence du risque et de la norme de vérification de la sécurité des applications de l'OWASP applicable comme référence structurée. L'applicabilité est évaluée séparément pour le portail, l'API, l'agent Windows, le Credential Provider et l'infrastructure de production.
Ces activités sont des auto-évaluations internes. Elles ne constituent ni une certification, ni une approbation, ni une accréditation, ni une vérification indépendante par l’OWASP. Vyvick ne revendique actuellement ni version ou niveau de vérification ASVS, ni test d’intrusion indépendant, ni rapport SOC 2, ni certification ISO 27001.
Le tableau indique l'état des preuves. "Testé en interne" signifie que Vyvick a effectué des tests répétables pour la portée indiquée ; ce n'est pas une certification indépendante et ne signifie pas que tous les risques possibles sont éliminés.
Domaine
État
Preuves de vérification
Authentification
Tests internes réussis
Tests de régression sur les mots de passe, la MFA, la protection contre le rejeu, la limitation des tentatives et la récupération de compte.
Gestion des sessions
Tests internes réussis
Cookies sécurisés, contrôles CSRF, version de session, révocation et comportement d'expiration.
Contrôle d'accès
Tests internes réussis
Tests des espaces clients, des rôles, des groupes, de la portée des serveurs, de la propriété des objets et des refus d’accès interclients.
Sécurité de l'API
Tests internes réussis
Contrôles d’autorisation, identité de l’agent, validation des entrées, limitation du débit et gestion des erreurs.
Contrôles cryptographiques
Implémentation vérifiée
Transport TLS, hachage des mots de passe et jetons à usage unique vérifiés ; les mots de passe destinés à la gestion des comptes locaux sont chiffrés pendant leur mise en attente, puis effacés après réussite, échec ou expiration.
Journalisation et surveillance
Tests internes réussis
Journaux d’audit, état de la collecte des événements, alertes opérationnelles et traitement des événements de sécurité.
Sécurité des agents
Version de l’agent vérifiée
Communications sortantes, enrôlement limité au bon espace client, artefacts signés et vérification des mises à jour.
Sécurité des dépendances
Audit automatisé des dépendances
Les contrôles npm du frontend et pip-audit du backend ont été examinés le 26 août 2026 ; aucune vulnérabilité connue n’a été signalée.
Modèle de sécurité de l’agent Lira
L'agent est un service Windows privilégié car il doit lire les événements de sécurité et appliquer des actions administratives explicitement autorisées.
L’agent établit des connexions HTTPS/WSS sortantes ; les réseaux clients n’ont pas besoin d’un port de gestion entrant.
L’enrôlement et les communications habituelles utilisent une identité propre à chaque agent et vérifient son appartenance à l’espace client.
Les commandes distantes utilisent des enveloppes HMAC propres à chaque agent, liées à son identité, au contenu et à l’expiration. L’agent applique une liste locale de commandes autorisées et un registre persistant anti-rejeu ; le control plane privilégié doit néanmoins rester protégé.
Les mises à jour exigent un manifeste signé RSA-PSS, un hash et une taille exacts, un téléchargement HTTPS de même origine et la signature Authenticode de l’éditeur Lira épinglé. La racine privée est distribuée séparément par GPO, WinRM authentifié ou console.
Le portail Vyvick n’envoie ni ne stocke les mots de passe Windows/RDP. La validation des identifiants reste sur l’hôte Windows.
En mode strict fail-closed, le filtre Lira Credential Provider contrôle les autres fournisseurs Windows ; Windows LSA reste responsable de la validation primaire du mot de passe.
Si le service cloud est indisponible, la télémétrie et les commandes distantes sont suspendues ; le comportement de la MFA suit la politique de continuité configurée.
Authentification et contrôle d'accès
L'identité et l'autorisation sont appliquées aux limites des sessions et des objets.
La MFA du portail, la limitation des tentatives de mot de passe, les défis à usage unique et la révocation des sessions sont testés.
Le RBAC est associé à des contrôles de portée sur l’espace client, les groupes, les serveurs et la propriété des objets.
L’enrôlement des agents et les contrôles d’identité des serveurs empêchent leur réaffectation silencieuse à un autre espace client.
Les actions administratives sensibles créent des entrées dans le journal d’audit.
Chiffrement et secrets
Des contrôles cryptographiques sont appliqués aux chemins de données spécifiques qui les nécessitent.
Les communications du portail public et de l’agent utilisent HTTPS/TLS.
Les mots de passe sont stockés sous forme de hachage à sens unique ; aucun mot de passe du portail n’est conservé en clair.
Les secrets de la plateforme peuvent être fournis par OpenBao ; en production, la configuration échoue de manière sûre si le matériel cryptographique requis est absent.
En production, les seeds TOTP RDP sont stockés dans des chemins OpenBao séparés par organisation ; le fallback utilise un chiffrement lié à l’organisation et les codes de récupération ne sont conservés que sous forme de digests avec clé.
TOTP réduit le risque lié au vol d’un mot de passe, mais ne résiste pas au phishing. FIDO2 ou PIV doivent être privilégiés lorsque l’architecture d’identité le permet.
Les mots de passe destinés à la gestion des comptes locaux sont chiffrés pendant leur mise en attente, puis effacés après réussite, échec ou expiration.
Isolation des espaces clients
Lira combine l'autorisation d'application avec la défense de base de données en profondeur pour le fonctionnement MSP et multi-clients.
Chaque requête détermine la portée de l’espace client avant de lire ou de modifier ses ressources.
Les contrôles du rôle et de l'accès au serveur sont appliqués aux opérations de l'API au niveau objet.
Les protections au niveau des lignes PostgreSQL complètent les autorisations applicatives ; le RLS n’est pas l’unique limite entre espaces clients.
Modifier un identifiant d'organisation, de serveur ou d'objet ne permet pas à lui seul d'accéder aux ressources d'un autre client.
Les accès interclients, les portées vides, les groupes hérités et les droits directs sur un serveur sont couverts par des tests de régression.
Développement et opérations sécurisés
La validation de la sécurité fait partie intégrante du cycle de développement et de publication.
Les tests de régression du backend couvrent l’authentification, l’autorisation, l’isolement des espaces clients, la CSRF, les secrets, l’identité des agents et les procédures de correction.
Les builds de production du frontend et les parcours authentifiés dans le navigateur sont vérifiés avant l’acceptation d’une version.
Les contrôles npm du frontend et pip-audit du backend ont été examinés le 26 août 2026 ; aucune vulnérabilité connue n’a été signalée.
Les conclusions de sécurité sont corrigées et protégées par des tests de régression, le cas échéant.
Surveillance, vérification et réponse
Les preuves opérationnelles appuient les enquêtes, la responsabilisation et le rétablissement contrôlé.
Les résultats d’authentification, l’état des agents, les blocages d’adresses IP et les événements de sécurité sont regroupés dans le portail.
Les changements administratifs et les actions distantes créent des entrées d’audit indiquant l’auteur, la cible, le résultat et l’horodatage.
Les commandes ratées ou retardées demeurent visibles pour le diagnostic au lieu d'être traitées comme terminées.
Les problèmes de sécurité peuvent être signalés par le canal d’assistance documenté et analysés à l’aide des données opérationnelles conservées.
Base technique vérifiée — 26 août 2026
Ces résultats techniques datés sont présentés séparément de l’auto-évaluation guidée par l’OWASP.
Il s’agit de 545 tests de sécurité et de régression du produit Vyvick. Ils ne constituent ni des contrôles OWASP ASVS, ni une évaluation OWASP, ni une certification, ni un test d’intrusion indépendant.
Preuves examinées le 26 août 2026
LIRA RDP✓RÉUSSIVÉRIFICATION INTERNE
545 réussisTests de sécurité et de régression du backendL’intégration facultative était exclue de cette suite ; un test séparé de connexion directe PostgreSQL RLS dans un environnement temporaire a réussi
6/6Artefacts de version avec signatures Authenticode vérifiéesAgent 2.7.33 : programme d’installation MSI, script d’installation, EXE/DLL de l’agent, EXE de mise à jour et DLL du Credential Provider
453Paquets de dépendances frontend vérifiésVulnérabilités connues détectées : 0
Vérification interne appuyée par le dépôt ; il ne s’agit ni d’un test d’intrusion indépendant ni d’une certification.
MESURÉ LORS DU PREMIER PILOTE
Résultats du premier pilote Lira
Mesures anonymisées du premier pilote de Lira. Elles témoignent d’une charge d’exploitation réelle sans exposer les clients, les hôtes, les comptes ni les adresses sources.
Non. L’OWASP ne certifie ni n’approuve Vyvick. Ses recommandations servent de référence à un processus interne d’auto-évaluation de la sécurité des applications.
Lira a-t-elle effectué un test de pénétration indépendant ?
Aucune revendication indépendante de test de pénétration n'est actuellement publiée. Une fois l'assurance de tiers terminée, sa portée et sa date seront précisées explicitement.
L'agent Lira a-t-il besoin de privilèges administratifs ?
Oui. Le service Windows a besoin de privilèges pour lire les journaux d’événements protégés et exécuter les actions de sécurité et de maintenance configurées. Les commandes restent ciblées et vérifiées.
Lira stocke-t-elle les mots de passe Windows ou RDP ?
Non. Le portail ne transmet ni ne stocke les mots de passe Windows/RDP. Le Credential Provider et Windows les traitent uniquement sur l’hôte protégé.
Un client peut-il accéder aux serveurs d'un autre client ?
L’identifiant de l’espace client, les autorisations au niveau des objets, le RBAC, la validation de propriété et les protections au niveau des lignes de la base de données imposent le cloisonnement entre clients.
Que se passe-t-il si Lira est temporairement indisponible ?
La télémétrie et les commandes distantes reprennent au retour de la connexion. Le comportement de la MFA RDP suit la politique de continuité configurée pour l’espace client.
Rapport complet d’ingénierie de sécurité
Consultez les contrôles mis en œuvre, les frontières de confiance, les empreintes de version, les preuves de test, l’état du déploiement progressif, les limites d’assurance et les travaux restants consignés le 3 septembre 2026.
Si vous pensez avoir découvert une vulnérabilité concernant Vyvick ou Lira, utilisez le canal d’assistance sécurisé et évitez toute divulgation avant que nous ayons pu l’analyser et la corriger.