Gérer les collaborateurs et les rôles en toute sécurité

Utilisateur, rôle et autorisation séparés

Un utilisateur appartient à une seule personne avec son nom et son email. Un rôle décrit un travail tel que la réception ou le ménage. Les autorisations décident s'il peut lire, écrire ou gérer.

L'Hôtel Nordlicht commence par des profils de gestion, de réception, d'entretien ménager et de finance. Une personne peut assumer plusieurs tâches mais utilise toujours un seul compte personnel et le plus petit rôle adéquat.

Garde trois concepts séparés. Un utilisateur est une personne identifiable possédant des informations d'identification personnelles, une langue et un état actif. Un rôle regroupe une étendue de travail approuvée. Une autorisation permet une action concrète telle que lire les réservations, modifier les paramètres financiers ou gérer les utilisateurs. Ne crée jamais un utilisateur « d’accueil » partagé, car les actions, erreurs et audits ultérieurs n’appartiendraient plus à une seule personne. Cartographie chaque employé du bon hôtel et évite de détenir les autorisations d'une autre responsabilité simplement pour des raisons de commodité. Les rôles système fournissent une base de référence maintenue ; les rôles personnalisés ne sont justifiés que par un besoin opérationnel stable. Documente le propriétaire du rôle et la date d’approbation. Avant la configuration, écris l’ensemble de tâches prévu et les exclusions sensibles. Le modèle est prêt lorsque la direction peut expliquer qui est la personne, pourquoi le rôle existe et quelles actions exactes elle accorde ou refuse sans s'appuyer sur un titre de poste informel.

Planifier les tâches avant les autorisations

Énumére cinq à dix tâches fréquentes par lieu de travail. La réception travaille avec les réservations, les invités et les messages ; ménage avec le plan quotidien; financer avec des documents et des paiements ; gestion avec rapports et configuration.

Indique si chaque tâche nécessite un accès en lecture ou en écriture. La visualisation des chambres n'implique pas la gestion des disponibilités ; la consultation des factures n’implique pas la correction du paiement. N'active pas les modules « juste au cas où ».

Concevoir l'accès à partir des tâches et des risques. Énumére ce que la réception, l'entretien ménager, les finances, la gestion et la couverture temporaire doivent faire au cours d'un quart de travail normal, puis identifie le plus petit ensemble de données et d'actions requises. Sépare la lecture, la création, la modification, l'approbation, l'exportation et l'administration là où le produit le prend en charge. Porte une attention particulière aux données des clients, aux documents, aux paiements, aux tarifs, aux paramètres de l'hôtel et à la gestion des utilisateurs. Une personne qui a besoin d'un rapport n'a pas automatiquement besoin de droits de configuration ; une femme de ménage qui met à jour le travail de la chambre n'a pas besoin de financement pour les invités. Définis une escalade d’urgence au lieu d’accorder à chaque utilisateur un accès administrateur permanent. Note quelles actions nécessitent une deuxième approbation ou un examen ultérieur. Compare le plan avec de véritables arrangements de substitution et une assistance en dehors des heures d'ouverture. La planification des tâches réussit lorsque chaque autorisation prend en charge un flux de travail nommé, chaque exclusion sensible a une alternative opérationnelle et aucun privilège n'existe uniquement parce que « cela peut être utile un jour ».

Examine les rôles du système et ajoute délibérément des rôles personnalisés

Ouvre Paramètres → Utilisateurs et rôles. STRYK fournit le propriétaire, l'administrateur, la réception et l'entretien ménager comme profils de départ. Examine la description, l'état actif, les utilisateurs attribués et les autorisations du module.

Crée un rôle personnalisé uniquement pour une tâche distincte et durable, telle que Finance sans configuration d'hôtel. Utilise un nom et une description clairs, sélectionne les modules requis et vérifie l'état enregistré.

Passe en revue les rôles système existants avant d’en créer un personnalisé. Compare les autorisations réelles du rôle avec la matrice de tâches et teste les domaines de produits qu'elle expose. Choisis la ligne de base la moins privilégiée la plus proche, puis crée un rôle personnalisé uniquement lorsqu'une tâche récurrente ne peut pas être représentée en toute sécurité. Donne aux rôles personnalisés des noms clairs en fonction de la responsabilité, documente leur propriétaire et évite les noms spécifiques à une personne qui perdent leur sens après les changements de personnel. Ne copie jamais un rôle d'administrateur et supprime quelques éléments visibles sans tester les actions cachées. Rouvre le rôle enregistré et compare chaque autorisation. Conserve un rôle canonique pour le même travail au lieu de plusieurs versions presque identiques. Si une nouvelle fonctionnalité ajoute une autorisation, vérifie son effet avant une attribution large. La conception des rôles réussit lorsque le rôle sélectionné prend en charge toutes les tâches requises, bloque les actions sensibles sans rapport et reste compréhensible pour un responsable qui ne l'a pas créé.

Crée des utilisateurs personnels en toute sécurité

Dans la zone utilisateur, choisis Créer un utilisateur et entre le nom complet, l'adresse e-mail individuelle joignable et le rôle préparé. Partage le mot de passe initial en toute sécurité et vérifie l’orthographe de l’e-mail avant de l’enregistrer.

L'hôtel Nordlicht crée des utilisateurs distincts pour la gestion, les équipes de réception, l'entretien ménager et les finances. Les équipes peuvent partager un rôle mais jamais un compte.

Crée un compte pour l'employé nommé en utilisant une adresse e-mail professionnelle vérifiée et le bon hôtel. Définis la langue prévue, l'état actif et le rôle approuvé ; ne préconfigure pas de données personnelles fictives pour que les captures d'écran paraissent complètes. Assurer l'intégration via le flux de compte approuvé et exiger de l'employé qu'il garde ses informations d'identification confidentielles. N'envoie jamais de mot de passe d'administrateur partagé dans le chat et ne le stocke jamais dans une note à la réception. Confirme que la personne peut se connecter et atterrir dans le bon locataire et dans la bonne langue. Examine l’enregistrement utilisateur après l’enregistrement et vérifie qu’aucun rôle involontaire n’a été hérité. Pour un accès élevé, enregistre l’approbateur et la date de révision. Une identité de kiosque est un utilisateur technique dédié et spécifique au locataire et doit ouvrir l'expérience de kiosque, et non l'administrateur normal ; il ne remplace pas les comptes des employés. La création d'utilisateurs réussit lorsqu'une personne réelle contrôle un compte attribuable et qu'aucun identifiant ou rôle ne doit être partagé pour effectuer un changement.

Teste chaque rôle avec des cas positifs et négatifs

Connecte-toi avec un utilisateur de test de rôle et vérifie les cas positifs : la réception atteint les réservations et les invités, gère le plan quotidien, finance le bon document. Utilise des données de test marquées.

Vérifie ensuite les restrictions délibérées. Si une tâche est manquante, modifie le rôle central en utilisant la plus petite autorisation requise, reconnecte-toi et teste à nouveau les cas autorisés et bloqués.

Teste chaque rôle avec des cas positifs et négatifs lorsque tu es connecté en tant qu'utilisateur test. Les cas positifs prouvent le travail nécessaire : un réceptionniste ouvre et met à jour une réservation approuvée, une femme de ménage utilise le plan journalier partagé, un utilisateur financier accède au document prévu et la direction effectue sa configuration autorisée. Les cas négatifs sont tout aussi importants : les mêmes utilisateurs doivent échouer visiblement lorsqu'ils tentent des opérations financières, d'administration des utilisateurs, d'exportation de clients sensibles ou de configuration d'hôtel sans rapport. Teste la navigation directe ainsi que les entrées de menu cachées ; la sécurité ne peut pas reposer uniquement sur un chaînon manquant. Enregistre le rôle, l’action, le résultat attendu, le résultat réel et les preuves. Traite une erreur d'STRYK qui modifie toujours les données comme un échec critique et traite un succès simulé localement comme non valide. Reteste après les modifications de rôle et après les modifications importantes du produit. Un rôle est approuvé uniquement lorsque les actions requises réussissent, que les actions interdites échouent côté serveur et que le résultat survit à la déconnexion et à la nouvelle connexion.

Gérer proprement les remplacements, les changements de rôle et les départs

Pour la couverture, définis les dates et la tâche supplémentaire concrète. Distingue la lecture des documents de la gestion des paiements et enregistre le moment où l’accès doit revenir à la normale.

Pour un changement d'emploi permanent, mets à jour l'utilisateur personnel au lieu de créer un deuxième compte. Désactive les sortants avant leur dernier jour mais préserve l’historique. La désactivation de STRYK ne remplace pas la liste complète des départs de l’hôtel.

Gère la couverture, les changements de rôle et les départs en tant qu’événements d’accès datés. Pour une couverture temporaire, accorde le plus petit rôle supplémentaire pour la période définie, enregistre l'approbateur et la date de suppression, et évite le partage des informations d'identification. Lorsqu'un employé change de service, compare les anciennes et les nouvelles matrices de tâches et supprime les autorisations dont te n'as plus besoin avant d'en ajouter de nouvelles. Au départ, désactive rapidement l'utilisateur personnel, conserve l'historique d'audit et réattribue la propriété opérationnelle ouverte telle que les salles de ménage ou les approbations. Ne supprime pas le compte pour effacer l’historique et ne le laisse pas actif « au cas où ». Examine les sessions actives ou les accès associés lorsque le système les fournit et modifie toutes les informations d'identification externes partagées que la personne connaissait légitimement. Teste l'employé de remplacement de manière indépendante. L'événement est terminé lorsque l'ancien utilisateur ne peut pas accéder à l'hôtel, que l'historique nécessaire reste imputable, que l'œuvre ouverte a un nouveau propriétaire et que le successeur n'a approuvé que les autorisations actuelles.

Examine et approuve régulièrement l’accès

Effectue un court rapprochement mensuel de l’équipe et un examen trimestriel complet des rôles. Vérifie les utilisateurs actifs, les emplois, le personnel saisonnier, les couvertures, les doublons et les rôles inutilisés.

Enregistre la date, le réviseur, les modifications et la prochaine révision. L'hôtel Nordlicht confirme six comptes personnels, quatre rôles opérationnels et aucun identifiant partagé.

Exécute un examen périodique des accès à l’aide de la liste des utilisateurs actifs, des définitions de rôles et de la responsabilité opérationnelle récente. Pour chaque utilisateur, confirme l'identité, le statut d'emploi ou de contrat, l'hôtel, le rôle, les autorisations élevées, la dernière approbation et les besoins professionnels continus. Passe en revue les rôles personnalisés pour la duplication et les autorisations ajoutées par les nouvelles fonctionnalités. Exemples de preuves d'audit pour des actions sensibles en matière de finances, d'invités, de tarification et d'administration. Demander aux responsables d'approuver ou de supprimer explicitement l'accès ; le silence n'est pas une approbation. Suis les subventions temporaires après leur date de fin et les comptes inactifs qui restent activés. Enregistre la date de révision, le réviseur, les corrections et les preuves d'achèvement sans copier les données personnelles inutiles dans une deuxième feuille de calcul. Répète l’opération après des changements majeurs de personnel ou de produits et à un intervalle régulier défini. L'examen est terminé lorsque chaque compte actif a un propriétaire actuel et une raison, que chaque rôle a réussi ses tests, que les accès excédentaires sont supprimés et que la direction peut retracer la décision à partir du système central.

À la fin de l'examen, effectue une vérification distincte du locataire : tous les utilisateurs actifs ne doivent accéder qu'à l'hôtel pour lequel ils ont été approuvés, et les demandes directes effectuées avec l'ID d'un autre locataire doivent échouer côté serveur. Le certificat de test ne doit pas contenir de données d'invité ni de mot de passe ; l'utilisateur, le rôle, l'hôtel, l'action, l'interdiction attendue et le temps sont suffisants. De cette manière, le contrôle des autorisations ne se fait pas seulement au niveau du menu, mais vérifie également la séparation des données multi-hôtels.