Produit · Gouvernance

    Des permissions auxquelles vos ingénieurs se fient.

    Un access tag porte huit droits nommés, réglables séparément pour les modèles et pour les instances. Chaque action d'une personne, d'un connecteur ou d'un agent IA est enregistrée sur l'item concerné. Auditeurs et fournisseurs externes reçoivent exactement la tranche accordée, et rien d'autre.

    koddex · Access tag · QA-Regulatory
    DroitModèleInstance
    viewImplicite avec tout access tag
    editValeurs et métadonnées
    use modelCréer des items depuis ce modèle
    view historyLire le log d'activité
    manage revisionsVoir et créer des révisions
    set access tagAppliquer ce tag à la création
    shareAjouter un autre access tag
    lockRendre l'item immuable
    Chaque droit sauf view et use model se règle séparément pour les modèles et pour les instances.

    La plupart des PLM ont des rôles. Koddex a des règles de résolution.

    Un rôle vous dit comment quelqu'un s'appelle. Une règle de résolution vous dit exactement quel droit est vérifié, sur quel objet, avant qu'une action passe. Toute la revue de sécurité tient dans cet écart : l'un est une promesse, l'autre s'audite ligne à ligne.

    Access tags

    Huit droits, et une réponse distincte pour les modèles et les instances.

    Un access tag est un label posé sur un item ou un modèle, et il porte les droits qu'un groupe ou un utilisateur détient sur tout ce qui le porte. La nuance qui compte en pratique : une équipe peut avoir le droit d'éditer un modèle sans avoir celui d'éditer les items qui en découlent, ou l'inverse.

    • Les identités sont des membres ou des service accounts ; les groupes les organisent ; les tags disent ce qu'ils peuvent faire
    • Les rôles gouvernent qui administre utilisateurs, groupes et tags, pas ce qui arrive à la donnée
    • L'application en masse vérifie la règle sur chaque item concerné et saute ceux où vos droits manquent
    koddex · Identities and tags
    Membres
    Service accounts
    Groupes
    Access tags
    Historique d'activité

    Qui a changé le critère d'acceptation, et quand.

    C'est la question que pose un auditeur de surveillance EN 9100, et la raison d'être du log d'activité. Chaque modification d'un item non verrouillé est enregistrée chronologiquement avec l'utilisateur, l'horodatage et les anciennes et nouvelles valeurs. Pas d'archéologie d'e-mails, pas de reconstitution au tableur.

    • Lire le log est lui-même un droit : l'historique n'est pas visible de tous par défaut
    • Les items retirés survivent dans l'historique de ce dont ils ont été retirés, et sont restaurables
    • Les actions de connecteurs et d'agents atterrissent dans le même log que les modifications humaines, avec leurs permissions
    Lock and revise
    koddex · Activity · TR-4421
    a.chen@editedAcceptance criteria · 4.2 → 4.5 bar14:32
    m.laurent@approvedTest Report TR-442114:28
    ci-bot@linkedTR-4421 → REQ-11814:15
    s.okafor@lockedBaseline B-1411:26
    Partage externe

    Donnez à l'auditeur la tranche, pas le dossier.

    Ajoutez un utilisateur externe à un access tag et il devient un tag partagé : cette personne voit exactement ce qui le porte. Koddex demande confirmation avant d'ajouter quelqu'un hors de votre organisation, et à nouveau avant de lui accorder l'écriture. Tags partagés et membres externes sont marqués visiblement avec leur organisation.

    • Seuls les administrateurs d'access tag ou de groupe peuvent faire entrer un externe
    • Un par un, ou en masse depuis un CSV d'adresses e-mail
    • Les externes ne vous sont visibles que sur les items que vous pouvez déjà voir vous-même
    Traçabilité audit-ready
    koddex · Shared access tag
    MLM. LaurentQuality Managerinterne
    ACA. ChenSystems Engineerinterne
    PNP. NadeauAuditeur externeBureauCert
    SOS. OkaforFournisseurPolyMed SA
    Koddex demande confirmation à chaque ajout d'un externe, et une seconde fois pour lui accorder l'écriture.

    Douze règles de résolution, écrites noir sur blanc.

    Pour chaque action, la documentation précise exactement quels droits sont vérifiés, et sur quoi. Vous n'avez pas à deviner ce qu'un rôle autorise : vous le lisez.

    1Voir un item
    2Éditer un item
    3Créer un item
    4Changer les access tags d'un item
    5Voir l'historique de révisions
    6Créer une révision
    7Voir l'historique d'activité
    8Voir et assigner des utilisateurs
    9Étendre un modèle
    10Éditer un modèle utilisé par d'autres
    11Verrouiller un item
    12Commenter un item

    Ce qu'une revue de sécurité demande vraiment.

    Ce sont les chiffres qui reviennent quand un responsable sécurité s'assied devant le modèle, pas ceux qui rendent bien sur un slide.

    Droits nommés par access tag

    view, edit, use model, view history, manage revisions, set access tag, share et lock. Rien d'implicite, rien de groupé.

    8
    Droits accordés un par un

    Des règles de résolution lisibles

    Une règle documentée par action, indiquant quel droit est vérifié et s'il porte sur le modèle ou sur l'instance.

    12
    Règles de résolution documentées

    Deux réponses distinctes, modèle et instance

    Tous les droits sauf view et use model se dédoublent : éditer un template et éditer ses items sont deux décisions.

    2
    Plans de permission par droit

    Questions fréquentes

    Amenez votre responsable sécurité à l'appel.

    On parcourt les access tags, les douze règles de résolution et le log d'activité sur un workspace réel. C'est le plus rapide pour savoir si le modèle colle à votre politique.