Marquages et récupération gouvernée

Sécurité au niveau des instances pour la base de connaissances organisationnelle — restreignez l'accès à des lignes individuelles selon les habilitations, liées à votre organigramme, appliquées à chaque lecture.

Les partitions décident de dans quelle base de connaissances vit une ligne. Les marquages décident de qui, au sein de l'organisation, peut lire une ligne individuelle — indépendamment de la partition. C'est ainsi que « la direction peut lire les documents de direction, mais un employé ordinaire ne le peut pas » est appliqué au niveau d'une seule ligne, et non d'une partition entière.

Un marquage est satisfait par votre organigramme — rôles fonctionnels (PDG, DPT, Ingénieur…) et ancienneté — et non par des rôles de contrôle d'accès. Un propriétaire org qui n'est pas affecté au rôle fonctionnel concerné peut configurer un marquage mais ne pourra jamais lire le contenu qui lui est soumis. Il n'existe pas de contournement administrateur.

Qu'est-ce qu'un marquage

Un marquage est un label de sécurité nommé, limité à l'organisation (ex. slt, finance, pii). Chaque marquage définit le prédicat qui le satisfait :

satisfyingFunctionalRoles — détenir l'un quelconque de ces rôles fonctionnels de l'organigramme satisfait le marquage.
minSeniorityLevel — un plancher d'ancienneté ; y être ou le dépasser satisfait le marquage.
departments — appartenance à un département (voir la note à la fin — actuellement limité).

Un appelant peut lire une ligne si et seulement s'il satisfait chaque marquage sur elle (refus par défaut, ET logique entre marquages). Les marquages inconnus ou non résolus échouent fermement — la ligne n'est jamais retournée.

Définir un marquage

Créer le marquage

POST /org-kb/markings
{
  "slug": "slt",
  "displayName": "Senior Leadership Team",
  "satisfyingFunctionalRoles": ["ceo", "cto", "cfo"],
  "minSeniorityLevel": "executive",
  "humanReviewAllowed": false
}

Autorité de configuration

Vous ne pouvez créer (ou modifier) un marquage que si vous le satisfaisez vous-même. Un administrateur non membre de la direction ne peut pas créer ni affaiblir un marquage slt — l'accès sensible ne peut donc pas fuiter via le plan de configuration. Listez les marquages existants avec GET /org-kb/markings.

L'appliquer

Les marquages sont associés à une ligne au moment de la promotion comme l'union des marquages de la source et des marquages de référence de la partition cible — la promotion ne peut qu'augmenter la sensibilité, jamais la réduire.

Récupération gouvernée

Chaque chemin de lecture applique les marquages de la même façon, et effectue toujours un pré-filtrage (les lignes refusées n'apparaissent jamais dans les résultats, les comptes ni les classements — elles sont absentes, pas expurgées) :

Requête org KB — POST /org-kb/query résout votre identité organigramme et supprime chaque ligne dont vous ne satisfaisez pas les marquages avant de retourner les résultats.
L'expurgation de champs s'applique toujours en plus : les propriétés confidential / restricted sont expurgées des lignes que vous pouvez voir.

Si votre identité ne peut pas être résolue, la récupération échoue fermement — vous ne voyez que les lignes non marquées.

Promotion sans exposition

Un marquage avec humanReviewAllowed: false signifie que son contenu ne doit jamais être vu par un réviseur humain. Les promotions portant un tel marquage prennent le chemin d'approbation automatique (acteur système) ou sont rejetées — aucune personne n'est jamais désignée comme réviseur, et un réviseur n'est eligible que s'il satisfait lui-même les marquages de la demande. Cela permet au contenu sensible d'alimenter le corpus organisationnel sans qu'aucun administrateur non habilité ne le lise jamais.

Les départements ne sont pas encore une dimension de marquage. user.department est du texte libre aujourd'hui ; conditionner l'accès à celui-ci n'est pas sûr. Les marquages limités aux départements (Finance uniquement, Juridique uniquement) s'activeront une fois que les départements seront devenus une entité structurée et assignable. D'ici là, modélisez l'accès basé sur le niveau hiérarchique/les habilitations avec des rôles fonctionnels et l'ancienneté.