Une version de politique publiée ne change jamais. Modifier une politique et la republier crée une nouvelle version ; elle ne réécrit jamais celle déjà déployée sur les machines. C’est ce qui rend le retour arrière sûr : la dernière bonne version est toujours là, octet pour octet, et revenir en arrière n’efface pas l’historique des décisions qui explique ce qui s’est mal passé.
Trouver une version
Allez dans Admin → éditeur de politiques et ouvrez la bibliothèque pour comparer les versions d’une politique ou en désactiver une.
Effectuer un retour arrière sur une machine
- Allez dans Admin → application, développez la machine concernée et identifiez son dernier ensemble de politiques connu comme fonctionnel.
- Sélectionnez modifier, restaurez ces versions et leurs effets, puis appliquez le nouveau déploiement.
- Attendez l’enregistrement de la machine, puis vérifiez le déploiement signalé.
- Ouvrez Observer → politique ainsi que les sessions concernées pour confirmer que le travail valide n’est plus bloqué.
Chaque déploiement sur une machine correspond à une génération numérotée. Listez-les, puis réinstaurez-en une :rollback crée une nouvelle génération portant l’ancien ensemble plutôt que de rembobiner le compteur, de sorte que l’historique reste en ajout uniquement. Cette commande refuse une génération faisant référence à une politique désactivée ou supprimée. Elle nécessite une session connectée avec policies:write. fp fleet diff <machine-id> montre ce qui était prévu par rapport à ce que la machine a appliqué — il s’affiche comme behind jusqu’au prochain sondage de la machine — et sur la machine elle-même, failproofai policies liste le déploiement en cours d’exécution. Retirer une politique de toutes les machines
Chaque commande crée une nouvelle génération sur chaque déploiement qu’elle touche. Revenir en arrière sur l’une de ces générations n’est toutefois pas la bonne façon d’annuler un disable — rollback refuse une génération faisant référence à une politique désactivée, et toutes les générations antérieures à la désactivation mentionnent celle-ci. fp policies enable est le chemin de retour, et il crée sa propre génération à son tour.
Retour arrière sur un pack
Un pack est épinglé à la version que vous avez installée ; revenir en arrière signifie donc installer une version antérieure :
Sans terminal, ou avec --policy, --category ou --all, le ré-ajout conserve le sous-ensemble que vous aviez choisi. Dans un terminal sans aucune de ces options, le sélecteur s’ouvre avec les sélections par défaut de l’auteur pré-cochées, et ce que vous cochez remplace votre sélection — pensez donc à recocher ce que vous aviez.
Quand effectuer un retour arrière
- Une politique bloque une action de production attendue.
- Le volume de correspondances est sensiblement plus élevé que ce que le déploiement observé avait prédit.
- Une politique dépend de champs qu’une intégration ne fournit pas.
- Une nouvelle version modifie un comportement en dehors du mode d’échec prévu.
Après un retour arrière, ouvrez les sessions concernées et identifiez la condition à l’origine du faux positif. Publiez une nouvelle version, testez aussi bien le cas non sécurisé que le cas légitime, puis observez-la à nouveau avant de l’appliquer.
failproofai config --pause suspend les politiques locales pour une session uniquement et n’affecte jamais les politiques gérées dans le cloud — ce n’est donc pas une solution pour sortir d’un mauvais déploiement cloud. Une pause élargit également l’exposition pour toutes les politiques dans son périmètre ; préférez revenir en arrière sur la seule version qui se comporte mal.
