Enterprise edizione

Analisi forense

In sintesi

NextPDF Enterprise Forensics legge la cronologia degli aggiornamenti incrementali di un PDF e produce un report strutturato e in sola lettura di revisioni, eventi classificati e modifiche per ciascun oggetto. Supporta i flussi di lavoro di analisi forense. Non è un sigillo a prova di manomissione e non asserisce che un documento sia autentico o non alterato.

Disponibilità e licenza

Questa funzionalità è inclusa in NextPDF Enterprise (nextpdf/enterprise) e si attiva con un envelope di licenza di livello Enterprise. Una distribuzione priva di tale autorizzazione non carica le classi della funzionalità. Confronta le edizioni e ottieni una licenza.

Installazione

composer require nextpdf/enterprise:^3

Panoramica concettuale

Un PDF può essere aggiornato aggiungendo le modifiche alla fine del file anziché riscrivendolo. Ogni aggiornamento aggiunge una nuova sezione di cross-reference e un nuovo trailer, e i byte originali restano al loro posto — ISO 32000-2:2020 §7.5.6. Quando un oggetto viene modificato, l’aggiornamento aggiunge una nuova copia e la sezione di cross-reference dell’aggiornamento registra un byte offset che sovrascrive l’offset precedente; un lettore risolve la copia più recente — ISO 32000-2:2020 §7.5.6. La struttura iniziale del file può essere modificata da aggiornamenti successivi — ISO 32000-2:2020 §7.5.4. La sezione di cross-reference di un aggiornamento elenca solo gli oggetti che sono stati aggiunti, modificati o eliminati in quell’aggiornamento — ISO 32000-2:2020 §7.5.5.

L’analizzatore legge questa struttura a strati. Effettua il parsing della tabella di cross-reference di ciascuna revisione, deriva i confini in byte delle revisioni e confronta le voci di ciascuna revisione con quelle della revisione immediatamente precedente per classificare ogni oggetto come aggiunto, modificato o eliminato. Quindi raggruppa le modifiche degli oggetti in eventi di livello superiore: è stata aggiunta una firma, il catalogo del documento è stato aggiornato, è comparso un dizionario di cifratura, oppure un insieme di oggetti è stato aggiunto, modificato o rimosso. L’output è un unico oggetto report che trasporta un conteggio delle revisioni, la dimensione totale, un elenco riepilogativo per ciascuna revisione, una cronologia di eventi classificati e l’elenco delle modifiche per ciascun oggetto.

L’analizzatore è in sola lettura. Rileva l’esistenza di una revisione di firma da marcatori strutturali; non convalida alcuna firma, non ricalcola alcun digest e non verifica alcun certificato. La convalida della firma è una capacità di Core separata. Un report prodotto è una descrizione strutturale della cronologia degli aggiornamenti così come è stata sottoposta a parsing; non è una determinazione che un documento sia autentico, che una modifica sia stata non autorizzata o che ogni modifica sia stata rilevata. Trattare il report come un rilevamento della rilevabilità delle manomissioni testato rispetto alla visione che il parser ha della catena di revisioni, non come una garanzia forense o un’attestazione ammissibile in giudizio.

Perché funziona così

L’analizzatore si ferma deliberatamente alla struttura. Riporta ciò che la catena di revisioni contiene e non asserisce mai che una modifica sia stata autorizzata o che una firma sia valida. La presenza strutturale e la validità crittografica sono affermazioni distinte; unirle consentirebbe a un chiamante di scambiare la rilevabilità delle manomissioni per una garanzia. La validità della firma resta perciò affidata all’unica superficie di firma di Core, con cui Forensics si compone anziché duplicarla. Il report è metadato strutturale JSON-serializzabile, così un SIEM acquisisce la cronologia delle modifiche senza toccare il contenuto del documento. Contesto di progettazione: Aggiornamenti incrementali e perché sono importanti.

Superficie API

Tipo	Genere	Ruolo	Stabilità	Da
`ForensicAnalyzer`	class	Effettua il parsing di un PDF e restituisce un report forense (metodo statico `analyze`)	stable	1.10.0
`ForensicReport`	class	Il risultato dell’analisi; `JsonSerializable` per l’esportazione SIEM	stable	1.10.0
`RevisionSummary`	class	Fatti per ciascuna revisione: numero di oggetti, dimensione, confini in byte, flag di presenza	stable	1.10.0
`ForensicEvent`	class	Un evento classificato con un elenco degli oggetti interessati	stable	1.10.0
`ForensicEventType`	enum	Categorie di eventi (firma aggiunta, catalogo aggiornato, oggetti aggiunti e altri)	stable	1.10.0
`ObjectChange`	class	Il record di modifica di un oggetto tra due revisioni	stable	1.10.0
`ObjectChangeType`	enum	Added, Modified o Deleted	stable	1.10.0

ForensicReport espone hasIncrementalUpdates(), hasAnySignature(), getEventsByType(), getChangesForRevision() e jsonSerialize(). Il flag hasSignature su un riepilogo di revisione è un segnale di presenza strutturale, non un risultato di validità.

Esempio di codice — Avvio rapido

<?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() riporta che una revisione di firma è presente nella struttura. Non dichiara che la firma sia valida.

Esempio di codice — Produzione

<?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;
        }
    }
}

Il record di log trasporta solo conteggi e dimensioni. Non trasporta testo del documento. Il blocco catch rilancia; non assorbe un errore di parsing.

Casi limite e insidie

Un documento a revisione singola non ha alcuna cronologia incrementale. L’elenco delle modifiche è vuoto; ciò non è una prova di autenticità.
Un evento SignatureAdded significa che una revisione di firma è strutturalmente presente. Non è un risultato di validità della firma. Convalidare la firma con la superficie di firma di Core.
Il riutilizzo degli oggetti è normale: un oggetto aggiornato mantiene il proprio numero di oggetto e viene aggiunta una nuova copia. L’analizzatore lo riporta come Modified, non come rimozione e ricreazione.
Una classificazione Deleted è una transizione a voce libera nella catena di cross-reference. Un lettore può comunque risolvere una copia più vecchia di quell’oggetto; l’eliminazione a livello di struttura non garantisce l’irrecuperabilità.
L’analizzatore riporta ciò che il parser ha osservato. Un documento costruito ad arte per confondere un parser può produrre un report che non corrisponde alla visione di un altro strumento. Il report non è un’affermazione che ogni modifica sia stata rilevata.
L’input è delimitato. Un documento sovradimensionato o con un numero eccessivo di revisioni fallisce in modo chiuso con un’eccezione di parsing tipizzata anziché consumare memoria illimitata.

Prestazioni

Il costo dell’analisi cresce con il numero di revisioni e con il numero di oggetti, non con la complessità delle pagine renderizzate. Il budget wall di 1500 ms copre un tipico documento aziendale a più revisioni. Il profilo di riproducibilità è structural: il report è deterministico per un dato input, ma i byte offset assoluti riflettono il file di input esatto e non sono portabili tra copie risalvate.

Note di sicurezza

L’analizzatore è in sola lettura e non scrive mai sull’input. È una superficie analitica, non trasformativa. Rileva l’esistenza di marcatori di firma e di cifratura ma non esegue alcuna operazione crittografica, perciò non avanza alcuna rivendicazione FIPS. Un report descrive la cronologia degli aggiornamenti sottoposta a parsing; non è un’asserzione di autenticità e non deve essere presentato come a prova di manomissione, garantito forensicamente o ammissibile in giudizio. È un operatore a trarre conclusioni; la libreria riporta la struttura.

Residenza dei dati e mitigazioni dei dati personali (PII)

L’analisi viene eseguita in-process sull’host che detiene il PDF. Nessun contenuto del documento lascia l’host. Il report trasporta numeri di oggetto, indici di revisione, dimensioni, confini in byte e categorie di eventi — metadati strutturali, non testo del documento né dati personali rilevati. Il fatto che il PDF di input o il report stesso contenga dati personali, e dove ciascuno sia memorizzato, è una responsabilità di distribuzione al di fuori del confine della libreria.

Telemetria sicura e sanificazione dei log

La libreria solleva eccezioni tipizzate con messaggi strutturali e non inserisce byte del documento nel testo delle eccezioni. Una distribuzione che registra attorno all’analisi dovrebbe registrare i conteggi e le categorie del report — come mostrato nell’esempio di produzione — e non deve registrare il payload PDF grezzo nei log o in un backend APM. Il report JSON è l’artefatto sicuro da inoltrare a un SIEM.

Comportamento in modalità FIPS

In questo modulo non avviene alcuna operazione crittografica, perciò non vi è alcun comportamento specifico della modalità FIPS. La convalida della firma, che è crittografica, è una capacità di Core separata ed è documentata in quella sede.

Conformità

Dichiarazione	Standard	Clausola
Gli aggiornamenti successivi aggiungono elementi ulteriori alla fine del file; la struttura originale è modificata dagli aggiornamenti successivi.	ISO 32000-2:2020	§7.5.6
Un oggetto aggiornato viene aggiunto come una nuova copia e la voce di cross-reference dell’aggiornamento sovrascrive il byte offset precedente; il lettore risolve la copia più recente.	ISO 32000-2:2020	§7.5.6
La struttura iniziale del file può essere modificata da aggiornamenti successivi.	ISO 32000-2:2020	§7.5.4
La sezione di cross-reference di un aggiornamento contiene voci solo per gli oggetti aggiunti, modificati o eliminati.	ISO 32000-2:2020	§7.5.5
Il dizionario della firma registra ciò che è firmato.	ISO 32000-2:2020	§12.8.1
ByteRange definisce l’intervallo di byte che la firma copre (la convalida della firma è una capacità di Core separata).	ISO 32000-2:2020	§12.8.1
Un Document Security Store contiene il materiale di convalida a lungo termine in una revisione successiva.	ISO 32000-2:2020	§12.8.4

Tutte le clausole sono parafrasate. NextPDF non riproduce il testo normativo. Consultare lo standard pubblicato per la formulazione autorevole. NextPDF non avanza alcuna rivendicazione di certificazione forense; il report descrive la struttura degli aggiornamenti sottoposta a parsing, non una determinazione certificata dell’integrità del documento.

Contratto di comportamento

L’analizzatore è in sola lettura: non scrive mai sul documento di input e non esegue alcuna operazione crittografica.
Effettua il parsing della tabella di cross-reference di ciascuna revisione, deriva i confini in byte delle revisioni e classifica ogni oggetto come aggiunto, modificato o eliminato, quindi raggruppa le modifiche in una cronologia di eventi classificati.
Un evento SignatureAdded significa che una revisione di firma è strutturalmente presente; non è un risultato di validità della firma — la convalida è una capacità di Core separata.
Un documento a revisione singola ha un elenco delle modifiche vuoto (non una prova di autenticità); una classificazione Deleted è una transizione a voce libera, non un’irrecuperabilità garantita.
L’input è delimitato: un documento sovradimensionato o con un numero eccessivo di revisioni fallisce in modo chiuso con un’eccezione di parsing tipizzata. Il report è un rilevamento della rilevabilità delle manomissioni così come testato, non una garanzia forense o un’attestazione ammissibile in giudizio.

Confine di pubblicazione

Questa pagina documenta solo il comportamento osservabile dall’esterno e la superficie API pubblica supportata. I percorsi di namespace interni, le classi helper, le tabelle dei meccanismi, i nomi di file di runbook e i prefissi di ticket sono fuori ambito.

Fallback di Core

NextPDF Core (Apache-2.0) non dispone di alcun analizzatore forense della cronologia delle revisioni — nessuno; questa capacità non ha un equivalente a livello Core. Core fornisce la superficie autorevole di convalida della firma, con cui l’analizzatore si compone ma che non sostituisce.

Fallback di Pro

NextPDF Pro non dispone di alcun analizzatore forense della cronologia delle revisioni — nessuno; questa capacità non ha un equivalente a livello Pro. Il reporting in sola lettura delle revisioni e delle modifiche per ciascun oggetto e il report SIEM JSON-serializzabile sono inclusi esclusivamente nel pacchetto nextpdf/enterprise.

Nota sul confine Enterprise

Il parser delle revisioni, la classificazione delle modifiche e la cronologia degli eventi sono descritti a livello di comportamento. I dettagli interni del parser ed eventuali dettagli interni di classificazione sono fuori ambito per la superficie pubblica. La validità della firma è deliberatamente fuori ambito qui — è responsabilità della superficie di firma di Core.

Confine di distribuzione

L’analisi viene eseguita in-process sull’host che detiene il PDF; nessun contenuto del documento lascia l’host. Il fatto che il PDF di input o il report contenga dati personali, e dove ciascuno sia memorizzato, è una responsabilità di distribuzione al di fuori del confine della libreria. L’operatore trae conclusioni dal report; la libreria riporta la struttura e non asserisce l’autenticità del documento.

Confine di conformità legale

Nessuna restrizione di controllo delle esportazioni si applica alla superficie Forensics. Il report non deve essere presentato come a prova di manomissione, garantito forensicamente o ammissibile in giudizio. Questa documentazione non è un parere legale; consultare i propri consulenti di conformità e legali.

Vedere anche

Analisi forense — Riferimento approfondito — derivazione dei confini di revisione e regole di classificazione delle modifiche degli oggetti.
Core signing — la superficie autorevole di convalida della firma.
Evidence bundles — artefatti di output con catena di custodia.
NextPDF Enterprise — l’intera superficie di funzionalità Enterprise.
Core AST — il modello del documento sottoposto a parsing.
Incremental update · Cross-reference table · DSS — termini del glossario.