Tâches, événements et audit

Les tâches, les événements et l’audit répondent à des questions de gestion différentes. Une tâche indique à l’opérateur si un travail de longue durée s’est terminé. Un événement aide l’interface et l’automatisation à réagir à un changement d’état. Un enregistrement d’audit indique à un examinateur de sécurité qui ou quoi a tenté une action lourde de conséquences. Aucun d’eux, à lui seul, ne prouve le résultat pour le client.

Le responsable de la ressource décide de réessayer ou de revenir en arrière, l’opérateur réconcilie l’état de la tâche avec l’environnement d’exécution propriétaire, et le responsable de la sécurité définit la rétention et l’export de l’audit. Gardez ces enregistrements reliés par des identifiants stables de ressources, de requêtes, de tâches et d’opérations.

Les tâches représentent un travail durable de longue durée, comme les builds, les déploiements, les migrations, les imports, le provisionnement et les mises à jour. Suivez l’état, l’avancement, les journaux, le code d’erreur et la disponibilité des actions de relance ou d’annulation. Ne lancez pas de doublons simplement parce qu’un navigateur s’est déconnecté.

Les événements mettent à jour l’état de l’interface en direct et déclenchent les processus opérationnels pris en charge. Les consommateurs doivent revalider l’autorisation et tolérer les reconnexions et les limites de rejeu.

Les enregistrements d’audit attribuent les actions pertinentes pour la sécurité et la configuration à des utilisateurs ou à des acteurs système. Le blocage ou la suppression d’un utilisateur ne supprime pas l’attribution historique. Exportez vers un SIEM lorsqu’une rétention ou une corrélation indépendante est requise.

Les détails de l’audit doivent identifier l’action et la ressource sans stocker de secrets, d’identifiants bruts, de clés privées, de prompts ni de sorties de modèles.

Cycle de vie des tâches

Les états habituels des tâches distinguent le travail en file d’attente, en cours, en attente, réussi, en échec, annulé et interrompu. Les états et actions disponibles dépendent de l’opération. L’avancement est une preuve fournie par le worker ou le démon propriétaire, et non une animation du navigateur.

Notez l’identifiant de la tâche avant de quitter une opération de longue durée. Recharger la page doit vous reconnecter à l’état durable plutôt que créer une seconde opération. Si la réponse à une commande est perdue, examinez à la fois la tâche et le propriétaire avant de réessayer.

Relancer, annuler et forcer l’annulation

Ne relancez que lorsque le contrat de la tâche indique que l’opération peut être relancée, ou lorsque la réconciliation prouve que la tentative précédente a atteint un état final. Les demandes d’annulation sont coopératives lorsque le propriétaire prend en charge l’annulation. Force Cancel peut empêcher Opfield d’attendre une opération abandonnée, mais ne justifie pas de supposer que l’action d’exécution sous-jacente n’a jamais eu lieu.

Après une annulation ou une interruption, actualisez la ressource auprès de son propriétaire et résolvez tout marqueur d’opération avant de lancer une autre modification.

Événements et état en temps réel

Les événements en temps réel réduisent la latence de l’interface, mais ne sont pas la seule source de vérité. Les clients doivent tolérer les déconnexions, les rejeux, les livraisons en double et l’arrivée d’un événement avant un instantané actualisé. Après une reconnexion, chargez l’instantané faisant autorité et fusionnez les événements plus récents selon l’identité stable des ressources.

Les événements qui déclenchent une automatisation doivent revérifier l’autorisation, la propriété, les droits et l’état du cycle de vie actuels. Une permission historique au moment de la création de l’événement n’autorise pas une modification ultérieure.

Interprétation de l’audit

Les enregistrements d’audit identifient l’acteur, l’action, la ressource, l’horodatage, le résultat et le contexte de requête pertinent. Les acteurs système et d’automatisation doivent rester distinguables des sessions humaines et de l’usurpation d’identité. Le blocage ou la suppression d’un utilisateur préserve l’attribution historique.

L’audit n’est pas un journal de débogage. Utilisez les journaux d’exploitation et les tâches pour les détails d’implémentation, et l’audit pour la responsabilité en matière de sécurité et de configuration. Exportez vers un stockage SIEM contrôlé de manière indépendante lorsque la rétention ou la corrélation doit survivre à un incident d’Opfield.

« Attribution immuable » signifie que les changements de cycle de vie des comptes ne réécrivent pas l’acteur historique rattaché à un enregistrement d’audit. Cela ne signifie pas que la base d’audit locale est un stockage WORM ou qu’elle est cryptographiquement inviolable face à une personne qui contrôle l’hôte Opfield, PostgreSQL, les sauvegardes ou les clés de chiffrement. Ces administrateurs restent à l’intérieur de la frontière de confiance.

Si la politique exige des preuves qui survivent à une compromission du plan de contrôle, exportez en continu les enregistrements d’audit vers un SIEM ou une destination compatible WORM administrés de manière indépendante, restreignez-y la suppression, synchronisez l’heure et surveillez les interruptions de l’export. Gardez la politique de rétention externe et la revue des accès séparées de l’administration d’Opfield.

Liste de contrôle d’investigation

1. Identifiez la ressource et l’effet visible par les clients.
2. Trouvez l’enregistrement d’audit déclencheur et l’identifiant de requête.
3. Trouvez la tâche ou l’opération durable.
4. Comparez l’état souhaité avec l’état actuel du propriétaire.
5. Examinez des journaux d’exploitation limités.
6. Consignez la relance, l’annulation, le retour arrière et la vérification finale.

Interprétation du succès et de l’échec

Une tâche réussie signifie que le processus propriétaire a atteint son état final documenté. Cela ne prouve pas nécessairement la propagation DNS, l’accès des clients externes, l’exactitude au niveau applicatif, l’envoi d’un e-mail, le traitement des données d’un webhook ni la restauration des données métier. Ajoutez une vérification indépendante adaptée à la ressource.

Une tâche en échec ou interrompue ne prouve pas qu’aucun effet de bord ne s’est produit. Le propriétaire peut avoir créé un conteneur, écrit un fichier, modifié un fournisseur ou terminé une action d’exécution avant la perte de l’acquittement. Lisez l’état actuel du propriétaire et l’historique des opérations avant tout nettoyage ou toute relance.

Les états d’attente doivent identifier la dépendance ou l’entrée requise. Si une tâche reste en attente sans propriétaire clair, conservez ses identifiants et escaladez plutôt que d’utiliser Force Cancel comme nettoyage de routine.

Maintenance et rétention

La maintenance (housekeeping) supprime les données dont Opfield n’a plus besoin, chaque jour à 02:00 par défaut. Configurez-la dans Settings > Features > Housekeeping : housekeeping:view affiche la configuration, les statistiques et l’historique d’exécution, housekeeping:run lance une exécution, et housekeeping:configure modifie les catégories et le calendrier. Chaque catégorie peut être désactivée. La catégorie Audit Log conserve 90 jours par défaut ; exportez les enregistrements d’audit vers un SIEM lorsque la politique exige une rétention plus longue.

Deux catégories ajoutées en 2.11 sont activées par défaut :

Catégorie	Ce qu’elle supprime
Operation History	Les tâches de conteneurs Docker terminées après un jour. Après la période de rétention, 90 jours par défaut : les builds terminés avec leurs journaux, les lots de builds vides, les opérations Compose, Workload Availability et d’hébergement terminées, et les livraisons de webhooks des sources Git. Chaque ressource conserve ses 10 exécutions les plus récentes, et les enregistrements encore utilisés par quelque chose — un artefact de build, un placement Availability, un instantané ou l’origine d’un nœud hébergé — sont conservés
Expired OAuth Grants	Les codes d’autorisation OAuth et les jetons d’accès et d’actualisation expirés, ainsi que les clients OAuth sans aucune autorisation depuis 90 jours. Un jeton d’actualisation est conservé jusqu’à son expiration, afin que sa réutilisation reste détectée

Les autres catégories couvrent les journaux nginx, les alertes ignorées, les livraisons de notifications, les journaux structurés, les tables système de ClickHouse, les artefacts d’IA orphelins, le registre interne, les volumes orphelins, les clés de PKI système retirées, les fichiers de défi ACME et les anciennes images d’Opfield.

Rétention et preuves externes

Les lignes d’audit ne sont pas perdues lorsqu’Opfield s’arrête. À l’arrêt, Opfield écrit les lignes encore en cours avant de fermer la connexion à la base de données. Lorsque la base a déjà disparu, comme lors d’un arrêt de l’hôte où tous les conteneurs s’arrêtent en même temps, une ligne qui ne peut pas être écrite est ajoutée à un fichier tampon sur le volume de données de l’application (/var/lib/opfield/audit-spool) et enregistrée au démarrage suivant avec son identifiant d’origine ; un rejeu qui s’arrête à mi-chemin n’ajoute donc jamais une ligne deux fois ; l’export SIEM reprend les lignes qu’il enregistre. Les nouvelles installations arrêtent aussi PostgreSQL par un arrêt « smart », qui attend jusqu’à 75 secondes qu’Opfield ferme ses connexions ; les installations existantes en bénéficient lors de la prochaine recréation de leur conteneur PostgreSQL.

Conservez les enregistrements d’audit conformément à la politique de sécurité et de conformité, et exportez-les vers un stockage SIEM contrôlé de manière indépendante lorsque les preuves doivent survivre à une panne d’Opfield ou à une compromission d’un administrateur. Les journaux d’exploitation des tâches peuvent avoir une rétention et une sensibilité différentes. N’enrichissez pas les charges utiles d’audit avec des secrets ou des corps de requête bruts simplement pour faciliter le débogage.

Lorsque vous fournissez des éléments de preuve au support ou à une autre équipe, incluez les horodatages, les identifiants stables, l’état final, les détails d’erreur assainis et le résultat de la vérification indépendante. Retirez les identifiants, la topologie interne, les données clients, les prompts, les sorties de modèles et les journaux sans restriction.