Droits et autorisations

Devant les connecteurs se trouve un contrôle des droits. Il décide si la personne à l’origine de la demande a le droit d’utiliser un connecteur, et il consigne la décision. Cette page explique pourquoi cette couche est nécessaire, sur quoi elle se prononce et où vous gérez les autorisations.

Pourquoi cette couche est nécessaire

Si l’on raccorde des connecteurs sans couche de droits propre, on ne peut le plus souvent définir que si quelqu’un a le droit d’utiliser des connecteurs, pas lesquels. Qui a le droit d’utiliser MCP voit alors tous les systèmes raccordés, ou aucun.

Pour un outil comme une consultation météo, cela n’a pas d’importance. Pour un ERP, si : « la comptabilité peut voir les factures, mais pas les salaires » ne se laisse pas exprimer à ce niveau. C’est exactement cette lacune que comble le contrôle des droits.

Ce que fait le contrôle des droits

Une vérification avant l’appel. Un appel d’outil n’atteint le connecteur que si la personne à l’origine de la demande y est autorisée. Sinon, elle reçoit dans le chat un message en clair qui la renvoie à l’administrateur. Le chat se poursuit normalement, il n’y a pas de plantage.
Une liste d’outils propre à chaque personne. Qui n’a pas d’autorisation pour un connecteur ne se voit même pas proposer ses outils.
Un journal de chaque appel. Chaque décision est consignée de façon inaltérable, refus compris. La durée de conservation de ces entrées, vous la fixez dans votre concept de suppression, voir Protection des données et conservation.
En cas de doute, refuser. Si une décision reste incertaine, l’accès est refusé plutôt qu’autorisé.
Le connecteur n’apprend pas qui demande. L’identité sert à la décision et n’est pas transmise au connecteur.

Le parcours d’une requête

Les niveaux d’une autorisation

Les autorisations peuvent être posées pour des personnes précises, pour des rôles et pour des groupes, et il s’y ajoute une règle par défaut par connecteur. Lorsque des indications se contredisent, la résolution est délibérément restrictive. C’est voulu : une limite de sécurité ne doit pas pouvoir être levée par le simple fait que quelqu’un appartient en plus à un groupe anodin.

À côté du niveau du connecteur, une autorisation peut aussi porter sur des outils précis.

Où vous gérez les autorisations

Les règles par défaut, les autorisations pour les rôles et les groupes ainsi que les exceptions pour des personnes précises se gèrent dans le panneau d’administration. C’est également là que se trouve le journal des appels d’outils, qui peut être exporté pour vos archives. Inversement, on peut aussi partir d’une personne donnée et retracer quels connecteurs lui sont ouverts.

Quelle vue se trouve où et comment elle s’utilise, cela est décrit dans le guide fourni avec votre livraison.

Ce que le contrôle des droits ne fait pas

Il ne remplace pas les droits dans le système source. Un compte de service aux droits trop larges reste un risque, même avec un contrôle devant lui. Tracez la limite des données dans le système source, pas dans le prompt.
Il ne filtre ni les arguments ni les contenus. Un outil qui accepte un langage de requête libre ne peut pas être raisonnablement restreint aux « seules factures ». Préférez les connecteurs avec des outils séparés ou avec un mode lecture seule.
Il n’est pas la seule limite. Pour les connecteurs qui travaillent avec les droits de chaque personne, c’est le système cible lui-même qui trace la limite de référence, voir Modèles de connecteurs.