Zum Inhalt springen

Trust Center

Dies ist das Trust Center der NextPDF-Kern-Engine. Es dient als Einstiegspunkt zu vier Dokumenten: dem Engine-Bedrohungsmodell, dem Sicherheitsmodell für Signatur und Verschlüsselung, dem Datenverarbeitungsverhalten und PII und der Richtlinie zur Schwachstellenoffenlegung. Jede Seite beschreibt einen bestimmten Aspekt davon, wie sich die Bibliothek verhält und wo die Verantwortung der Bibliothek endet und die des Deployments beginnt.

Grenze. Diese Seite und die von ihr verlinkten Seiten beschreiben die Engineering-Haltung: die Designentscheidungen, Standardwerte und Schutzmaßnahmen, die in die Kern-Engine eingebaut und durch ihre eigene Test-Suite verifiziert sind. Sie sind keine Zertifizierung, kein Auditbericht und keine rechtliche Gewährleistung. Keine Aussage hier behauptet, dass die Bibliothek in Ihrem Deployment „sicher“ ist. Sicherheit ist eine Eigenschaft des gesamten Systems – Ihrer Schlüsselverwaltung, Ihrer Verifizierungsrichtlinie, Ihres Netzwerks und Ihrer betrieblichen Praktiken –, nicht einer einzelnen Abhängigkeit.

Die hier beschriebene Trust-Haltung gilt für die Kern-Engine:

Terminal-Fenster
composer require nextpdf/core:^3

Für das Lesen dieser Seiten ist kein zusätzliches Paket erforderlich. Die darin beschriebenen Verhaltensweisen werden durch die Kern-Test-Suite geprüft, die im selben Paket ausgeliefert wird.

Das Trust Center folgt dem Prinzip, dass eine Dokumentationsseite sowohl angeben muss, was die Engine tut, als auch, was sie nicht zusichert. Die vier Unterseiten gliedern diesen Bereich:

  • Bedrohungsmodell – die Angriffsklassen, die die Engine berücksichtigt (SSRF, XXE, Dekompressionsbomben, Path Traversal, Content Injection), die Default-Deny-Haltung und die im Code enthaltenen Schutzmechanismen, die jede Klasse abmildern. Es dokumentiert berücksichtigte Bedrohungen. Es behauptet nicht, dass keine Schwachstellen vorhanden sind.
  • Sicherheitsmodell – die kryptografische Oberfläche: CMS/PAdES B-B- und B-T-Signaturpfad, die AES-256-Dokumentverschlüsselung und die auf Kooperation des Readers angewiesene Natur der PDF-Berechtigungsbits. Es erklärt, warum „Unterstützung für einen Mechanismus“ nicht dasselbe ist wie „Sicherheit Ihres Deployments“.
  • Datenverarbeitung – welche Daten die Bibliothek liest, im Speicher hält und schreibt; welche PII-Bereinigungstransformation auf Audit-Bundles angewendet wird; und welchen opt-in-basierten Telemetriepfad ohne Mehraufwand es gibt. Es beschreibt das Verhalten der Bibliothek, nicht die Datenresidenz auf Deployment-Ebene.
  • Offenlegung – der koordinierte Prozess zur Offenlegung von Schwachstellen: private Meldekanäle, Zielvorgaben für die Reaktionszeit und das Embargomodell. Es ist eine Prozesszusage, keine Ergebnisgarantie.

Jede Seite stellt ihre normativen Aussagen als Tabelle Aussage → Clause-ID + reference_id dar, die aus dem citations:-Block ihres Frontmatter stammt. Lesende können die normative Grundlage jeder Aussage neu herleiten.

Nicht zutreffend. Das Trust Center ist Dokumentation. Die APIs, die das beschriebene Verhalten stützen, werden in den Modul-Referenzseiten (/modules/core/security/, /modules/core/audit/) behandelt und hier nicht erneut aufgeführt. Diese Seite verweist auf die Trust-Facetten, nicht auf Symbole.

Nicht zutreffend. Dies ist eine Index-Seite. Sie behauptet kein ausführbares Verhalten. Die Unterseiten, die Laufzeitverhalten beschreiben, enthalten dort eigene Codebeispiele, wo ein Verhalten im Kern demonstrierbar ist.

Nicht zutreffend. Siehe die Unterseiten.

  • Eine Trust-Seite ist kein Vertrag. Das Lesen dieser Seiten gewährt keine Gewährleistung. Es gilt die Lizenz (Apache-2.0). Der dortige Gewährleistungsausschluss gilt vollumfänglich.
  • Die Haltung ist versioniert. Die hier beschriebenen Standardwerte und Schutzmechanismen gelten für die aktuelle stabile Hauptversion. Eine ältere Hauptversion kann einen schwächeren Standardwert haben. Die Sicherheitsrichtlinie hält fest, welche Hauptversionen Fixes erhalten.
  • „Unterstützung“ ist eine wiederkehrende Falle. Im gesamten Trust Center ist die Unterstützung für ein Profil oder einen Mechanismus niemals dasselbe wie Konformität mit diesem Profil oder Sicherheit dieses Mechanismus. Jede Seite formuliert diese Grenze in ihren eigenen Worten neu.

Nicht zutreffend. Dokumentation hat keine Laufzeitkosten. Der Performance-Rahmen der zugrunde liegenden Sicherheitsoperationen ist auf den jeweiligen Modulseiten dokumentiert.

Das Trust Center existiert, um Sicherheitsgrenzen explizit statt implizit zu machen. Zwei übergreifende Grenzen gelten für jede Seite:

  1. Standardwerte sind fail-closed, nicht narrensicher. Jedes Policy-Objekt in der Engine wird mit der striktesten Einstellung ausgeliefert, die die öffentliche API zulässt. Jede Lockerung erfordert ein explizites Opt-in des Aufrufers. Ein fail-closed-Standardwert verringert die Wahrscheinlichkeit einer versehentlichen Preisgabe. Er entbindet Betreibende nicht von der Verantwortung, die gewählte Konfiguration zu prüfen. Dies spiegelt das Prinzip der Baseline-Konfiguration in NIST SP 800-53 Rev. 5 CM-7 wider (nist_sp_800_53r5#x4.x182.p14): eine minimierte Baseline ist ein Ausgangspunkt. Jede Lockerung ist eine explizite, dokumentierte Entscheidung.
  2. Dokumentierte Anforderungen, keine pauschale Zusicherung. Das Trust Center verifiziert das Verhalten gegen dokumentierte Sicherheitsanforderungen, im Sinne von OWASP ASVS 5 (owasp_asvs_5#x165): Ein Verifizierungsstandard misst die Konformität mit aufgelisteten Anforderungen. Er zertifiziert nicht, dass nichts übersehen wurde.

Als Profil nicht zutreffend. Dieser Index implementiert kein Konformitätsprofil. Wenn eine Unterseite einen Standard behandelt (ISO 32000-2 für Verschlüsselung und Signaturen, ISO/IEC 29147/30111 für die Offenlegung, EU-DSGVO / ISO/IEC 29100 für die Datenverarbeitung), zitiert sie die konkrete Clause und reference_id in ihrem eigenen Frontmatter. Sie rendert die Tabelle Aussage → Clause selbst.