Nachweise

Auf einen Blick

NextPDF Enterprise setzt dokumentbezogene Validierungsbefunde zu einem versiegelten, unveränderlichen Paket mit einer deterministischen JSON-Form und einem stabilen SHA-256-Digest zusammen, das optional ein RFC-3161-Zeitstempel-Token trägt. Die Evidence-Erfassung unterstützt Audit-Workflows. Sie ist keine rechtliche Bescheinigung, keine Audit-Zertifizierung und kein Nachweis, dass ein Dokument konform ist.

Verfügbarkeit & Lizenzierung

Diese Fähigkeit wird in NextPDF Enterprise (nextpdf/enterprise) ausgeliefert und wird mit einer Lizenzhülle 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

EvidencePortal ist der Einstiegspunkt. generateEvidence($documentHash, $records, $tsaTimestamp) setzt eine Liste von EvidenceRecord-Instanzen zu einem EvidencePackage zusammen, berechnet Pass-/Fail-Statistiken, persistiert das Paket über ein EvidenceStoreInterface und gibt das versiegelte Paket zurück. Ein EvidenceRecord erfasst eine Policy-Prüfung: Policy-Name, Pass-Flag, Details, die Validator-Version, die ihn erzeugt hat, und einen Zeitstempel.

EvidencePackage ist nach der Konstruktion unveränderlich. Es trägt eine Paket-ID, den SHA-256 des validierten Dokuments, die Records, aggregierte Anzahlen, eine Erzeugungszeit und ein optionales RFC-3161-Zeitstempel-Token. allPassed() und passRate() fassen es zusammen. Seine Unveränderlichkeit macht ein Paket für Write-Once-Read-Many-(WORM-)Speicher geeignet.

EvidenceExporter serialisiert ein Paket in eine deterministische JSON-Zeichenkette — feste Schlüsselreihenfolge, reproduzierbar —, sodass exportHash() einen stabilen 64-Zeichen-SHA-256-Digest zur Integritätsprüfung zurückgibt. Dasselbe Paket ergibt stets denselben Digest, unabhängig davon, wann oder wo er berechnet wird.

ContinuousMonitor validiert ein Dokument erneut und vergleicht die aktuelle Evidence anhand des Namens der fehlgeschlagenen Policy mit der gespeicherten vorherigen Evidence, kategorisiert Probleme als neu, behoben oder unverändert und stellt eine Zeitplanprüfung bereit (isDue() / MonitorSchedule / MonitorFrequency). Dies unterstützt die Drift-Erkennung über die Zeit; es meldet, was sich geändert hat, es behauptet zu keinem Zeitpunkt einen Rechtsstatus.

Was „Evidence” hier bedeutet

Dieses Modul verpackt Validierungsbefunde und versieht sie mit Zeitstempeln für Audit-Workflows. Es zertifiziert nichts.

• Ein RFC-3161-Zeitstempel-Token bindet das Paket-Datum an einen Zeitwert: Es liefert den Nachweis, dass die Daten vor diesem Zeitpunkt existierten. Es ist keine rechtliche Bescheinigung, und es behauptet nicht, dass der zeitgestempelte Inhalt konform oder gültig ist.
• Ein versiegeltes Paket mit allPassed() === true erfasst, dass die enthaltenen Prüfungen gegen die Regeln bestanden haben, die sie implementieren. Es ist keine Audit-Zertifizierung.
• Der deterministische Digest beweist die Integrität der Paketbytes. Er beweist nicht die regulatorische Hinlänglichkeit des Dokuments.

Die Evidence-Erfassung unterstützt Audit-Workflows; sie ist keine rechtliche Bescheinigung und keine Audit-Zertifizierung. Gültigkeit und Konformität bleiben Eigenschaften der finalen Datei plus eines Validators.

Stufengrenze

Die Evidence-Paketierung ist eine Enterprise-exklusive Oberfläche. Core und Pro erzeugen Befunde und Berichte; Enterprise Evidence versiegelt diese Befunde zu einem unveränderlichen, deterministischen, optional zeitgestempelten Paket und verfolgt Regressionen. Es hängt von anderswo erzeugten Befunden ab (den Oberflächen Validation oder Compliance); es führt selbst keine Konformitätsprüfungen aus.

Warum es so funktioniert

Evidence ist nur nützlich, wenn sie nicht im Nachhinein stillschweigend umgeschrieben werden kann, daher ist EvidencePackage ein versiegelter readonly-Wert ohne Mutatoren — sicher für Write-Once-Read-Many-Speicher. Die toJson()-Ausgabe des Exporters folgt einer festen Schlüsseleinfügereihenfolge, nicht einer Laufzeitsortierung, sodass dasselbe Paket stets zu identischen Bytes serialisiert. Diese Byte-Stabilität lässt einen gespeicherten exportHash() später die Integrität verifizieren: Jede Änderung am Paket ändert den Digest. Das RFC-3161-Token wird als eingebetteter Zeitnachweis geführt, nie als Urteil, sodass ein Paket belegt, wann eine Prüfung lief, ohne zu behaupten, dass das Dokument konform ist. Die Regressionsverfolgung vergleicht dann anhand des Namens der fehlgeschlagenen Policy mit dem vorherigen Paket, sodass die Drift-Erkennung unabhängig von der Prüfreihenfolge oder -anzahl bleibt.

Designhintergrund: Compliance, die Sie einem Prüfer übergeben können.

API-Oberfläche

Klasse	Verantwortung
EvidencePortal	Evidence-Pakete zusammensetzen, persistieren und abrufen.
EvidencePackage	Unveränderliches versiegeltes Bündel von Records mit aggregierten Statistiken.
EvidenceRecord	Ein Policy-Prüfungsergebnis mit Validator-Version und Zeitstempel.
EvidenceExporter	Deterministische JSON-Serialisierung; stabiler SHA-256-Digest.
EvidenceStoreInterface	Persistenzvertrag.
InMemoryEvidenceStore	Referenzimplementierung des In-Memory-Speichers.
ContinuousMonitor	Erneut validieren und gegen vorherige Evidence vergleichen.
MonitorResult	Kategorisierung in neue / behobene / unveränderte Probleme.
MonitorSchedule / MonitorFrequency	Zeitplanbasiertes Polling.

Codebeispiel — Schnellstart

$package = $portal->generateEvidence($documentHash, $records);
$digest  = $exporter->exportHash($package); // 64-char SHA-256

Codebeispiel — Produktion

$package = $portal->generateEvidence($documentHash, $records, $tsaToken);
$logger->info('evidence.sealed', [
    'package'   => $package->packageId,
    'digest'    => $exporter->exportHash($package),
    'pass_rate' => $package->passRate(),
]);

$delta = $monitor->check($package, $documentHash);
if ($delta->newIssues !== []) {
    $logger->warning('evidence.regression', ['count' => count($delta->newIssues)]);
}
// The package is audit-supporting evidence, not an attestation of compliance.

Sonderfälle und Stolperfallen

• passRate() gibt 0.0 zurück, wenn es keine Befunde gibt; ein leeres Paket ist kein Bestehen.
• Der Export ist nur über EvidenceExporter deterministisch; das Hashen beliebiger Serialisierungen bricht die Stabiler-Digest-Garantie.
• Ein Paket ohne TSA-Token ist weiterhin gültige Evidence; das Token fügt eine Zeitbindung hinzu, kein Urteil.

Performance

Paketierung und deterministische Serialisierung skalieren linear mit der Record-Anzahl. Die Digest-Berechnung ist ein einzelner SHA-256-Durchlauf über das serialisierte JSON.

Sicherheitshinweise

Der Paket-Digest liefert Manipulationssicherheit für die Paketbytes. Das optionale RFC-3161-Token muss von einem vertrauenswürdigen TSA stammen; dieses Modul bettet das Token ein, es bürgt nicht für das TSA. Behandeln Sie Record-Details als potenziell sensibel (siehe unten).

Datenresidenz & PII-Minderungsmaßnahmen

Evidence-Records und Dokumenthashes können auf regulierten Inhalt verweisen. Die Paketierung ist prozessintern; die Persistenz wird an Ihre EvidenceStoreInterface-Implementierung delegiert, sodass die Residenz Ihrem Speicher folgt. Wenden Sie Aufbewahrungs- und Minimierungskontrollen auf gespeicherte Pakete an.

Sichere Telemetrie & Log-Schwärzung

Paket-Metadaten (IDs, Digests, Anzahlen) sind sicher zu protokollieren. Record-Details können Befundmeldungen widerspiegeln, die extrahierte Dokumentzeichenketten enthalten; schwärzen Sie diese, bevor Sie sie an gemeinsame Senken weiterleiten.

Konformität

Verhalten	Referenz	Status
Zeitstempel-Token bindet ein Datum an eine Zeit	IETF RFC 3161 §2	Token eingebettet (TSA-bereitgestellt)
DSS-/Langzeitvalidierungskontext	ISO 32000-2:2020 §12.8	Referenziert (hier konsumiert, nicht erzeugt)

Diese Tabelle erfasst die Spezifikationen, gegen die dieses Modul gebaut ist. Ein Zeitstempel-Token ist ein Zeitnachweis, keine Zertifizierung und keine rechtliche Bescheinigung.

FIPS-Modus-Verhalten

Dieses Modul berechnet SHA-256 über die Paketbytes und bettet ein vom Aufrufer bereitgestelltes RFC-3161-Token ein. Es führt kein Signieren und keine Schlüsselverwahrung aus; kryptografische Operationen und das FIPS-Modus-Verhalten werden von den Modulen Security und Signature übernommen.

Bedrohungsmodell

Die Eingaben sind Befunde und ein optionales TSA-Token. Mitigationen: unveränderliche Pakete, deterministische Serialisierung mit einem stabilen Integritäts-Digest und delegierte Persistenz, sodass der Speicher WORM und Zugriffskontrolle durchsetzt.

Verhaltensvertrag

• Das Portal setzt Befunde zu einem unveränderlichen, versiegelten Paket mit einer Paket-ID, dem SHA-256 des validierten Dokuments, Records, aggregierten Anzahlen, einer Erzeugungszeit und einem optionalen RFC-3161-Zeitstempel-Token zusammen.
• Der Exporter serialisiert ein Paket in eine deterministische JSON-Zeichenkette mit fester Schlüsselreihenfolge, sodass der Digest ein stabiler 64-Zeichen-SHA-256 ist, identisch unabhängig davon, wann oder wo er berechnet wird.
• Der Continuous Monitor validiert erneut und vergleicht die aktuelle Evidence anhand des Namens der fehlgeschlagenen Policy mit der gespeicherten vorherigen Evidence und kategorisiert Probleme als neu, behoben oder unverändert.
• passRate() gibt 0.0 zurück, wenn es keine Befunde gibt — ein leeres Paket ist kein Bestehen; ein Paket ohne TSA-Token ist weiterhin gültige Evidence.
• Ein Zeitstempel-Token ist ein Nachweis, dass die Daten vor einem Zeitpunkt existierten; es ist keine rechtliche Bescheinigung und erhebt keinen Anspruch über die Konformität oder Gültigkeit des Inhalts.

Veröffentlichungsgrenze

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

Core und Pro erzeugen Befunde und Berichte; das Versiegeln dieser Befunde zu einem unveränderlichen, deterministischen, optional zeitgestempelten Paket mit Regressionsverfolgung hat kein Core-Stufen-Äquivalent. Die Enterprise-Oberfläche hängt von anderswo erzeugten Befunden ab; sie führt selbst keine Konformitätsprüfungen aus.

Pro-Fallback

Pro-Fallback — keiner; diese Fähigkeit hat kein Pro-Stufen-Äquivalent. Das versiegelte Evidence-Paket, der deterministische Exporter und der Continuous Monitor werden ausschließlich im Paket nextpdf/enterprise ausgeliefert; die Oberfläche konsumiert Befunde von den Oberflächen Validation oder Compliance.

Hinweis zur Enterprise-Grenze

Das Portal, das Paket, der Exporter und der Monitor werden auf Verhaltensebene beschrieben. Der Referenz-In-Memory-Speicher ist dokumentiert; die dauerhafte Persistenz wird vom Host bereitgestellt, und etwaige interne Speicherinterna liegen außerhalb des Geltungsbereichs der öffentlichen Oberfläche. Dieses Modul bettet ein vom Aufrufer bereitgestelltes TSA-Token ein; es bürgt nicht für das TSA.

Bereitstellungsgrenze

Paketierung und Serialisierung sind prozessintern. Der Betreiber stellt eine dauerhafte Speicherimplementierung bereit, ist für die WORM-Durchsetzung und Zugriffskontrolle verantwortlich und stellt ein TSA-Token von einem vertrauenswürdigen TSA bereit. Evidence-Records und Dokumenthashes können auf regulierten Inhalt verweisen; die Residenz folgt dem Speicher des Betreibers, und Aufbewahrungs- und Minimierungskontrollen liegen in der Verantwortung des Betreibers.

Rechtliche Compliance-Grenze

Die Evidence-Erfassung unterstützt Audit-Workflows; sie ist keine rechtliche Bescheinigung und keine Audit-Zertifizierung, und Gültigkeit und Konformität bleiben Eigenschaften der finalen Datei plus eines Validators. Diese Dokumentation ist kein Rechtsgutachten; konsultieren Sie Ihre eigenen Compliance- und Rechtsberater.

Siehe auch

• Validation — erzeugt die hier verpackten Befunde.
• Compliance — externe Validator-Ergebnisse.
• AST-Audit-Trail — nur anfügbare Mutationshistorie.
• Specifications: PAdES — Langzeitvalidierungskontext.
• Evidence — Deep Reference — vollständige klassenbasierte API-Referenz.