Équipes

Politique de l'organisation

Comment une politique est rédigée, publiée, signée et appliquée par chaque zn-gate de l'organisation.

La politique de l'organisation est une liste de règles sur les secrets : vers où ils peuvent être envoyés et comment ils sont injectés. Les propriétaires et administrateurs la modifient dans Politiques et publient une nouvelle version ; chaque zn-gate de l'organisation la récupère.

Règles

Chaque règle s'applique à un secret (par son nom, jamais par sa valeur ; PRÉFIXE* et * sont acceptés) :

Champ	Signification
`secret`	Le nom du secret, par exemple `STRIPE_API_KEY`
`agents`	Agents auxquels un nouvel hôte peut être proposé, par exemple `claude-code`, `codex`. Un `deny` ignore cette liste
`mode`	Seul `proxy` est appliqué (la manière la plus restrictive) ; les autres valeurs sont ignorées
`allowHosts`	Les hôtes auxquels le secret peut être envoyé
`allowCommands`	Les commandes qui peuvent recevoir le secret
`injectAt`	L'endroit où le secret est injecté
`deny`	Bloque toute utilisation du secret, par tous les agents de la machine
`warn`	Laisse passer l'usage dans les autres limites de la règle, avertit le développeur et l'enregistre comme Avertissement, pour tous les agents de la machine. Utilisez `warn` ou `deny`, jamais les deux
`reason`	Affiché au développeur lorsqu'une règle d'avertissement s'applique ; pour les règles de blocage, c'est une note pour les administrateurs

Combinaison des règles :

Toutes les règles correspondantes s'appliquent, de haut en bas ; chacune ne peut que restreindre davantage.
deny bloque. warn laisse passer l'usage, avertit le développeur et le consigne dans le journal d'audit. Un deny s'applique aussi à secrets_render_file : un secret bloqué par la politique ne peut pas être écrit dans un fichier avec cet outil.
Les champs définis par une règle ne font que restreindre les paramètres locaux de la machine ; les champs omis conservent la valeur locale. Un nouvel hôte n'est proposé que tant que la politique est en vigueur (pas une fois expirée sur une machine en mode strict), nécessite l'approbation du membre, et un hôte avec un port n'est jamais proposé ; les commandes, les modes et injectAt ne sont jamais élargis.

Il existe une seule politique pour toute l'organisation, et non une par agent. Un deny ou un warn s'applique à tous les agents de la machine, quelle que soit la liste agents : cette liste décide seulement à quels agents un nouvel hôte est proposé.

Trois états

Chaque règle a l'un de trois états, choisi dans l'éditeur de règles :

État	Sur la machine du membre	Dans le journal d'audit
Non bloqué (par défaut)	L'usage est autorisé, avec les paramètres locaux et les limites de la règle.	Autorisé
Avertir	L'usage est autorisé dans les limites de la règle ; zn-gate avertit le développeur et l'enregistre.	Avertissement
Bloquer	L'usage est arrêté.	Bloqué

Un avertissement s'affiche sur la machine du développeur ; il n'arrête pas l'usage. Chaque usage averti ou bloqué apparaît dans Équipe → Journal d'audit, avec les métadonnées seulement (sans valeurs).

Les règles Avertir s'appliquent partout où un blocage s'applique : zn run, secrets_http_request, secrets_render_file et les restaurations de marqueurs et de jetons dans les hooks de l'agent. Quand un usage averti est autorisé, le développeur et l'agent voient cet avertissement, qui reste en anglais : zn: your team policy would block STRIPE_API_KEY here (policy note: "..."). It was allowed and recorded for your organization. Un enregistrement d'audit avec la décision warn est envoyé au journal de votre organisation. Un marqueur restauré par les hooks suit les mêmes règles : un secret que la politique bloque reste un marqueur et le hook indique pourquoi ; un secret sous une règle Avertir est restauré et enregistré.

Les règles Avertir nécessitent zn-gate 1.8.0 ou une version ultérieure. Sur les machines dotées d'une version antérieure de zn-gate, une règle Avertir agit comme Non bloqué : l'usage est autorisé dans les autres limites de la règle, mais aucun avertissement n'est affiché et rien n'est enregistré comme Avertissement. Demandez aux membres de mettre à jour zn-gate.

Dans une organisation qui a des règles Avertir, ne revenez pas à zn-gate 1.7.1. Cette version refuse une politique contenant des règles Avertir et n'applique que les paramètres locaux jusqu'à la prochaine synchronisation, qui télécharge une copie qu'elle peut lire. Restez sur 1.8.0 ou une version ultérieure.

Publication

La publication crée une nouvelle version. Le tableau de bord la valide d'abord. Un usage bloqué est signalé avec reason: policy:org_deny, et un usage averti est signalé avec reason: policy:warn et consigné dans le journal d'audit comme Avertissement. Le tableau de bord refuse aussi une règle qui définit à la fois warn et deny.

La publication exige une authentification à deux facteurs pour les propriétaires et administrateurs. Les modifications proposées depuis un agent de code avec un jeton d'administrateur de l'organisation attendent toujours qu'une personne les approuve ; voir Gérer votre équipe depuis votre agent.

Signature et versions

zn sert chaque politique signée avec la clé Ed25519 de votre organisation. Chaque machine la vérifie avec la clé publique qu'elle a épinglée lors de son adhésion.
Une politique servie est valide pendant 7 jours. Les machines vérifient régulièrement l'existence d'une nouvelle version, ainsi que lorsque vous exécutez zn team sync.
Une machine n'accepte jamais une version inférieure à la dernière qu'elle a acceptée, une politique signée avec une clé inconnue ou dont la signature ne se vérifie pas. Elle conserve la dernière politique valide et journalise policy:rejected.

Ce qui se passe sans réseau, ou lorsqu'une politique expire, est décrit dans Mode hors ligne.

Ce que l'organisation ne peut pas faire

zn-gate est un garde-fou local, et non un MDM. La politique de l'organisation fonctionne par-dessus les protections intégrées de zn-gate et ne peut pas les désactiver : les fichiers d'identifiants, ~/.zn et la configuration propre aux agents restent protégés quelle que soit la politique.