 |
Bienvenue sur le gestionnaire d'accès |
|
|
Bienvenue sur le gestionnaire d'accès |
|
Ce document recense les évolutions d'AccessManager, de la plus récente à la plus ancienne.
Les numéros de version suivent le format majeur.mineure.commit :
L'état des courriels dans la liste des demandes. Une colonne Courriels montre deux pastilles : l'enveloppe pour l'invitation à compléter la demande, le QR code pour le badge envoyé à la validation. Leur couleur dit où en est le dernier envoi, d'après le journal des emails :
L'infobulle reprend l'état et sa date. Un courriel se renvoie toujours depuis le journal des emails. Les envois antérieurs à cette version n'étaient pas classés par type : leurs pastilles restent bleues.
Zones de circulation. Une zone dit désormais où un visiteur a le droit de se déplacer sur l'emprise. Chaque zone porte un nom et une couleur, et SUPERADMIN tient ce référentiel depuis le nouvel écran « Zones de circulation ».
Chaque unité ne demande que ce qui lui est ouvert. Sur la fiche du service, SUPERADMIN coche les zones que l'unité aura le droit de demander. Le chef de service en retient une seule à chaque demande, la même pour toutes les personnes invitées ensemble.
Le laissez-passer prend la couleur de la zone. Le QR code imprimé est teinté de la couleur de la zone accordée, et le nom de cette zone est inscrit en toutes lettres en son centre — un badge photocopié en noir et blanc reste donc exploitable. Les noms de plus de 20 caractères ne sont pas inscrits : le code resterait illisible ; seule la couleur est alors portée.
Le filtrage lit la zone au scan. Sous le verdict d'accès s'affiche un bandeau « Zone autorisée », avec le nom de la zone dans sa couleur : celle du QR code que l'agent vient de scanner. Les badges permanents ne sont pas concernés.
Une couleur trop claire est refusée à la saisie. Un jaune ou un beige rendrait le QR code indéchiffrable au lecteur : l'application le signale au moment où la couleur est choisie, plutôt qu'au poste de filtrage.
Rien à ressaisir. Chaque organisation reçoit une zone « Zone vie », noire — la couleur qu'avaient jusqu'ici tous les QR codes. Les unités et les demandes déjà enregistrées la portent, et une unité à laquelle aucune zone n'a été attribuée se la voit proposer : aucune demande n'est bloquée.
Numéros d'urgence sur le laissez-passer. La carte d'urgence de la base s'imprime désormais en tête de la moitié gauche du laissez-passer : les contacts à joindre en cas de situation inhabituelle, rangés en deux rubriques — sécurité et protection défense d'un côté, incendie et médical de l'autre. Les instructions de pliage passent en dessous.
Un écran pour les tenir à jour. L'administrateur du site saisit ses propres numéros — une ligne par contact — depuis l'entrée « Numéros d'urgence », et n'a personne à solliciter pour corriger un numéro. Un aperçu montre le cartouche tel qu'il s'imprimera.
Rien n'est imprimé tant que rien n'est saisi. Les numéros sont propres à chaque emprise : un numéro d'une autre base serait pire que pas de numéro du tout. Tant que les rubriques sont vides, le laissez-passer garde sa présentation antérieure.
Menu réorganisé. Les entrées sont désormais rangées par rubriques — « Accès », « Filtrage », « Sécurité du site », « Documentation » — et les écrans de paramétrage sont réunis dans un bloc Administration encadré, comme l'est déjà le bloc Compte : unités, utilisateurs, zones de circulation, numéros d'urgence, types de badge, PDF de service, journaux et statistiques. Ce qui règle l'emprise se distingue ainsi de ce qui la fait tourner.
secureentry.fr : un lien de réinitialisation de
mot de passe ne peut plus être détourné vers un autre domaine.Une page « Mon compte », pour chacun. L'entrée du menu réunit ce qui vous concerne : votre identité, vos coordonnées — adresse électronique et téléphone, que vous tenez vous-même —, votre mot de passe et la double authentification. Elle est ouverte à tous les profils, sans passer par un administrateur.
L'identifiant, le nom et les rôles y figurent en lecture seule : ils engagent l'organisation et restent tenus par l'administration.
Double authentification, au choix du titulaire. Votre compte peut désormais être protégé par un code à usage unique, produit par une application sur votre téléphone — Google Authenticator ou équivalente — demandé après le mot de passe à chaque connexion.
Elle est désactivée à la création du compte : c'est à vous de l'activer, en scannant un code depuis votre page de compte. Vous seul appairez votre téléphone. Rien n'est activé avant qu'un premier code n'ait été vérifié : un appairage manqué ne vous enferme donc pas dehors.
Un mot de passe seul ne suffit plus. Dérobé par hameçonnage, saisi sur un poste partagé ou réemployé sur un autre site qui se fait pirater, il ouvre votre compte et tout ce qu'il donne à voir. Ne pas activer la double authentification engage votre responsabilité en cas d'utilisation frauduleuse de votre compte.
Le courriel d'ouverture de compte le rappelle, votre page de compte le répète tant que la protection est absente, et le menu porte une pastille.
Téléphone perdu : l'administrateur peut réinitialiser. Sans votre téléphone, vous ne pouvez plus produire de code. Un administrateur réinitialise alors la protection de votre compte, depuis sa fiche : vous vous connectez avec votre seul mot de passe, le temps d'appairer un nouveau téléphone. L'opération est consignée au journal.
La liste des visiteurs s'importe depuis un tableur. Pour un groupe nombreux, plus besoin de saisir chaque personne à la main : renseignez le cartouche du haut — dates, motif, plage horaire —, puis déposez un fichier.
Un bouton Modèle vierge fournit le fichier à remplir : une personne par ligne, trois colonnes NOM, PRÉNOM, EMAIL. Les personnes apparaissent alors dans le tableau, où elles restent modifiables : rien n'est enregistré avant que vous n'ayez validé la demande.
Les formats .xlsx, .ods et .csv sont acceptés, jusqu'à deux cents
personnes par import. L'ancien format .xls d'avant 2007 n'est pas lu :
ouvrez le fichier dans votre tableur et enregistrez-le en .xlsx.
Une ligne incomplète, ou dont l'adresse électronique est mal formée, est écartée et signalée — les autres sont importées quand même. Un nom trop long pour le badge est raccourci, et l'application vous le dit.
Les laissez-passer visiteurs sont bornés à une plage horaire. Un accès temporaire ne valait jusqu'ici que par ses dates d'arrivée et de départ, à toute heure du jour et de la nuit. Il ne vaut désormais qu'en jour ouvré, de 6h00 à 19h00 du lundi au vendredi.
Une case, sur la demande comme sur la fiche, ouvre l'accès à toute la semaine et à toute heure. Ces deux réglages sont les seuls offerts : la plage n'est pas paramétrable, pour qu'un réglage précipité ne puisse pas ouvrir une plage inattendue.
Le scan refuse hors plage, comme il le fait déjà pour les badges permanents : même couleur, même bandeau, et la plage autorisée s'affiche. Le bouton d'entrée disparaît.
La plage figure sur le badge imprimé, en français et en anglais : le porteur la lit sur son propre laissez-passer, sans avoir à la demander au filtrage.
La plage du jour ouvré est la valeur par défaut et s'applique aux accès déjà enregistrés. Un laissez-passer en cours qui servait le week-end ou en soirée doit être rouvert depuis sa fiche, en cochant la case.
Le journal des actions couvre désormais tout ce dont il faut pouvoir rendre compte. Il consignait les décisions d'accès et les connexions ; il y ajoute :
L'adresse d'origine de chaque action est conservée. Une nouvelle colonne la donne à lire, triable et filtrable comme les autres : deux connexions du même compte depuis deux adresses très différentes se voient, là où le seul nom ne dit rien.
Échecs de connexion et comptes verrouillés ne remontent qu'au super administrateur. L'identifiant saisi peut ne correspondre à aucun compte, et le rattacher à une organisation reviendrait à confirmer qu'un compte y existe.
Aucun mot de passe ne figure au journal, sous aucune forme. Celui qui est saisi lors d'une tentative de connexion n'est jamais enregistré, même en cas d'échec : seul l'identifiant l'est. Celui du serveur d'envoi d'une organisation est noté comme modifié, jamais avec sa valeur.
app:purge-historique. Elle applique la durée de conservation du journal —
un an par défaut. Son absence ne bloque rien, elle laisse seulement les traces
s'accumuler au-delà.app:alerte-bga devient
app:alerte-securite. Elle doit être modifiée chez l'hébergeur en même temps
que la mise en ligne, sans quoi l'alerte cesse d'être envoyée sans message
d'erreur.Le menu se parcourt en entier sur les écrans bas. Lorsque le menu était plus haut que la fenêtre — un compte cumulant plusieurs rôles sur un écran peu haut, ou une fenêtre réduite — les dernières entrées, dont la déconnexion, étaient purement coupées : rien ne permettait de les atteindre. Le menu défile désormais, avec une barre qui n'apparaît que si elle est nécessaire.
Les messages d'erreur du formulaire de visite s'affichent en toutes lettres. Le motif de la visite laissé vide, ou trop long, affichait un libellé interne au lieu de la phrase explicative. Le formulaire public rempli par le visiteur était concerné.
Surveillance du journal d'accès du serveur. Une analyse automatique examine chaque heure les connexions reçues par l'application et signale par courriel ce qui sort de l'usage : tentatives de connexion en rafale, essais de liens d'accès en série, parcours de fiches en grand nombre, recherche de fichiers sensibles.
Le journal interne d'AccessManager retient les connexions et les modifications ; il ne voit pas les simples consultations. Cette surveillance complète le dispositif sur ce point.
L'alerte ne transmet que des nombres et renvoie au journal du serveur pour le détail : aucune donnée nominative ne circule par courriel, et rien n'est conservé en base. En l'absence d'anomalie, aucun message n'est envoyé.
Un document dédié — Surveillance du journal d'accès — décrit le dispositif, ses réglages et ses limites.
Première version dont les évolutions sont consignées ici. Les modifications antérieures ne figurent pas dans ce journal.