Distinguer permissions opérateur et accès physique
Un rôle opérateur Lexoh regroupe les permissions servant à déterminer les actions permises à un compte dans l’application. Ses réglages peuvent aussi restreindre les dossiers ou appareils concernés. Examinez l’action et sa portée; le nom du rôle ne définit pas à lui seul les droits obtenus.
Un compte opérateur, un profil client et un identifiant d’accès remplissent des fonctions différentes. Pouvoir consulter une porte ou lui envoyer une commande ne donne pas à lui seul un droit d’entrée au badge de l’opérateur. Une connexion réussie ne démontre pas non plus l’accès à toutes les fonctions.
Examinez les rôles réels de l’installation. Administrateur, Opérateur ou Technicien peuvent désigner une fonction, mais ce guide ne démontre ni leurs permissions initiales, ni leur protection contre la suppression, ni leur disponibilité. Confirmez les réglages actuels avant d’utiliser ou de copier un rôle.
Créer un rôle pour une fonction définie
- Listez les actions, dossiers et sites nécessaires avec l’administrateur responsable. Nommez le rôle selon sa fonction et sa portée, par exemple Surveillance du site A, et consignez qui approuve les changements.
- Ouvrez la gestion des rôles dans la navigation de configuration accessible à votre compte. Examinez un rôle existant avant de décider de le réutiliser, le copier ou en créer un avec la commande prise en charge.
- Sélectionnez les permissions disponibles nécessaires au travail. Examinez séparément consultation, création, modification, suppression, exportation et commandes lorsque le formulaire les distingue. Ne déduisez pas une permission d’une autre.
- Si des restrictions par étiquette ou entreprise existent, confirmez les types de dossiers visés et la combinaison des sélections. Vérifiez une sélection vide, les dossiers sans étiquette, les dossiers liés et ceux d’une autre organisation. Une association à une entreprise ne démontre pas à elle seule l’isolation entre locataires.
- Enregistrez et rouvrez le rôle, comparez les valeurs aux besoins approuvés et testez avec un compte désigné avant une attribution plus large. Préservez une voie de récupération administrative vérifiée séparément lors de changements pouvant retirer l’accès de gestion.
Examiner chaque opération et sa portée
Les domaines suivants constituent une liste de vérification, pas un inventaire complet des identifiants de permissions Lexoh. Utilisez les commandes réelles de l’installation. Les modules disponibles, les restrictions de dossiers et les capacités de l’équipement peuvent limiter une opération malgré une permission pertinente.
Comptes et rôles
Distinguez la consultation des comptes, leur création ou désactivation, l’attribution de rôles et la modification des définitions. Vérifiez si un compte peut modifier ses propres privilèges ou ceux de comptes plus privilégiés.
Portes, barrières et identifiants
Séparez la consultation de l’état et de l’historique des commandes d’équipement et de la gestion des badges, horaires et identifiants. Une permission de commande ne démontre ni sa compatibilité ni son exécution par l’équipement.
Vidéo
Examinez séparément le direct, la relecture, l’exportation, la configuration et les commandes panoramique/inclinaison/zoom lorsqu’ils sont disponibles. L’accès à une caméra ne démontre pas l’accès à toutes les caméras ou archives.
Stationnement et transactions
Séparez consultation de l’occupation, changements tarifaires, consultation des transactions, opérations de paiement et exportation de rapports. Vérifiez les actions et portées exactes; un libellé Paiements ne démontre pas des droits de remboursement ou de règlement.
Alertes et événements
Distinguez la lecture d’un événement, l’accusé de réception d’une alerte et la modification des règles de détection ou d’avis. Une alerte acquittée ne démontre pas la résolution de sa cause.
Véhicules et dossiers clients
Vérifiez séparément consultation, création, modification, suppression et exportation. Examinez dossiers liés, pièces jointes et portée par entreprise plutôt que de vous fier seulement aux éléments visibles dans la liste.
Vérifier les sessions existantes et les nouvelles connexions
Avant de modifier un rôle, identifiez les comptes et correspondances d’annuaire ou de connexion qui l’utilisent. Consignez les anciens réglages et les changements attendus. Un rôle partagé peut toucher plus que le compte utilisé pour le test.
Enregistrez, rouvrez le rôle et comparez les permissions et restrictions sauvegardées. Vérifiez une session existante et une nouvelle connexion avec le compte de test désigné. Ne promettez ni application immédiate ni reconnexion systématique; déterminez le comportement réel des sessions et de l’actualisation des droits.
Si des droits doivent être retirés, suivez la procédure de révocation de comptes et de sessions prise en charge, puis vérifiez le refus attendu. Actualiser une page ou vider le cache ne prouve pas que les autres sessions ont perdu l’accès. Un changement de rôle ne récupère pas les fichiers exportés et n’annule pas les commandes antérieures.
Attribuer le rôle prévu au bon compte
- Ouvrez le compte opérateur et vérifiez sa référence stable, son identité de connexion et la portée voulue. Ne le confondez pas avec un client ou une carte d’accès portant le même nom.
- Vérifiez le fonctionnement de l’attribution dans le formulaire et sa gestion éventuelle par un annuaire ou une connexion unique. Ne supposez ni une limite à un seul rôle ni la conservation d’une modification manuelle après synchronisation.
- Choisissez l’attribution approuvée et enregistrez. Rouvrez le compte pour confirmer la valeur et examinez les autres attributions ou restrictions contribuant aux droits effectifs.
- Avec le compte de test, vérifiez une action requise et une action exclue dans la portée concernée. Une réussite en tant qu’administrateur ne démontre pas le même droit pour l’opérateur. Coordonnez les tests physiques avec l’exploitation du site.
Utiliser une liste explicite de critères d’acceptation
Le rôle illustratif Surveillance du site A doit seulement consulter l’état et les événements du site A. Il ne doit ni commander l’équipement, ni voir le site B, ni administrer les comptes. Il s’agit d’exigences proposées pour un test, pas d’un rôle Lexoh préconfiguré ni d’une affirmation que chaque permission est réglable séparément.
| Test avec le compte affecté | Résultat requis dans cet exemple |
|---|---|
| Consulter un appareil désigné du site A et ses événements | Permettre la consultation prévue dans le site A. |
| Commander un équipement du site A | Refuser : le rôle illustratif sert uniquement à la surveillance. Suivre une procédure approuvée sans mouvement imprévu de l’équipement. |
| Ouvrir un dossier connu du site B par son lien de détail normal | Refuser ce dossier, même si des dossiers semblables du site A sont accessibles. Utiliser un dossier réservé au test. |
| Ouvrir un rapport ou export disponible contenant des données du site B | Exclure les données non autorisées du site B ou refuser l’opération selon la conception approuvée. Une liste filtrée ne suffit pas comme preuve. |
| Modifier un utilisateur ou une attribution de rôle | Refuser : la gestion des comptes et rôles dépasse la fonction illustrée. |
Consigner le résultat, pas seulement l’apparence du menu
Conservez pour chaque cas le compte testé, la version du rôle, la cible, le résultat attendu, le résultat réel et l’heure. Vérifiez le travail permis et refusé. Si les commandes disponibles ne permettent pas une séparation requise, revoyez la conception approuvée avec l’administrateur avant le déploiement.
Maintenir des permissions vérifiables
Accordez seulement les actions et la portée nécessaires au travail. Vérifiez l’autorisation au-delà des menus : masquer une commande ne prouve pas le refus d’accès. OWASP recommande le moindre privilège et une vérification d’autorisation à chaque requête; ces principes généraux ne certifient pas l’implémentation Lexoh.
OWASP recommande aussi le renouvellement des identifiants de session après un changement de privilèges. Confirmez le comportement de l’application installée avec l’administrateur et vérifiez le traitement des sessions existantes.
Conservez un responsable, un but, une portée approuvée et un compte rendu daté des tests. Revoyez les attributions après un changement de personnel, site, entreprise, étiquette ou fonction, ainsi qu’à une fréquence adaptée à l’organisation. Déterminez le nombre de rôles selon les responsabilités réelles, sans objectif universel de trois à huit.
Recommandations générales consultées le 30 septembre 2026 : Guide OWASP sur les autorisations. Guide OWASP sur la gestion des sessions.
Retirer un rôle après vérification des dépendances
- Identifiez les comptes affectés et les correspondances externes. Confirmez les exigences du remplacement avant toute réattribution; ne choisissez pas un rôle trop privilégié simplement pour retirer une dépendance.
- Testez le remplacement avec des comptes désignés et vérifiez les actions requises et les exclusions. Confirmez qu’un administrateur autorisé conserve l’accès de gestion.
- Examinez les commandes réelles de suppression et les restrictions concernant les rôles protégés ou encore attribués. Suivez la procédure prise en charge; les rôles nommés par défaut ne sont pas forcément protégés de la même façon partout.
- Après le retrait, vérifiez les attributions, correspondances et droits effectifs. Préservez la trace du changement et l’historique requis par l’organisation. Recréer le même nom ne rétablit pas nécessairement la référence ou les attributions initiales.
Trouver la cause d’un résultat inattendu
Une fonction nécessaire manque
Vérifiez le rôle enregistré, la permission d’action, le module et la portée des dossiers. Comparez aux besoins du travail avant de modifier les permissions. Ne rendez pas le compte administrateur pour contourner un refus inexpliqué.
Un changement semble sans effet
Confirmez les références enregistrées du rôle et du compte, puis comparez sessions existantes et nouvelles connexions. Vérifiez les commandes d’actualisation ou révocation prises en charge et les correspondances d’annuaire. Conservez le résultat et les traces disponibles pour l’administrateur.
Le compte voit trop de données
Consignez l’opération et la cible inattendues avec des données de test désignées. Examinez combinaisons d’étiquettes/entreprises, restrictions vides, dossiers liés, exports et autres attributions effectives. Signalez l’écart avant d’étendre l’usage du rôle.
Le rôle ne peut pas être supprimé
Examinez l’explication de l’application, les comptes dépendants, les correspondances et les règles de protection. Une réattribution exige ses propres vérifications de permissions; elle ne justifie pas un accès illimité.