Analyse forensique

En bref

NextPDF Enterprise Forensics lit l’historique des mises à jour incrémentales d’un PDF et produit un rapport structuré, en lecture seule, des révisions, des événements classifiés et des changements par objet. Il prend en charge les flux de travail d’analyse forensique. Ce n’est pas un sceau inviolable et il n’affirme pas qu’un document est authentique ou non modifié.

Disponibilité & licence

Cette capacité est livrée dans NextPDF Enterprise (nextpdf/enterprise) et s’active avec une enveloppe de licence de palier Enterprise. Un déploiement sans ce droit d’usage ne charge pas les classes de la capacité. Comparer les éditions et obtenir une licence.

Installation

composer require nextpdf/enterprise:^3

Vue d’ensemble conceptuelle

Un PDF peut être mis à jour en ajoutant les changements à la fin du fichier plutôt qu’en le réécrivant. Chaque mise à jour ajoute une nouvelle section de références croisées et un nouveau trailer, et les octets originaux sont laissés en place — ISO 32000-2:2020 §7.5.6. Lorsqu’un objet est modifié, la mise à jour ajoute une nouvelle copie et la section de références croisées de la mise à jour enregistre un décalage d’octets qui remplace l’ancien décalage ; un lecteur résout la copie la plus récente — ISO 32000-2:2020 §7.5.6. La structure initiale du fichier peut être modifiée par des mises à jour ultérieures — ISO 32000-2:2020 §7.5.4. La section de références croisées d’une mise à jour énumère uniquement les objets qui ont été ajoutés, modifiés ou supprimés dans cette mise à jour — ISO 32000-2:2020 §7.5.5.

L’analyseur lit cette structure en couches. Il analyse la table de références croisées de chaque révision, dérive les frontières d’octets de révision et compare les entrées de chaque révision à celles de la révision immédiatement plus ancienne pour classifier chaque objet comme ajouté, modifié ou supprimé. Il regroupe ensuite les changements d’objets en événements de plus haut niveau : une signature a été ajoutée, le catalogue du document a été mis à jour, un dictionnaire de chiffrement est apparu, ou un ensemble d’objets a été ajouté, modifié ou retiré. La sortie est un objet de rapport unique qui porte un nombre de révisions, une taille totale, une liste de résumés par révision, une chronologie d’événements classifiés et la liste des changements par objet.

L’analyseur est en lecture seule. Il détecte l’existence d’une révision de signature à partir de marqueurs structurels ; il ne valide aucune signature, ne recalcule aucune empreinte et ne vérifie aucun certificat. La validation de signature est une capacité distincte du Core. Un rapport produit est une description structurelle de l’historique des mises à jour telle qu’analysée ; ce n’est pas une détermination qu’un document est authentique, qu’un changement était non autorisé, ni que chaque modification a été détectée. Considère le rapport comme une détection de résistance à l’altération telle que testée au regard de la vision qu’a l’analyseur de la chaîne de révisions, et non comme une garantie forensique ou une attestation recevable en justice.

Pourquoi ça fonctionne ainsi

L’analyseur s’arrête délibérément à la structure. Il rapporte ce que contient la chaîne de révisions, et n’affirme jamais qu’un changement était autorisé ni qu’une signature était valide. La présence structurelle et la validité cryptographique sont des revendications différentes ; les fusionner laisserait un appelant confondre la détection d’altération avec une garantie. La validité des signatures reste donc du ressort de l’unique surface de signature du Core, avec laquelle Forensics se compose plutôt que de la dupliquer. Le rapport est constitué de métadonnées structurelles JSON-sérialisables, de sorte qu’un SIEM ingère l’historique des modifications sans toucher au contenu du document. Contexte de conception : Les mises à jour incrémentales et pourquoi elles comptent.

Surface d’API

Type	Catégorie	Rôle	Stabilité	Depuis
ForensicAnalyzer	classe	Analyse un PDF et renvoie un rapport forensique (analyze statique)	stable	1.10.0
ForensicReport	classe	Le résultat de l’analyse ; JsonSerializable pour l’export SIEM	stable	1.10.0
RevisionSummary	classe	Faits par révision : nombre d’objets, taille, frontières d’octets, indicateurs de présence	stable	1.10.0
ForensicEvent	classe	Un événement classifié avec une liste d’objets affectés	stable	1.10.0
ForensicEventType	enum	Catégories d’événements (signature ajoutée, catalogue mis à jour, objets ajoutés, et autres)	stable	1.10.0
ObjectChange	classe	L’enregistrement de changement d’un objet entre deux révisions	stable	1.10.0
ObjectChangeType	enum	Added, Modified ou Deleted	stable	1.10.0

ForensicReport expose hasIncrementalUpdates(), hasAnySignature(), getEventsByType(), getChangesForRevision() et jsonSerialize(). L’indicateur hasSignature d’un résumé de révision est un signal de présence structurelle, et non un résultat de validité.

Exemple de code — Démarrage rapide

Analyze the revision history of a PDF

<?php

declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

use NextPDF\Enterprise\Forensics\ForensicAnalyzer;

/**
 * Produce a forensic report from PDF bytes.
 *
 * @param string $pdfData Raw PDF file bytes.
 *
 * @return array{revisions: int, incremental: bool, signedRevisionPresent: bool}
 */
function inspect(string $pdfData): array
{
    $report = ForensicAnalyzer::analyze($pdfData);

    return [
        'revisions' => $report->revisionCount,
        'incremental' => $report->hasIncrementalUpdates(),
        'signedRevisionPresent' => $report->hasAnySignature(),
    ];
}

hasAnySignature() rapporte qu’une révision de signature est présente dans la structure. Il n’énonce pas que la signature est valide.

Exemple de code — Production

Forensic analysis with SIEM export and fail-closed handling

<?php

declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

use NextPDF\Enterprise\Forensics\ForensicAnalyzer;
use NextPDF\Enterprise\Forensics\ForensicEventType;
use Psr\Log\LoggerInterface;

final readonly class RevisionAuditor
{
    public function __construct(private LoggerInterface $logger) {}

    /**
     * Analyze a document and emit a structural JSON record for the SIEM.
     *
     * @param string $pdfData The PDF bytes to inspect.
     *
     * @return string A JSON forensic report (no document content).
     */
    public function audit(string $pdfData): string
    {
        try {
            $report = ForensicAnalyzer::analyze($pdfData);

            $this->logger->info('Forensic analysis complete', [
                'revisions' => $report->revisionCount,
                'sizeBytes' => $report->totalSizeBytes,
                'signatureAddedEvents' => count(
                    $report->getEventsByType(ForensicEventType::SignatureAdded),
                ),
            ]);

            return json_encode($report, JSON_THROW_ON_ERROR);
        } catch (\Throwable $e) {
            $this->logger->error('Forensic analysis failed', ['error' => $e->getMessage()]);

            throw $e;
        }
    }
}

L’enregistrement de journal porte uniquement des comptes et des tailles. Il ne porte pas de texte de document. Le bloc catch relance l’exception ; il n’avale pas un échec d’analyse.

Cas limites & pièges

• Un document à révision unique n’a aucun historique incrémental. La liste des changements est vide ; ce n’est pas une preuve d’authenticité.
• Un événement SignatureAdded signifie qu’une révision de signature est structurellement présente. Ce n’est pas un résultat de validité de signature. Valide la signature avec la surface de signature du Core.
• La réutilisation d’objets est normale : un objet mis à jour conserve son numéro d’objet et une nouvelle copie est ajoutée. L’analyseur rapporte cela comme Modified, et non comme une suppression suivie d’une recréation.
• Une classification Deleted est une transition d’entrée libre dans la chaîne de références croisées. Un lecteur peut tout de même résoudre une copie plus ancienne de cet objet ; la suppression au niveau structurel ne garantit pas l’irrécupérabilité.
• L’analyseur rapporte ce que l’analyseur a observé. Un document conçu pour tromper un analyseur peut produire un rapport qui ne correspond pas à la vision d’un autre outil. Le rapport n’est pas une revendication que chaque modification a été détectée.
• L’entrée est bornée. Un document surdimensionné ou comportant un nombre excessif de révisions échoue de manière sûre avec une exception d’analyse typée plutôt que de consommer une mémoire non bornée.

Performance

Le coût de l’analyse évolue avec le nombre de révisions et le nombre d’objets, et non avec la complexité des pages rendues. Le budget de 1500 ms de temps total couvre un document métier typique à révisions multiples. Le profil de reproductibilité est structural : le rapport est déterministe pour une entrée donnée, mais les décalages d’octets absolus reflètent le fichier d’entrée exact et ne sont pas portables entre des copies réenregistrées.

Notes de sécurité

L’analyseur est en lecture seule et n’écrit jamais dans l’entrée. C’est une surface analytique, et non transformationnelle. Il détecte l’existence de marqueurs de signature et de chiffrement mais n’effectue aucune opération cryptographique, de sorte qu’il ne formule aucune revendication FIPS. Un rapport décrit l’historique des mises à jour analysé ; ce n’est pas une affirmation d’authenticité et il ne doit pas être présenté comme inviolable, garanti sur le plan forensique ni recevable en justice. Un opérateur tire des conclusions ; la bibliothèque rapporte la structure.

Résidence des données & mesures d’atténuation des PII

L’analyse s’exécute en mémoire (in-process) sur l’hôte qui détient le PDF. Aucun contenu de document ne quitte l’hôte. Le rapport porte des numéros d’objet, des index de révision, des tailles, des frontières d’octets et des catégories d’événements — des métadonnées structurelles, et non du texte de document ni des données personnelles détectées. Le fait que le PDF d’entrée ou le rapport lui-même contienne des données personnelles, et où chacun est stocké, relève d’une responsabilité de déploiement hors de la frontière de la bibliothèque.

Télémétrie sûre & nettoyage des journaux

La bibliothèque lève des exceptions typées avec des messages structurels et ne place pas d’octets de document dans le texte des exceptions. Un déploiement qui journalise autour de l’analyse devrait journaliser les comptes et les catégories du rapport — comme illustré dans l’exemple de production — et ne doit pas journaliser la charge utile brute du PDF vers les journaux ou un backend APM. Le rapport JSON est l’artefact sûr à transmettre à un SIEM.

Comportement en mode FIPS

Aucune opération cryptographique n’a lieu dans ce module, de sorte qu’il n’y a aucun comportement propre au mode FIPS. La validation de signature, qui est cryptographique, est une capacité distincte du Core et y est documentée.

Conformité

Revendication	Norme	Clause
Les mises à jour ultérieures ajoutent des éléments supplémentaires à la fin du fichier ; la structure originale est modifiée par les mises à jour ultérieures.	ISO 32000-2:2020	§7.5.6
Un objet mis à jour est ajouté comme une nouvelle copie et l’entrée de références croisées de la mise à jour remplace le décalage d’octets antérieur ; le lecteur résout la copie la plus récente.	ISO 32000-2:2020	§7.5.6
La structure initiale du fichier peut être modifiée par des mises à jour ultérieures.	ISO 32000-2:2020	§7.5.4
La section de références croisées d’une mise à jour contient des entrées uniquement pour les objets ajoutés, modifiés ou supprimés.	ISO 32000-2:2020	§7.5.5
Le dictionnaire de signature enregistre ce qui est signé.	ISO 32000-2:2020	§12.8.1
ByteRange définit la plage d’octets que couvre la signature (la validation de signature est une capacité distincte du Core).	ISO 32000-2:2020	§12.8.1
Un Document Security Store contient le matériel de validation à long terme dans une révision ultérieure.	ISO 32000-2:2020	§12.8.4

Toutes les clauses sont paraphrasées. NextPDF ne reproduit pas le texte normatif. Consulte la norme publiée pour la formulation qui fait autorité. NextPDF ne formule aucune revendication de certification forensique ; le rapport décrit la structure des mises à jour analysée, et non une détermination certifiée de l’intégrité du document.

Contrat de comportement

• L’analyseur est en lecture seule : il n’écrit jamais dans le document d’entrée et n’effectue aucune opération cryptographique.
• Il analyse la table de références croisées de chaque révision, dérive les frontières d’octets de révision et classifie chaque objet comme ajouté, modifié ou supprimé, puis regroupe les changements en une chronologie d’événements classifiés.
• Un événement SignatureAdded signifie qu’une révision de signature est structurellement présente ; ce n’est pas un résultat de validité de signature — la validation est une capacité distincte du Core.
• Un document à révision unique a une liste de changements vide (pas une preuve d’authenticité) ; une classification Deleted est une transition d’entrée libre, et non une irrécupérabilité garantie.
• L’entrée est bornée : un document surdimensionné ou comportant un nombre excessif de révisions échoue de manière sûre avec une exception d’analyse typée. Le rapport est une détection de résistance à l’altération telle que testée, et non une garantie forensique ou une attestation recevable en justice.

Frontière de publication

Cette page documente uniquement le comportement observable de l’extérieur et la surface d’API publique prise en charge. Les chemins d’espace de noms internes, les classes utilitaires, les tables de mécanismes, les noms de fichiers de runbook et les préfixes de ticket sont hors périmètre.

Repli sur le Core

NextPDF Core (Apache-2.0) n’a aucun analyseur forensique de l’historique des révisions — aucun ; cette capacité n’a aucun équivalent au palier Core. Le Core fournit la surface de validation de signature faisant autorité, avec laquelle l’analyseur se compose mais qu’il ne remplace pas.

Repli sur Pro

NextPDF Pro n’a aucun analyseur forensique de l’historique des révisions — aucun ; cette capacité n’a aucun équivalent au palier Pro. Le rapport en lecture seule des révisions et des changements par objet ainsi que le rapport JSON-sérialisable pour SIEM sont livrés uniquement dans le paquet nextpdf/enterprise.

Note sur la frontière Enterprise

L’analyseur de révisions, la classification des changements et la chronologie d’événements sont décrits au niveau du comportement. Les détails internes de l’analyseur et tout détail interne de classification sont hors du périmètre de la surface publique. La validité des signatures n’est délibérément pas dans le périmètre ici — elle relève de la responsabilité de la surface de signature du Core.

Frontière de déploiement

L’analyse s’exécute en mémoire (in-process) sur l’hôte qui détient le PDF ; aucun contenu de document ne quitte l’hôte. Le fait que le PDF d’entrée ou le rapport contienne des données personnelles, et où chacun est stocké, relève d’une responsabilité de déploiement hors de la frontière de la bibliothèque. L’opérateur tire des conclusions du rapport ; la bibliothèque rapporte la structure et n’affirme pas l’authenticité du document.

Frontière de conformité légale

Aucune restriction de contrôle des exportations ne s’applique à la surface Forensics. Le rapport ne doit pas être présenté comme inviolable, garanti sur le plan forensique ni recevable en justice. Cette documentation n’est pas un avis juridique ; consulte tes propres conseillers conformité et juridiques.

Voir aussi

• Forensics — Référence approfondie — dérivation des frontières de révision et règles de classification des changements d’objets.
• Signature du Core — la surface de validation de signature faisant autorité.
• Paquets Evidence — artefacts de sortie de chaîne de traçabilité.
• NextPDF Enterprise — la surface complète des fonctionnalités Enterprise.
• Core AST — le modèle de document analysé.
• Mise à jour incrémentale · Table de références croisées · DSS — termes du glossaire.