Les journaux locaux appuient les preuves SOC 2 CC7

Les journaux locaux d'exécution avec détection des altérations peuvent appuyer des preuves SOC 2 CC7, mais ils ne suffisent pas seuls pour CC7.1 ou CC7.2. Ils peuvent montrer quel processus d'agent local a ouvert une session, quels appels avec identifiants il a tentés, comment ces appels se sont terminés et si l'historique stocké a changé. Ils ne montrent pas que chaque système du périmètre a fait l'objet d'une surveillance des vulnérabilités ni qu'une personne a étudié les anomalies au rythme prévu.

Cette limite compte. J'ai vu des équipes remettre à l'auditeur un export de journaux parfaitement signé et le présenter comme leur contrôle de surveillance. L'export prouvait que des événements existaient. Il ne prouvait ni la couverture, ni la logique de détection, ni la revue, l'escalade ou la correction. Le journal local devient utile comme source de preuves dans un dispositif de contrôle. Si on le confond avec le contrôle entier, les lacunes apparaissent lors de l'échantillonnage.

Le test pratique est simple : reliez chaque affirmation à un champ, une procédure, un responsable et une preuve corroborante. S'il manque un élément, consignez la limite avant que l'auditeur ne le fasse.

CC7.1 et CC7.2 posent des questions différentes

CC7.1 demande si l'entité utilise des procédures de détection et de surveillance pour repérer les changements de configuration qui introduisent de nouvelles vulnérabilités et l'exposition aux vulnérabilités récemment découvertes. CC7.2 demande si elle surveille les composants et leur fonctionnement pour détecter des anomalies liées à des actes malveillants, des catastrophes naturelles ou des erreurs, puis les analyse afin de décider s'il s'agit d'événements de sécurité. Le journal d'une action API ou SSH d'un agent peut contribuer aux deux critères, mais différemment.

Pour CC7.1, un journal d'exécution constitue généralement une preuve de changement. Il peut montrer qu'un agent a modifié une règle de pare-feu, déployé un paquet, changé un réglage d'identité ou exécuté une commande sur un hôte. Cette preuve aide à relier une dérive de configuration ou une nouvelle exposition au processus qui l'a causée. Le journal ne détecte pas une vulnérabilité nouvellement publiée sans un scanner, un flux d'avis, un inventaire ou une procédure de revue qui compare les composants déployés aux nouvelles informations.

Pour CC7.2, le même journal fournit une télémétrie opérationnelle. Un appel refusé, une destination inattendue, des échecs d'authentification répétés, une commande inhabituelle ou une action hors session approuvée peuvent alimenter la détection d'anomalies. Pourtant, stocker un événement n'équivaut pas à le surveiller. L'organisation doit encore définir comment sélectionner les événements, reconnaître les motifs suspects, les transmettre à un réviseur et consigner la décision.

Cette distinction évite une erreur fréquente : confondre journalisation et détection. Une source de journaux enregistre des observations. Un contrôle de détection applique une logique ou un jugement humain à ces observations. L'auditeur teste souvent la conception et le fonctionnement, donc une preuve de collecte ne répond qu'à la moitié de la question.

Les Trust Services Criteria de l'AICPA proposent des points d'attention, pas une liste universelle d'outils. Une entreprise peut donc concevoir des contrôles adaptés à ses risques, mais il n'existe ni durée magique de conservation ni catégorie de produit obligatoire. La description du système, l'évaluation des risques, le libellé du contrôle et la procédure réelle déterminent la pertinence des données locales.

Un contrôle limité et défendable pourrait dire : « Chaque jour ouvré, l'équipe sécurité examine les actions de production médiées par des agents afin de repérer les appels refusés ou échoués, les nouvelles destinations et les commandes SSH privilégiées ; le réviseur consigne la décision et transmet les événements suspects selon la procédure d'incident. » Ce texte identifie la population, les signaux, la fréquence, le responsable et le suivi. « Nous conservons des journaux avec détection des altérations » ne décrit qu'une propriété du stockage.

L'identité de session décrit le processus, pas la personne

Un bon journal de session identifie assez précisément le processus de l'agent pour distinguer deux exécutions. Enregistrez au minimum un identifiant unique, les heures de début et de fin, le chemin de l'exécutable, l'identité de signature ou l'empreinte binaire, le processus parent, l'identifiant de l'hôte, le compte local, la décision d'autorisation, son auteur et l'état de révocation. Conservez aussi la méthode d'obtention de chaque champ, car une valeur déclarée par l'agent est moins fiable qu'une valeur observée par la passerelle ou le système d'exploitation.

Ne transformez pas discrètement une identité de processus en identité humaine. Une autorité de signature indique qui a signé un binaire. Un compte local indique le contexte système qui l'a lancé. Aucun des deux ne prouve quel salarié a rédigé le prompt, approuvé chaque action ou voulu une commande précise. Si le contrôle exige une attribution humaine, reliez la session aux connexions du fournisseur d'identité, à la gestion des appareils, aux approbations, au propriétaire du ticket ou à l'affectation d'un poste contrôlé.

La même prudence vaut pour les liens parent-enfant. Un shell peut lancer un agent, qui lance un auxiliaire, lequel demande une action SSH. Enregistrez la chaîne observée, mais désignez le processus soumis au contrôle. Sinon, une équipe regroupera par agent principal, une autre par auxiliaire et la population changera au milieu de l'audit.

Un objet compact rend le contrat de preuve explicite :

{"session_id":"ses_01JX...","host_id":"mac-042","started_at":"2026-07-21T14:03:18Z","ended_at":"2026-07-21T14:48:02Z","executable":"/usr/local/bin/agent","signing_authority":"Developer ID Application: Example","parent_pid":8821,"local_account":"builder","authorization":{"decision":"approved","method":"local_user_action","at":"2026-07-21T14:03:22Z"},"revoked_at":null}

Les points de suspension signalent un exemple abrégé, pas un identifiant acceptable en production. La preuve réelle exige la valeur complète et une règle d'unicité documentée. Elle exige aussi une preuve de synchronisation des horloges. Si les horodatages de l'endpoint, de la passerelle, de l'identité et du ticket dérivent, l'auditeur ne peut pas reconstruire l'ordre avec fiabilité, même si chaque source reste cohérente.

Dans Sallyport, le journal Sessions enregistre les exécutions d'agents, tandis que l'approbation du premier appel affiche d'abord l'autorité de signature du processus et reste valable jusqu'à sa fin. C'est une bonne preuve locale, mais des sources externes restent nécessaires si le contrôle mentionne un salarié, un appareil géré, un changement approuvé ou une connexion d'entreprise.

Le résultat d'un appel doit permettre une décision

Le journal d'un appel doit préciser ce que le processus a tenté, où, quelle référence d'identifiant ou classe de clé la passerelle a utilisée, si une approbation était requise, quelle décision a été prise, si l'exécution a commencé et comment elle s'est terminée. Enregistrez les horaires et la durée, le canal, la destination normalisée, le type d'action, les classes de résultat et d'erreur, ainsi qu'un identifiant stable de corrélation. Gardez assez de détails pour enquêter sans copier de secrets ni de réponses sensibles dans la piste d'audit.

Le vocabulaire des résultats doit être strict. « Refusé » signifie qu'un contrôle a arrêté l'exécution avant l'action externe. « Échoué » signifie que l'exécution a commencé, mais a renvoyé une erreur, expiré ou perdu le transport. « Réussi » signifie que l'interface distante a signalé un succès selon une règle documentée. « Inconnu » couvre le cas où le client perd la confirmation après l'envoi. Fusionner refus et échec détruit la preuve que le contrôle préventif a fonctionné.

Le statut HTTP raconte rarement toute l'histoire. Une réponse 200 peut contenir une erreur applicative. Un 202 peut seulement indiquer une mise en file. Un code de sortie SSH nul prouve que le shell distant a signalé un succès, pas que l'état attendu a changé. Définissez la normalisation par type d'action et conservez le statut brut à côté du résultat normalisé.

Un journal d'appel peut prendre cette forme :

{"call_id":"call_01JX...","session_id":"ses_01JX...","occurred_at":"2026-07-21T14:17:09Z","channel":"ssh","destination":"prod-web-03","action":"systemctl restart api","credential_ref":"ssh-prod-ops","approval":{"required":true,"decision":"approved","method":"touch_id"},"execution":{"started":true,"result":"failed","exit_code":1,"error_class":"remote_command_error","duration_ms":842},"ticket_ref":"CHG-1842"}

N'enregistrez pas de bearer token, clé privée, en-tête d'autorisation complet ou réponse brute pour donner une impression d'exhaustivité. Un journal qui divulgue des secrets crée un autre échec de contrôle. Utilisez une référence stable et consignez la méthode d'injection, en gardant les secrets hors de l'agent et des preuves exportées.

Pour CC7.1, les réviseurs peuvent rapprocher les appels capables de modifier la configuration des dérives, déploiements et résultats de scans. Pour CC7.2, ils peuvent sélectionner les actions refusées, échouées, inconnues, à destination inhabituelle ou à haut risque. Le journal n'appuie ces procédures que si l'organisation peut énumérer la population complète. Une capture de cinq événements prouve l'existence de cinq événements, pas l'examen de tous les événements pertinents.

L'intégrité prouve la cohérence, pas la vérité

Une chaîne de hachage peut détecter la suppression, l'insertion, le réordonnancement ou la modification après l'entrée des données, si le vérificateur part d'un format et d'une ancre fiables. Elle ne prouve pas que la source a capturé chaque action, que chaque champ était juste à l'écriture ou qu'un attaquant n'a jamais contourné le journal. La distinction est nette : l'intégrité des enregistrements n'est pas l'exhaustivité de la collecte.

Un stockage chiffré sans capacité de réécriture réduit le risque qu'un lecteur ou un chemin d'analyse compromis modifie le passé. Le chiffrement protège la confidentialité. Le chaînage protège une continuité vérifiable. Des clés matérielles peuvent renforcer l'accès. Ces mécanismes répondent à des questions différentes, alors documentez-les séparément plutôt que de qualifier tout le système d'« immuable ».

Une procédure d'intégrité exige des entrées répétables et des résultats conservés. Avec Sallyport, le réviseur peut vérifier la chaîne chiffrée hors ligne sans clé :

$ sp audit verify /evidence/agent-audit-2026-07.splog
verified: 18432 records
first: 2026-07-01T00:01:44Z
last: 2026-07-31T23:58:10Z
chain: valid

La sortie exacte doit venir de la version installée. Le format ci-dessus indique ce que le dossier doit conserver : commande, version, identifiant ou empreinte du fichier, nombre d'enregistrements, bornes temporelles, résultat, heure et opérateur. Si la vraie commande utilise d'autres libellés, gardez sa sortie au lieu de la réécrire.

Lancez un test négatif avant de vous fier à la procédure. Copiez un export hors production, modifiez ou retirez un enregistrement avec un dispositif de test validé par l'ingénierie, puis confirmez l'échec. Gardez la méthode, l'échec attendu, la sortie réelle, la version et l'approbation. Une vérification réussie montre qu'un fichier est passé ; un test négatif contrôlé montre que le vérificateur détecte bien l'altération annoncée.

Rapprochez aussi les limites. Comparez le dernier compteur et l'ancre d'un export au premier état attendu du suivant. Examinez les trous, remises à zéro, réinstallations, sauts d'horloge et remplacements d'hôtes. Si un administrateur local peut effacer le journal et son ancre, la chaîne peut valider fidèlement uniquement l'historique de remplacement. Envoyez ancres, empreintes ou reçus signés vers un emplacement contrôlé séparément à une fréquence adaptée au risque.

NIST Special Publication 800-92 recommande de protéger l'intégrité des archives et de vérifier les journaux transférés, souvent par comparaison d'empreintes. Ce conseil reste pertinent, mais une empreinte ne remplace pas la surveillance de la couverture. Utilisez-la pour révéler les échecs de transfert et de conservation, puis vérifiez que toutes les sources du périmètre produisent des données.

La conservation dépend de la période et de l'enquête

SOC 2 n'impose pas un nombre universel de jours aux preuves CC7.1 ou CC7.2. Définissez la durée selon la période d'audit, les obligations légales et contractuelles, les besoins d'enquête, le délai de détection, la sensibilité et le temps de production d'un échantillon. La politique doit nommer les catégories conservées, l'emplacement, le responsable, les restrictions, la destruction et les exceptions.

Pour un examen Type 2, l'auditeur teste le fonctionnement sur une période. Si l'équipe ne garde que l'historique local récent, elle ne pourra peut-être pas fournir les échantillons du début ni prouver la continuité. Couvrez toute la période, la préparation, les travaux et une marge de suivi. L'équipe juridique ou conformité doit résoudre les obligations plus longues au lieu de copier la durée d'un autre rapport.

Le stockage uniquement local entraîne un échec prévisible. Un ordinateur est remplacé en avril, son journal disparaît et l'échantillon d'octobre porte sur février. L'équipe possède une chaîne parfaite pour le nouvel appareil, mais aucune preuve pour la date choisie. Exportez les données et ancres vers un stockage contrôlé par l'organisation selon un calendrier défini, et conservez la preuve de l'exécution des exports.

Testez la récupération, pas seulement le réglage. Choisissez une date ancienne, trouvez la population de sessions, récupérez les appels, vérifiez l'intégrité et reliez un événement à sa décision de revue. Notez le délai et les échecs. Une capture de configuration montre le design ; une récupération ancienne réussie montre le fonctionnement.

La vie privée et la sécurité s'appliquent toujours. Les commandes, destinations, comptes et erreurs peuvent contenir des données personnelles ou des détails sensibles. Limitez l'accès, expurgez les copies selon une règle documentée et ne gardez une source complète que si elle est autorisée. L'expurgation ne doit pas changer l'ordre ou casser la vérification sans préserver un original vérifiable séparément.

La fréquence de revue doit laisser une preuve

Un contrôle de revue fonctionne lorsqu'un rôle désigné examine une population définie à une fréquence annoncée, applique des critères écrits et consigne la décision. « Les journaux sont revus régulièrement » ne permet pas un échantillonnage fiable. Une revue chaque jour ouvré peut convenir aux actions de production, une approbation par appel à quelques clés puissantes, et une revue hebdomadaire aux destinations de développement moins risquées. L'évaluation des risques doit justifier le choix.

Séparez l'approbation préventive de la revue de détection. L'approbation décide si une action peut continuer. La revue cherche si les actions permises, refusées, échouées ou contournées indiquent une anomalie. Approuver un appel risqué ne prouve pas que quelqu'un a ensuite contrôlé le résultat, corrélé les appels ou reconnu une session compromise.

Définissez les sélecteurs avant l'outil. Une procédure peut retenir tous les result égaux à failed ou unknown, les approbations refusées, les nouvelles destinations, les identifiants de production désignés, les sessions lancées par une autorité inconnue et les échecs d'intégrité. Le réviseur classe chaque élément comme attendu, problème opérationnel, écart de politique ou événement suspect. Un événement suspect reçoit un identifiant et une heure d'escalade.

Conservez les résultats nuls. Lors d'une journée calme, la requête, la fenêtre couverte, l'heure, l'identité du réviseur et le compte nul prouvent l'exécution. Un mois avec uniquement des tickets positifs laisse planer un doute sur les autres jours. L'auditeur échantillonne l'exécution du contrôle, pas seulement les cas intéressants.

La preuve de revue comprend :

• La requête de population ou les critères d'export et leur version.
• Les heures de début et de fin, le fuseau et le nombre d'enregistrements.
• L'identité du réviseur, l'heure de fin et l'explication des retards.
• Chaque anomalie sélectionnée, sa décision et sa justification.
• Les références d'incident, de changement ou de problème en cas d'escalade.

Ne laissez pas le producteur des événements être l'unique réviseur. Une petite équipe peut utiliser une revue compensatoire par une autre personne, une inspection périodique de la direction et des exports contrôlés séparément. Décrivez la réalité. Une séparation inventée est pire qu'une limite honnête accompagnée d'un contrôle raisonnable.

La fréquence concerne aussi la santé du contrôle. Confirmez que les hôtes attendus produisent des données, que les exports finissent, que les horloges restent synchronisées, que les vérifications passent, que les sélecteurs correspondent encore au schéma et que les files sont traitées. Un changement de schéma peut casser silencieusement une requête. Ajoutez un événement test connu ou une limite de volume pour détecter un pipeline devenu muet.

CC7.2 exige d'analyser les anomalies pour déterminer si elles sont des événements de sécurité. Fermer un ticket comme « faux positif » sans raison ne démontre rien. Le dossier doit dire ce qui s'est passé, pourquoi les objectifs étaient menacés ou non, quelles preuves soutiennent la décision, qui l'a prise et si le suivi a modifié un détecteur ou une procédure.

Construisez le dossier autour des affirmations

L'auditeur demande généralement d'abord des preuves de conception, puis des preuves de fonctionnement pour certaines dates ou événements. Organisez les journaux afin que chaque pièce réponde à une affirmation. Ne donnez pas une archive brute en espérant que l'auditeur y découvre le contrôle.

Utilisez cette correspondance comme index :

Pour chaque contrôle, gardez une définition d'une page avec libellé, responsable, fréquence, populations, procédure, pièces attendues, emplacement et exceptions. Ajoutez un dictionnaire des champs. L'auditeur ne doit pas deviner si actor signifie salarié, compte local, processus ou autorité de signature.

Préparez deux parcours. Le premier part d'une date aléatoire et prouve que la revue complète s'est faite à temps. Le second part d'un appel risqué, remonte à l'autorisation puis suit le résultat distant, la revue et les tickets. Le premier teste la récurrence ; le second la traçabilité.

Rapprochez les totaux à chaque transfert. Le compteur Sessions doit correspondre à l'export avec les filtres documentés. Les appels doivent être aussi nombreux avant et après transfert. Les entrées de revue doivent se répartir entre sélection, exclusion et attente. Expliquez les écarts légitimes : tests, exclusions approuvées, doublons ou données hors fenêtre.

Un rapport Type 1 évalue la conception à un instant. Un Type 2 évalue aussi le fonctionnement sur la période. Une capture actuelle, une vérification récente ou une nouvelle procédure peut aider le Type 1, mais ne recrée pas des mois de Type 2 manquants. Si l'historique n'existe pas, déclarez la lacune et repoussez la préparation au lieu de fabriquer des validations rétroactives.

Avant les travaux, demandez à l'auditeur comment recevoir les preuves chiffrées ou sensibles, quels attributs il attend et s'il choisira des dates, sessions, appels ou alertes. Cela change l'emballage, pas le contrôle. Celui-ci doit déjà fonctionner régulièrement.

Collectez ailleurs la couverture et la réponse

Les journaux locaux ne couvrent que les actions qui passent par leur chemin. Ils ne prouvent pas que tous les changements de production y passent. Les administrateurs peuvent utiliser une console cloud, SSH direct, des identifiants CI/CD, le support d'un fournisseur, des comptes d'urgence, des tâches planifiées ou un autre poste. Inventoriez ces chemins, intégrez-les au contrôle ou collectez leurs journaux séparément.

CC7.1 exige aussi :

• Un inventaire actuel des actifs et logiciels lié au périmètre.
• Des normes de configuration et versions de référence approuvées.
• La configuration, la couverture, les résultats et la santé des scans.
• Un processus d'avis nouveaux et de correspondance des composants touchés.
• Les tickets de correction, acceptations de risque, délais, retests et exceptions.

Un appel qui installe la version X constitue une preuve de changement. Il ne dit pas que X est devenue vulnérable trois semaines plus tard. Le système de vulnérabilités, les avis, l'inventaire et la correction doivent raconter cette suite.

CC7.2 a besoin de sources plus larges. Collectez la télémétrie des endpoints, identités, réseaux, plans de contrôle cloud, applications, bases et disponibilité selon les risques. Gardez les définitions des détecteurs, inventaires de sources, tests de routage, astreintes, historiques d'alertes, décisions, incidents et actions postérieures. Les catastrophes et erreurs peuvent exiger des alarmes de disponibilité et procédures de continuité invisibles à une passerelle d'actions.

Prouvez l'exhaustivité par rapprochement. Comparez les appareils gérés à ceux qui exportent, les identifiants de production à ceux disponibles dans la passerelle et les changements cloud aux appels et automatisations autorisés. Examinez les écarts dans les deux sens : un changement sans appel peut signaler un contournement ; un appel réussi sans changement attendu peut révéler une mauvaise normalisation ou un retour arrière.

Collectez aussi la gouvernance. L'évaluation des risques explique pourquoi les agents comptent pour CC7.1 et CC7.2. Les politiques attribuent les responsabilités de journal, vulnérabilité, surveillance, revue, incident et conservation. La formation couvre les approbateurs et réviseurs. Les revues d'accès indiquent qui peut lire, exporter, administrer ou supprimer les preuves et modifier la détection.

NIST Special Publication 800-92 traite la gestion des journaux comme un cycle de génération, transmission, stockage, analyse et destruction. Ce cycle teste bien une conception trop locale. Si la génération et le stockage sont traités, mais pas la transmission, l'analyse et la destruction, la conception reste inachevée malgré une bonne cryptographie.

Tenez un registre des lacunes avec système non couvert, période absente, contrôle touché, risque, procédure temporaire, responsable et date cible. L'auditeur n'attend pas d'un petit journal qu'il voie toute l'entreprise. Il attend de la direction qu'elle connaisse son périmètre et limite ses affirmations aux preuves disponibles.

Faites-en un composant limité et testable

Les journaux locaux valent la peine lorsque le contrôle correspond à ce qu'ils observent. Ils donnent des détails de session et d'appel, conservent les refus jamais reçus à distance et rendent les modifications ultérieures détectables. Ils conviennent particulièrement aux agents IA, car les API distantes voient souvent une identité de service partagée et perdent le contexte local.

Ils s'affaiblissent lorsque l'équipe exagère l'identité, ignore les chemins alternatifs, conserve tout sur des postes remplaçables ou confond chaîne valide et surveillance complète. La réponse n'est pas un adjectif cryptographique supplémentaire. Il faut une affirmation plus petite, une population documentée, une revue récurrente, des résultats conservés séparément et des liens vers les systèmes de référence.

Avant de vous appuyer dessus, effectuez un test complet avec un événement semé. Lancez une session identifiable, tentez une action approuvée et une refusée, confirmez les résultats, exportez la période, vérifiez la chaîne, exécutez le sélecteur, consignez la décision et rapprochez l'événement distant. Répétez la récupération sur une période ancienne. Chaque rupture est une vraie lacune.

Donnez à l'auditeur le résultat de la chaîne, mais aussi l'inventaire des sources, le sélecteur, la preuve de revue, les exceptions et les corroborations externes. Ce dossier appuie un contrôle CC7.1 ou CC7.2 défendable. La chaîne seule soutient uniquement l'affirmation modeste que l'historique fourni conserve la structure attendue par le vérificateur.