Sécurité de la plateforme

Introduction

Gward donne accès à vos machines : la plateforme applique donc plusieurs couches de protection, du filtrage réseau jusqu’à la validation d’une action sensible.

Toutes ces règles sont appliquées côté serveur. Le navigateur n’est jamais considéré comme une source de confiance : masquer un bouton ne suffit pas à interdire une action, chaque appel est revérifié avant d’être exécuté.

Vue d’ensemble

Couche	Ce qu’elle protège
Filtrage des réseaux entrants	D’où l’on peut se connecter
Mot de passe + MFA	Qui se connecte
Session d’authentification	Combien de temps l’accès reste ouvert
MFA récent	Les actions sensibles et l’accès LiveControl
Portée LiveControl	Sur quelles machines la prise en main est permise
Session LiveControl	La durée d’une prise en main d’agent
Heures d’accès	Quand les opérations sur les agents sont permises
Anti-bruteforce	Les tentatives répétées sur un compte
Clés d’API et liens d’écran	Les accès sans session : étroits, révocables et tracés

Authentification et session

La connexion se fait par adresse e-mail et mot de passe. Si le MFA est activé pour votre compte, par défaut celui de votre organisation sauf exception définie pour vous (voir Activation), une vérification supplémentaire est demandée avant que la session ne devienne utilisable.

Une fois connecté, vous disposez d’une session d’authentification :

Règle	Valeur
Expiration sur inactivité	Configurable côté serveur
Prolongation	Automatique à chaque action dans l’application
Déconnexion	Ferme immédiatement la session côté serveur

Authentification multifacteur (MFA)

Activation

Le MFA se configure à deux niveaux, qui se combinent :

Organisation, dans Paramètres → Sécurité. Un super administrateur y définit le comportement par défaut : l’activer ou le désactiver pour toute l’organisation, et choisir le facteur utilisé.
Utilisateur, dans Paramètres → Utilisateurs, en modifiant un compte. Un super administrateur peut y définir une exception propre à cet utilisateur : l’activer pour lui alors que l’organisation ne l’impose pas, le désactiver pour lui malgré une organisation qui l’impose, ou lui attribuer un facteur différent de celui de l’organisation.

Sans réglage particulier sur son compte, un utilisateur suit simplement le réglage de son organisation : c’est le comportement par défaut, inchangé pour tous les comptes existants.

Facteur	Disponibilité
Code par e-mail	Disponible
TOTP (application d’authentification)	Disponible
WebAuthn	Prévu
FIDO2	Disponible

Le facteur par défaut est le code envoyé par e-mail, à l’adresse du compte concerné.

Quand le MFA est-il demandé ?

Le MFA n’est jamais demandé en boucle : une vérification réussie ouvre une fenêtre de MFA récent, dont la durée est configurable côté serveur, pendant laquelle les opérations protégées se déroulent sans nouvelle demande.

Situation	MFA demandé ?
Connexion à la plateforme	Oui
Consultation (alertes, checks, agents, rapports…)	Non
Action sensible	Seulement si la fenêtre de MFA récent est expirée
Ouverture d’une session LiveControl	Seulement si la fenêtre de MFA récent est expirée

Concrètement, un utilisateur qui se connecte puis ouvre LiveControl dans la foulée ne saisit qu’un seul code. Le même utilisateur qui revient plus tard, une fois la fenêtre de MFA récent écoulée, devra revalider un code avant d’accéder à LiveControl, mais sans être déconnecté : l’expiration du MFA récent retire uniquement le niveau d’authentification renforcée, votre session reste ouverte.

Actions sensibles

Toute opération qui modifie la configuration de la plateforme est classée comme sensible et exige un MFA récent lorsque le MFA est activé : gestion des utilisateurs et de leurs facteurs, configuration de l’organisation, gestion des accès et de LiveControl, mais aussi création, modification et suppression des agents, checks, labels, catégories et rapports. La consultation, elle, n’est jamais concernée.

Lorsqu’une de ces actions est demandée sans MFA récent, la plateforme affiche une fenêtre de vérification, puis rejoue l’action une fois le code validé : rien n’est perdu, il n’y a pas à recommencer la saisie.

Le code e-mail

Caractéristique	Valeur
Durée de validité	Configurable côté serveur
Usage	Unique : invalidé dès qu’il est accepté
Tentatives autorisées	Configurable côté serveur, puis le code est définitivement invalidé
Renvoi d’un nouveau code	Possible, avec un délai minimal entre deux envois

Un code est également lié à l’utilisateur, à sa session en cours et à l’intention pour laquelle il a été émis (connexion, action sensible, LiveControl). Un code obtenu dans un contexte ne peut donc pas être réutilisé dans un autre, ni validé depuis une autre session.

Lorsque le MFA est désactivé

Si le MFA n’est pas actif pour un utilisateur (ni par l’organisation, ni par une exception propre à son compte), aucun code n’est demandé : ni à la connexion, ni pour les actions sensibles, ni pour LiveControl. Toutes les autres protections (session, heures d’accès, filtrage réseau, anti-bruteforce, traçabilité) restent en place.

LiveControl : session privilégiée

L’accès à un agent via LiveControl constitue une élévation de privilèges. Il obéit à un parcours dédié :

votre session d’authentification doit être valide ;
votre rôle doit être Opérateur ou supérieur ;
la prise en main doit être autorisée sur l’agent visé (voir Portée de la prise en main) ;
une justification est obligatoire (elle est conservée avec l’utilisateur, la cible et la date) ;
un MFA récent est exigé : sinon un code est demandé.

L’autorisation est vérifiée avant la justification et le MFA : sur un agent bloqué, la demande est refusée d’emblée, sans vous faire saisir un motif ni consommer un code.

La session LiveControl ainsi ouverte est distincte de votre session d’authentification :

Règle	Valeur
Avertissement d’inactivité	Configurable côté serveur
Fermeture automatique	Configurable côté serveur
Durée réinitialisée	À chaque action sur l’agent

À sa fermeture (manuelle, par expiration, par déconnexion, ou parce qu’un super administrateur vient de retirer l’autorisation sur cet agent), les autorisations LiveControl sont retirées immédiatement et l’accès à la machine cible est coupé. Vous restez connecté à Gward et poursuivez votre navigation normalement.

Portée de la prise en main

Autoriser LiveControl est une décision par machine, pas seulement par organisation : un poste bureautique et un contrôleur de domaine n’appellent pas la même réponse. Les réglages se trouvent dans Paramètres → LiveControl et sont réservés au super administrateur, avec MFA récent exigé.

Réglage	Portée	Effet
Prise en main à distance activée	Organisation	Interrupteur maître : désactivé, aucun agent n’est pilotable, quel que soit son réglage individuel
Autorisation par agent	Un agent	Autorise ou bloque la prise en main sur cette machine précise
Autoriser les nouveaux agents par défaut	Organisation	Valeur appliquée à un agent au moment où il remonte pour la première fois

Les deux premiers réglages se combinent : la prise en main n’est possible que si l’interrupteur maître et l’autorisation de l’agent sont actifs.

Autoriser ou bloquer des agents

La section Paramètres → LiveControl liste les agents avec leur état. La sélection se filtre par catégorie et par labels dynamiques (avec les combinaisons OR, AND et NOT), ce qui permet de traiter un parc entier en une fois : par exemple bloquer d’un coup tous les agents portant le label role = domain-controller.

Un agent se bascule depuis sa ligne, ou plusieurs d’un coup via Activer / Désactiver la sélection.

Comportement à la remontée d’un nouvel agent

Quand un agent s’enrôle, il hérite de la valeur du réglage Autoriser les nouveaux agents par défaut :

Réglage	Un agent qui remonte est…
Activé (valeur initiale)	immédiatement pilotable
Désactivé	bloqué tant qu’un super administrateur ne l’a pas explicitement autorisé

Heures d’accès à la plateforme

Deux réglages d’organisation encadrent les périodes d’utilisation, dans Paramètres → Configuration :

Réglage	Effet
Heures d’activité (début / fin)	En dehors de la plage, les opérations sur les agents (LiveControl, commandes, transferts de fichiers) sont refusées
Mode vacances	Bloque la connexion à la plateforme, à l’exception des super administrateurs

La plage horaire peut traverser minuit (par exemple 22:00 → 05:00). La surveillance, la collecte des checks et les alertes continuent de fonctionner en permanence : ces réglages encadrent les actions humaines, pas le monitoring.

Filtrage des réseaux entrants

Une organisation peut restreindre les adresses depuis lesquelles la plateforme est accessible, dans Paramètres → Sécurité.

Les réseaux autorisés se déclarent en notation CIDR (par exemple 192.168.10.0/24 ou 203.0.113.42/32).
Aucun réseau déclaré : la plateforme est accessible depuis n’importe quelle adresse.
Au moins un réseau déclaré : toute connexion provenant d’une autre adresse est refusée, avant même la vérification du mot de passe. L’utilisateur est redirigé vers une page d’accès refusé.

Protection contre le bruteforce

La plateforme intègre un mécanisme de verrouillage de compte, sans configuration préalable.

Règle	Comportement
Échecs consécutifs sur un compte	Le compteur augmente à chaque mot de passe erroné
Après plusieurs échecs	Le compte est banni : toute connexion est refusée, même avec le bon mot de passe
Connexion réussie	Le compteur est remis à zéro
Déblocage	Par un super administrateur, dans Paramètres → Utilisateurs

Le message d’erreur affiché à la connexion reste volontairement générique : il ne précise jamais si l’adresse existe ou si seul le mot de passe est faux, afin de ne pas révéler l’existence d’un compte.

Le même principe s’applique au MFA : le nombre de tentatives sur un code est limité, et les demandes de renvoi sont espacées d’un délai minimal.

Accès sans session : clés d’API et écrans muraux

Deux accès ne passent pas par la connexion d’un utilisateur : les clés d’API des partenaires et les liens d’écran mural. Ils sont volontairement étroits.

	Clé d’API partenaire	Lien d’écran mural
Usage	Un serveur partenaire interroge l’API	Une TV affiche un dashboard
Portée	Lecture seule des données ouvertes aux partenaires	Lecture seule d’un seul dashboard
Durée de validité	90 jours au plus, renouvellement par une nouvelle clé	Jusqu’à révocation
Création	Administrateur, avec MFA récent	Administrateur, avec MFA récent

Dans les deux cas :

le secret n’est affiché qu’une fois, à la création : Gward n’en conserve qu’une empreinte ;
il n’ouvre ni l’interface, ni la configuration, ni LiveControl ;
le nombre de requêtes est limité pour chaque clé ;
la liste indique le dernier usage et l’adresse d’origine, et la révocation coupe l’accès sans délai côté serveur.

Le détail se trouve dans Ouvrir l’API à un partenaire et Afficher un dashboard sur un écran mural.

Supervision et traçabilité

Suivi des sessions

Un super administrateur dispose d’une vue temps réel dans Paramètres → Sessions :

Sessions d’authentification : qui est connecté, depuis quelle adresse, dernière activité, temps restant avant expiration et présence d’un MFA récent ;
Sessions LiveControl : quel agent est pris en main, par qui, avec quelle justification, depuis quand et pour combien de temps encore.

Un filtre permet de basculer entre les sessions en cours et l’historique récent, avec le motif de fermeture (déconnexion, inactivité, fin manuelle).

Journal de sécurité

Les événements sensibles sont journalisés : connexions réussies et échouées, demandes et validations MFA, actions sensibles autorisées ou refusées, ouverture, avertissement, expiration et fermeture des sessions LiveControl. Chaque entrée est horodatée et nominative.

Les refus le sont au même titre que les accès accordés : une demande de prise en main sur un agent bloqué laisse une trace, avec son auteur et la machine visée. Chaque activation ou blocage d’un agent est également journalisé, agent par agent, de même que la création, le renouvellement et la révocation des clés d’API et des liens d’écran.