Aller au contenu principal
Retour au catalogue des connecteurs

Connecteur

HashiCorp Vault

Identifiant d'API, saisi client par client.

Gestionnaire de secrets centralisé auto-hébergé (HashiCorp Vault OSS/Enterprise), utilisé par les MSP pour stocker et distribuer les identifiants, clés d'API et certificats d'un client plutôt que de les disperser dans des scripts ou fichiers de configuration. Vigicap lit l'état de scellement (sealed/unsealed) et la liste des moteurs de secrets montés pour évaluer l'objectif ReCyF « Gestion des identités et des accès ». Un Vault descellé avec des moteurs de secrets configurés est un signal de gestion centralisée, mais ne garantit ni le moindre privilège ni la rotation effective des secrets.

01

Ce qu'il faut créer dans l'outil

L'accès se crée dans HashiCorp Vault, pas dans Vigicap. Vigicap ne demande jamais le mot de passe d'un administrateur : il attend un identifiant d'API que vous créez, que vous voyez, et que vous pouvez révoquer sans nous.

Où le générer

Générez ou utilisez un token Vault disposant d'une policy autorisant la lecture de sys/health et sys/mounts (ex. capability "read" sur sys/mounts). En namespace Vault Enterprise, indiquez également le namespace (ex. "ns1").

Rôle minimal

Vault n'exprime pas le moindre privilège par un rôle mais par une policy. La policy minimale de ce connecteur tient en deux chemins en lecture : path "sys/health" { capabilities = ["read"] } et path "sys/mounts" { capabilities = ["read"] } — aucun accès aux moteurs de secrets eux-mêmes, et pas de capability sudo.

Formulation reprise du modèle de rôles de l'éditeur, et vérifiée avant publication.

02

Ce qu'il faut saisir dans Vigicap

Les champs exacts du formulaire de connexion, dans l'ordre où ils apparaissent. Les valeurs marquées « secret » ne ressortent jamais vers le navigateur : elles sont chiffrées au repos et supprimées à la déconnexion.

Le formulaire commence par l'adresse de l'instance, saisie à part des champs ci-dessous. Le catalogue public ne publie pas encore si ce connecteur en demande une, ni à quoi elle ressemble — cette liste est donc exacte pour tout le reste, et muette sur ce premier champ.

  • Token Vaultsecret

    Token Vault avec une policy autorisant la lecture de sys/health et sys/mounts.

    hvs.xxxxxxxxxxxxxxxxxxxx

  • Namespace (Vault Enterprise)facultatif

    Optionnel — uniquement pour Vault Enterprise avec des namespaces. Laissez vide en Vault OSS ou sur le namespace racine.

    ns1

03

Le routage par client

La connexion se fait client par client : un identifiant par client, saisi sur la fiche de ce client. Rien n'est partagé entre deux clients, et déconnecter l'un n'affecte pas l'autre.

04

Ce qu'il fait, et ce qu'il ne fait pas

Objectifs ReCyF pré-remplis

Une lecture alimente un objectif du référentiel ANSSI ReCyF. Elle le PROPOSE : le niveau n'est retenu qu'une fois validé par un consultant.

  • #10 Gestion des identités et des accès des utilisateurs aux systèmes d'information

Lecture seule

Les lectures sont en lecture seule : Vigicap n'écrit rien dans l'outil en lisant.

Ce qui est lu, ce qui est conservé, combien de temps et avec quels droits : le même registre, connecteur par connecteur, dans l'inventaire des données.

Vérification

Ce connecteur a été exécuté de bout en bout contre une instance réelle de l'outil, pas seulement testé contre une simulation.

Les marques et logos cités appartiennent à leurs titulaires respectifs et identifient les outils avec lesquels Vigicap est compatible — voir les mentions légales.