Forensik

Auf einen Blick

NextPDF Enterprise Forensics liest die Inkrementelle-Aktualisierung-Historie eines PDF und erzeugt einen strukturierten, schreibgeschützten Bericht über Revisionen, klassifizierte Ereignisse und Änderungen pro Objekt. Es unterstützt forensische Analyse-Workflows. Es ist keine manipulationssichere Versiegelung und behauptet nicht, dass ein Dokument authentisch oder unverändert ist.

Verfügbarkeit und Lizenzierung

Diese Fähigkeit wird in NextPDF Enterprise (nextpdf/enterprise) ausgeliefert und wird mit einem Lizenz-Envelope der Enterprise-Stufe aktiviert. Eine Bereitstellung ohne diese Berechtigung lädt die Klassen der Fähigkeit nicht. Editionen vergleichen und Lizenz erwerben.

Installation

composer require nextpdf/enterprise:^3

Konzeptioneller Überblick

Ein PDF kann aktualisiert werden, indem Änderungen ans Ende der Datei angehängt werden, statt sie neu zu schreiben. Jede Aktualisierung fügt eine neue Querverweissektion und einen neuen Trailer hinzu, und die ursprünglichen Bytes bleiben an Ort und Stelle — ISO 32000-2:2020 §7.5.6. Wenn ein Objekt geändert wird, hängt die Aktualisierung eine neue Kopie an, und die Querverweissektion der Aktualisierung erfasst einen Byte-Offset, der den älteren Offset überschreibt; ein Leser löst die jüngste Kopie auf — ISO 32000-2:2020 §7.5.6. Die anfängliche Dateistruktur kann durch spätere Aktualisierungen modifiziert werden — ISO 32000-2:2020 §7.5.4. Die Querverweissektion einer Aktualisierung listet nur die Objekte auf, die in dieser Aktualisierung hinzugefügt, modifiziert oder gelöscht wurden — ISO 32000-2:2020 §7.5.5.

Der Analysator liest diese geschichtete Struktur. Er parst die Querverweistabelle jeder Revision, leitet die Byte-Grenzen der Revisionen ab und vergleicht die Einträge jeder Revision mit der nächstälteren Revision, um jedes Objekt als hinzugefügt, modifiziert oder gelöscht zu klassifizieren. Anschließend gruppiert er Objektänderungen zu übergeordneten Ereignissen: Eine Signatur wurde hinzugefügt, der Dokumentkatalog wurde aktualisiert, ein Verschlüsselungs-Dictionary erschien, oder eine Menge von Objekten wurde hinzugefügt, modifiziert oder entfernt. Die Ausgabe ist ein Berichtsobjekt, das eine Revisionsanzahl, die Gesamtgröße, eine Zusammenfassungsliste pro Revision, eine klassifizierte Ereignis-Timeline und die Änderungsliste pro Objekt trägt.

Der Analysator ist schreibgeschützt. Er erkennt das Vorhandensein einer Signaturrevision anhand struktureller Marker; er validiert keine Signatur, berechnet keinen Digest neu und prüft kein Zertifikat. Die Signaturvalidierung ist eine separate Core-Fähigkeit. Ein erzeugter Bericht ist eine strukturelle Beschreibung der Aktualisierungshistorie wie geparst; er ist keine Feststellung, dass ein Dokument authentisch ist, dass eine Änderung unbefugt war oder dass jede Modifikation erkannt wurde. Behandeln Sie den Bericht als Manipulationsnachweis-Erkennung, wie sie gegen die Sicht des Parsers auf die Revisionskette getestet wurde, nicht als forensische Garantie oder gerichtsverwertbare Bescheinigung.

Warum es so funktioniert

Der Analysator hält bewusst bei der Struktur an. Er meldet, was die Revisionskette enthält, und behauptet nie, dass eine Änderung befugt oder eine Signatur gültig war. Strukturelles Vorhandensein und kryptografische Gültigkeit sind unterschiedliche Aussagen; sie zu verschmelzen würde einen Aufrufer einen Manipulationsnachweis mit einer Garantie verwechseln lassen. Die Signaturgültigkeit verbleibt daher bei der einzigen Core-Signieroberfläche, mit der sich Forensics zusammensetzt, statt sie zu duplizieren. Der Bericht besteht aus JSON-serialisierbaren strukturellen Metadaten, sodass ein SIEM die Bearbeitungshistorie aufnimmt, ohne Dokumenteninhalt zu berühren. Designhintergrund: Inkrementelle Aktualisierungen und warum sie wichtig sind.

API-Oberfläche

Type	Kind	Role	Stability	Since
ForensicAnalyzer	class	Parst ein PDF und gibt einen forensischen Bericht zurück (static analyze)	stable	1.10.0
ForensicReport	class	Das Analyseergebnis; JsonSerializable für SIEM-Export	stable	1.10.0
RevisionSummary	class	Fakten pro Revision: Objektanzahl, Größe, Byte-Grenzen, Vorhandensein-Flags	stable	1.10.0
ForensicEvent	class	Ein klassifiziertes Ereignis mit einer Liste betroffener Objekte	stable	1.10.0
ForensicEventType	enum	Ereigniskategorien (Signatur hinzugefügt, Katalog aktualisiert, Objekte hinzugefügt und andere)	stable	1.10.0
ObjectChange	class	Der Änderungseintrag eines Objekts über zwei Revisionen hinweg	stable	1.10.0
ObjectChangeType	enum	Added, Modified oder Deleted	stable	1.10.0

ForensicReport stellt hasIncrementalUpdates(), hasAnySignature(), getEventsByType(), getChangesForRevision() und jsonSerialize() bereit. Das hasSignature-Flag auf einer Revisionszusammenfassung ist ein strukturelles Vorhandensein-Signal, kein Gültigkeitsergebnis.

Codebeispiel — Schnellstart

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() meldet, dass eine Signaturrevision in der Struktur vorhanden ist. Es gibt nicht an, dass die Signatur gültig ist.

Codebeispiel — Produktion

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

Der Protokolleintrag trägt nur Anzahlen und Größen. Er trägt keinen Dokumenttext. Der Catch-Block wirft erneut; er verschluckt keinen Parse-Fehler.

Sonderfälle und Stolperfallen

• Ein Dokument mit einer einzigen Revision hat keine inkrementelle Historie. Die Änderungsliste ist leer; dies ist kein Authentizitätsnachweis.
• Ein SignatureAdded-Ereignis bedeutet, dass eine Signaturrevision strukturell vorhanden ist. Es ist kein Signaturgültigkeitsergebnis. Validieren Sie die Signatur mit der Core-Signieroberfläche.
• Objektwiederverwendung ist normal: Ein aktualisiertes Objekt behält seine Objektnummer, und eine neue Kopie wird angehängt. Der Analysator meldet dies als Modified, nicht als Entfernung und Neuerstellung.
• Eine Deleted-Klassifizierung ist ein Free-Entry-Übergang in der Querverweiskette. Ein Leser kann weiterhin eine ältere Kopie dieses Objekts auflösen; das Löschen auf Strukturebene ist keine garantierte Nichtwiederherstellbarkeit.
• Der Analysator meldet, was der Parser beobachtet hat. Ein Dokument, das darauf ausgelegt ist, einen Parser zu verwirren, kann einen Bericht ergeben, der nicht der Sicht eines anderen Werkzeugs entspricht. Der Bericht ist kein Anspruch, dass jede Modifikation erkannt wurde.
• Die Eingabe ist begrenzt. Ein überdimensioniertes oder übermäßig vielrevisioniges Dokument scheitert fail-closed mit einer typisierten Parse-Ausnahme, statt unbegrenzten Speicher zu verbrauchen.

Performance

Die Analysekosten skalieren mit der Revisionsanzahl und der Objektanzahl, nicht mit der gerenderten Seitenkomplexität. Das Wall-Budget von 1500 ms deckt ein typisches mehrrevisioniges Geschäftsdokument ab. Das Reproduzierbarkeitsprofil ist structural: Der Bericht ist für eine gegebene Eingabe deterministisch, aber absolute Byte-Offsets spiegeln die exakte Eingabedatei wider und sind nicht über neu gespeicherte Kopien hinweg portierbar.

Sicherheitshinweise

Der Analysator ist schreibgeschützt und schreibt niemals in die Eingabe. Er ist eine analytische, keine transformierende Oberfläche. Er erkennt das Vorhandensein von Signatur- und Verschlüsselungsmarkern, führt jedoch keine kryptografische Operation aus und erhebt daher keinen FIPS-Anspruch. Ein Bericht beschreibt die geparste Aktualisierungshistorie; er ist keine Authentizitätsbehauptung und darf nicht als manipulationssicher, forensisch garantiert oder gerichtsverwertbar dargestellt werden. Ein Betreiber zieht Schlüsse; die Bibliothek meldet die Struktur.

Datenresidenz & PII-Minderungen

Die Analyse läuft prozessintern auf dem Host, der das PDF hält. Kein Dokumenteninhalt verlässt den Host. Der Bericht trägt Objektnummern, Revisionsindizes, Größen, Byte-Grenzen und Ereigniskategorien — strukturelle Metadaten, keinen Dokumenttext und keine erkannten personenbezogenen Daten. Ob das Eingabe-PDF oder der Bericht selbst personenbezogene Daten enthält und wo jedes gespeichert wird, ist eine Bereitstellungsverantwortung außerhalb der Bibliotheksgrenze.

Sichere Telemetrie & Log-Bereinigung

Die Bibliothek löst typisierte Ausnahmen mit strukturellen Meldungen aus und legt keine Dokumentbytes in den Ausnahmetext. Eine Bereitstellung, die rund um die Analyse protokolliert, sollte die Anzahlen und Kategorien des Berichts protokollieren — wie im Produktionsbeispiel gezeigt — und darf die rohe PDF-Nutzlast nicht in Protokolle oder ein APM-Backend protokollieren. Der JSON-Bericht ist das sichere Artefakt zur Weiterleitung an ein SIEM.

Verhalten im FIPS-Modus

In diesem Modul findet keine kryptografische Operation statt, sodass es kein FIPS-modus-spezifisches Verhalten gibt. Die Signaturvalidierung, die kryptografisch ist, ist eine separate Core-Fähigkeit und ist dort dokumentiert.

Konformität

Claim	Standard	Clause
Spätere Aktualisierungen hängen zusätzliche Elemente ans Ende der Datei an; die ursprüngliche Struktur wird durch spätere Aktualisierungen modifiziert.	ISO 32000-2:2020	§7.5.6
Ein aktualisiertes Objekt wird als neue Kopie angehängt, und der Querverweiseintrag der Aktualisierung überschreibt den vorherigen Byte-Offset; der Leser löst die jüngste Kopie auf.	ISO 32000-2:2020	§7.5.6
Die anfängliche Dateistruktur kann durch spätere Aktualisierungen modifiziert werden.	ISO 32000-2:2020	§7.5.4
Die Querverweissektion einer Aktualisierung enthält nur Einträge für hinzugefügte, modifizierte oder gelöschte Objekte.	ISO 32000-2:2020	§7.5.5
Das Signatur-Dictionary erfasst, was signiert wird.	ISO 32000-2:2020	§12.8.1
ByteRange definiert die Byte-Spanne, die die Signatur abdeckt (die Signaturvalidierung ist eine separate Core-Fähigkeit).	ISO 32000-2:2020	§12.8.1
Ein Document Security Store hält langfristiges Validierungsmaterial in einer späteren Revision vor.	ISO 32000-2:2020	§12.8.4

Alle Klauseln sind paraphrasiert. NextPDF gibt keinen normativen Text wieder. Konsultieren Sie den veröffentlichten Standard für die maßgebliche Formulierung. NextPDF erhebt keinen forensischen Zertifizierungsanspruch; der Bericht beschreibt die geparste Aktualisierungsstruktur, keine zertifizierte Feststellung der Dokumentintegrität.

Verhaltensvertrag

• Der Analysator ist schreibgeschützt: Er schreibt niemals in das Eingabedokument und führt keine kryptografische Operation aus.
• Er parst die Querverweistabelle jeder Revision, leitet die Byte-Grenzen der Revisionen ab und klassifiziert jedes Objekt als hinzugefügt, modifiziert oder gelöscht und gruppiert die Änderungen dann zu einer klassifizierten Ereignis-Timeline.
• Ein SignatureAdded-Ereignis bedeutet, dass eine Signaturrevision strukturell vorhanden ist; es ist kein Signaturgültigkeitsergebnis — die Validierung ist eine separate Core-Fähigkeit.
• Ein Dokument mit einer einzigen Revision hat eine leere Änderungsliste (kein Authentizitätsnachweis); eine Deleted-Klassifizierung ist ein Free-Entry-Übergang, keine garantierte Nichtwiederherstellbarkeit.
• Die Eingabe ist begrenzt: Ein überdimensioniertes oder übermäßig vielrevisioniges Dokument scheitert fail-closed mit einer typisierten Parse-Ausnahme. Der Bericht ist Manipulationsnachweis-Erkennung wie getestet, keine forensische Garantie oder gerichtsverwertbare Bescheinigung.

Publikationsgrenze

Diese Seite dokumentiert ausschließlich extern beobachtbares Verhalten und die unterstützte öffentliche API-Oberfläche. Interne Namespace-Pfade, Hilfsklassen, Mechanismustabellen, Runbook-Dateinamen und Ticket-Präfixe liegen außerhalb des Geltungsbereichs.

Core-Fallback

NextPDF Core (Apache-2.0) hat keinen Revisionshistorie-Forensikanalysator — keinen; diese Fähigkeit hat kein Core-Stufen-Äquivalent. Core liefert die maßgebliche Signaturvalidierungsoberfläche, mit der sich der Analysator zusammensetzt, die er aber nicht ersetzt.

Pro-Fallback

NextPDF Pro hat keinen Revisionshistorie-Forensikanalysator — keinen; diese Fähigkeit hat kein Pro-Stufen-Äquivalent. Die schreibgeschützte Revisions- und Pro-Objekt-Änderungsmeldung und der JSON-serialisierbare SIEM-Bericht werden ausschließlich im Paket nextpdf/enterprise ausgeliefert.

Hinweis zur Enterprise-Grenze

Der Revisionsparser, die Änderungsklassifizierung und die Ereignis-Timeline werden auf Verhaltensebene beschrieben. Die Parser-Interna und jegliches interne Klassifizierungsdetail liegen außerhalb des Geltungsbereichs der öffentlichen Oberfläche. Die Signaturgültigkeit liegt hier bewusst nicht im Geltungsbereich — sie ist die Verantwortung der Core-Signieroberfläche.

Bereitstellungsgrenze

Die Analyse läuft prozessintern auf dem Host, der das PDF hält; kein Dokumenteninhalt verlässt den Host. Ob das Eingabe-PDF oder der Bericht personenbezogene Daten enthält und wo jedes gespeichert wird, ist eine Bereitstellungsverantwortung außerhalb der Bibliotheksgrenze. Der Betreiber zieht Schlüsse aus dem Bericht; die Bibliothek meldet die Struktur und behauptet keine Dokumentauthentizität.

Rechtliche Compliance-Grenze

Für die Forensics-Oberfläche gilt keine exportkontrollrechtliche Beschränkung. Der Bericht darf nicht als manipulationssicher, forensisch garantiert oder gerichtsverwertbar dargestellt werden. Diese Dokumentation ist kein Rechtsgutachten; konsultieren Sie Ihre eigenen Compliance- und Rechtsberater.

Siehe auch

• Forensik — Deep Reference — Ableitung der Revisionsgrenzen und Regeln zur Objektänderungsklassifizierung.
• Core signing — die maßgebliche Signaturvalidierungsoberfläche.
• Evidence-Bündel — Chain-of-Custody-Ausgabeartefakte.
• NextPDF Enterprise — die vollständige Enterprise-Funktionsoberfläche.
• Core AST — das geparste Dokumentmodell.
• Incremental update · Cross-reference table · DSS — Glossarbegriffe.