CapordiaEspace client Nommer les responsables avant de distribuer les accès
Distinguez le responsable du dossier de location, la personne qui autorise l’accès au projet et celle qui peut appliquer les changements techniques sur la cible. Le responsable des résultats n’a pas nécessairement besoin de lancer des processus ou d’administrer la machine. Écrivez les opérations requises avant de choisir les droits : lire un export, déposer des entrées, exécuter une tâche ou modifier un environnement.
Vérifiez ensuite le périmètre des accès effectivement remis. Si vous ne disposez pas du droit de créer des identités ou de régler les permissions, faites confirmer la procédure possible avant d’inviter d’autres intervenants. Ne contournez pas cette limite en distribuant le mot de passe du compte Capordia. Le partage du travail et la gestion du dossier commercial sont deux questions différentes.
Utiliser une identité individuelle et connaître sa portée
Une identité individuelle permet de retirer l’accès d’une personne sans remplacer celui de toute l’équipe. Dans une organisation SSH par clés, OpenSSH distingue la clé publique connue du serveur et la clé privée détenue par l’utilisateur. Le document de coordination peut contenir une référence ou une empreinte de clé publique ; il ne doit jamais contenir la clé privée ou sa phrase de protection.
Deux clés différentes donnant accès au même compte système ne créent pas automatiquement deux périmètres de fichiers différents. Les permissions dépendent du compte et des mécanismes configurés sur la machine. Décidez donc si l’exigence porte seulement sur l’authentification individuelle ou aussi sur la séparation des actions. Pour les automatisations, prévoyez une identité et un propriétaire explicites, sans réutiliser discrètement l’identité personnelle d’un collègue.
Vérifier la cible avant de lui présenter une identité
Lors du premier accès, contrôlez le nom de la machine, le compte attendu et l’empreinte de sa clé d’hôte à partir d’une référence de confiance obtenue dans le processus de remise des accès. Cette clé d’hôte identifie le serveur ; elle est distincte de votre clé d’utilisateur. Un message inattendu de changement d’identité du serveur mérite un examen, pas la suppression automatique de la référence connue.
OpenSSH conserve des clés d’hôte et signale leurs changements. Utilisez cette information avec le contexte : reconstruction annoncée de la machine, adresse modifiée ou événement non expliqué. Faites confirmer le changement avant de poursuivre s’il n’est pas attendu. Le but n’est pas d’ajouter un rituel à chaque connexion, mais d’éviter de traiter une alerte d’identité comme une simple gêne d’affichage.
Exemple fictif : trois intervenants, trois besoins
L’équipe fictive « Dossier des ouvrages » prépare une semaine de travail. Idriss exécute les traitements du projet A, Noémie relit les exports et Sacha intervient temporairement pour configurer l’environnement. L’équipe souhaite les droits du tableau, mais doit vérifier qu’ils sont applicables avec le système réellement remis. Il ne s’agit ni de comptes clients existants ni de fonctions de gestion d’équipe annoncées par Capordia.
Le principe décisif est que Noémie n’obtient pas un accès d’administration pour ouvrir un résultat et que l’intervention de Sacha possède une fin. Une approbation humaine seule ne configure aucun droit : le responsable technique applique les mécanismes disponibles, puis chacun exécute les contrôles prévus. Si la séparation souhaitée n’est pas réalisable, le projet doit adapter son organisation avant d’introduire des données qui exigent cette séparation.
| Intervenant | Besoin | Périmètre souhaité | Réexamen |
|---|---|---|---|
| Idriss, exploitation | Déposer des entrées et lancer le projet A | Espace de travail A, sans administration générale | Fin de campagne ou changement de rôle |
| Noémie, validation | Lire les exports remis | Résultats retenus, sans modification des entrées | Fin de validation |
| Sacha, intervention | Préparer l’environnement autorisé | Changement défini et approuvé | Dès la réception de l’intervention |
Préparer une fiche d’accès et tester les limites
La fiche relie une personne ou une automatisation, une identité technique, un approbateur, un périmètre, une justification et une échéance. Conservez la référence de la clé publique et la procédure de retrait sans stocker les secrets. OpenSSH ssh-keygen permet d’afficher l’empreinte d’une clé publique : cette référence aide à désigner la bonne clé lors d’un ajout ou d’une suppression, sans copier sa partie privée.
Testez une action autorisée sur un fichier synthétique puis une action volontairement hors périmètre, prévue comme refusée. Pour un rôle de lecture, l’ouverture doit fonctionner et une tentative de modification contrôlée doit être refusée. N’utilisez pas des données réelles pour tester une interdiction de suppression. Vérifiez aussi les chemins communs et la destination des sorties, car un droit correct sur un dossier ne garantit pas tous les chemins du programme.
Prévoir le retrait et vérifier une nouvelle connexion
Déclenchez le retrait à la fin de l’intervention, au départ d’une personne ou après une suspicion de compromission. Le responsable identifie toutes les autorisations concernées, y compris les autres chemins d’accès autorisés pour cette même identité. Il applique le retrait selon la configuration réelle. La directive RevokedKeys d’OpenSSH est un mécanisme possible parmi ceux documentés ; elle ne doit pas être supposée active sur une machine sans vérification.
Contrôlez ensuite qu’une nouvelle authentification avec l’identité retirée est refusée, sans supprimer l’accès de récupération du responsable. Examinez séparément les sessions déjà ouvertes, les tâches en cours et les identités d’automatisation : retirer une autorisation et arrêter une activité sont des décisions différentes. Si un travail doit continuer, transférez sa responsabilité selon une procédure convenue plutôt que de laisser une identité orpheline.
Éviter les raccourcis qui empêchent le contrôle
Une clé privée commune empêche de savoir qui doit la remplacer et impose souvent une rotation collective. Un accès large « en attendant » tend à durer si personne n’a fixé sa date de revue. Un compte de validation utilisé aussi pour administrer la machine rend les contrôles de séparation difficiles à interpréter. Corrigez ces problèmes dans la fiche d’accès avant qu’ils ne deviennent une dépendance de l’exploitation.
Évitez également d’ajouter des transmissions d’agent, des tunnels ou des exceptions d’accès uniquement pour contourner une difficulté non diagnostiquée. Faites décrire le besoin de connexion et ses contraintes par le responsable autorisé. Ce guide ne propose pas de configuration serveur universelle : les mécanismes dépendent des droits remis, de l’environnement et des exigences du projet. Une documentation générale ne vaut pas validation de la cible.
Remettre une organisation d’accès qui reste vérifiable
À la réception, rassemblez la matrice approuvée, les identités actives, les tests autorisés et refusés, les échéances et la personne capable de retirer un accès. Vérifiez qu’une personne absente peut être remplacée sans diffuser son secret. La continuité repose sur une procédure et un responsable de secours autorisé, pas sur un mot de passe partagé dans le dossier du projet.
Lors du passage de relais, revoyez les accès devenus inutiles et les automatisations qui dépendent d’une identité personnelle. Si un refus inattendu bloque le travail, constituez un dossier d’incident ciblé avec identité technique, chemin concerné et erreur expurgée. N’ajoutez pas de droits généraux seulement pour faire disparaître le symptôme. La bonne clôture est un accès nécessaire, testé et assorti d’une fin connue.
Questions pour décider
Faut-il partager le compte Capordia avec tous les intervenants ?
Non. Le suivi de la location et les accès techniques au travail doivent être organisés séparément. Définissez les identités de machine possibles avec les droits réellement remis. Cette méthode ne suppose aucun système d’invitations ou de rôles d’équipe dans l’espace Capordia.
Une clé publique donne-t-elle automatiquement les bons droits ?
Non. Elle sert à l’authentification lorsqu’elle est autorisée ; les actions accessibles dépendent ensuite du compte et des permissions du système. Vérifiez une action permise et une action qui doit être refusée sur des fichiers synthétiques.
Que vérifier après le départ d’un intervenant ?
Retirez ses autorisations, contrôlez le refus d’une nouvelle authentification et examinez les sessions, travaux et automatismes encore liés à son identité. Conservez un responsable autorisé pour la récupération et le suivi. Ne concluez pas au retrait à partir d’une simple case cochée.