Datenschutz

Auf einen Blick

NextPDF Enterprise Privacy erkennt Text, der konfigurierten PII-Mustern entspricht, und schwärzt ihn entweder, unterdrückt die Zeilen, die ihn enthalten, oder ersetzt ihn durch reversible deterministische Pseudonyme, die durch eine verschlüsselte At-Rest-Map gestützt werden. Es entfernt Inhalte, die den konfigurierten Regeln entsprechen, wie getestet. Es garantiert keine vollständige PII-Entfernung und ist keine Aussage über regulatorische Compliance.

Verfügbarkeit & Lizenzierung

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

Installation

composer require nextpdf/enterprise:^3

Konzeptioneller Überblick

Die Erkennung ist musterbasiert. Ein Detektor durchsucht Text gegen ein Register regulärer Ausdrucksmuster und liefert eingebaute Muster für E-Mail-Adressen, Telefonnummern, Sozialversicherungsnummern der Vereinigten Staaten, Kreditkartennummern und taiwanische nationale Ausweisnummern. Ein Deployment kann zusätzliche Muster registrieren. Die Erkennung findet ausschließlich die konfigurierten Typen; ein Wert, dem kein Muster entspricht, wird nicht erkannt, und eine gescannte Seite ohne Textschicht ergibt keine Treffer.

Eine Schwärzungsrichtlinie steuert das Verhalten. Im Detect-only-Modus gibt die Engine Findings zurück, ohne Inhalte zu ändern. Im Schwärzungsmodus ersetzt sie jeden getroffenen Span durch eine Black-Box-, White-Box- oder Text-Ersetzung. Der De-Identifier ergänzt eine Unterdrückungsstrategie, die ganze Zeilen entfernt, die einen Treffer enthalten, statt einzelne Spans zu maskieren. Jeder Lauf gibt den SHA-256 des Originaltexts, den modifizierten Inhalt, einen detaillierten Bericht und ein Modified-Flag zurück.

Die Pseudonymisierung ist per Design reversibel. Die Engine ersetzt erkannte Entitäten durch deterministische, formatbewusste Pseudonyme, die aus einem HMAC über den Originalwert und einem Seed pro Sitzung abgeleitet werden, sodass derselbe Wert innerhalb einer Sitzung konsistent zugeordnet wird, während die Tokens sitzungsübergreifend nicht durch deterministische Gleichheit korrelieren. Die Original-zu-Pseudonym-Map wird serialisiert und at rest mit AES-256-GCM und einem versionierten Schlüssel verschlüsselt, was eine Schlüsselrotation unterstützt. Die Rehydrierung stellt Originalwerte wieder her, aber nur mit dem korrekten Schlüssel und der passenden verschlüsselten Map; ohne sie sind die Originalwerte nicht allein aus dem pseudonymisierten Text wiederherstellbar.

Diese Operationen implementieren die De-Identifizierung, die die Verknüpfung zwischen den Daten und der Person entfernt — ISO/IEC 29100:2024 §2. Die Pseudonymisierung ersetzt einen Identifikator durch einen Alias und ist per Definition mit der separat gehaltenen Zuordnung reversibel — ISO/IEC 29100:2024 §2. Die Anonymisierung zielt darauf ab, die Identifizierung unwiderruflich zu verhindern — ISO/IEC 29100:2024 §2; diese Enterprise-Oberfläche führt musterbeschränkte Schwärzung, Unterdrückung und reversible Pseudonymisierung durch, keine Anonymisierung. Das verbleibende Re-Identifikationsrisiko hängt von den Attributen ab, die nach der De-Identifizierung verbleiben — ISO/IEC 29100:2024 §2, und die De-Identifizierung verringert dieses Risiko, beseitigt es aber nicht — ISO/IEC 29151:2017. Behandeln Sie die Ausgabe als Inhalt, der den konfigurierten Regeln entsprechend wie getestet entfernt oder ersetzt wurde, nicht als Garantie für vollständige PII-Entfernung, Unwiderruflichkeit oder regulatorische Compliance.

Warum es so funktioniert

Die Reversibilität ist die tragende Entscheidung. Pseudonyme sind HMAC-SHA256-Ausgaben über den Originalwert und einen Seed pro Sitzung, sodass derselbe Wert innerhalb einer Sitzung auf dasselbe Token abgebildet wird und die internen Beziehungen des Dokuments erhalten bleiben. Ein frischer Zufalls-Seed pro Sitzung bedeutet, dass derselbe Wert sitzungsübergreifend nicht auf dasselbe Token abgebildet wird, sodass die Pseudonyme sitzungsübergreifend nicht durch deterministische Token-Gleichheit korrelieren, was die deterministische Verknüpfbarkeit ohne zentrales Nachschlagen verringert. Die Zuordnung wird bewusst aufbewahrt — at rest mit AES-256-GCM verschlüsselt —, damit eine autorisierte Rehydrierung die Originale wiederherstellen kann; diese Reversibilität ist es, die dies zu einer Pseudonymisierung gemäß ISO/IEC 29100:2024 §2 macht, nicht zu einer Anonymisierung. Der Kompromiss wird akzeptiert: Die verschlüsselte Map, nicht der pseudonymisierte Text, wird zum sensiblen Artefakt, sodass sich die Vertraulichkeit auf die Schlüsselverwahrung reduziert. Formatbewusste Tokens bewahren die Form jeder Entität, sodass nachgelagerte Parser weiterarbeiten, um den Preis, dass Prüfsummen-Validatoren einen geformten, aber synthetischen Wert ablehnen können.

Design-Hintergrund: Schwärzung ist kein schwarzes Rechteck.

API-Oberfläche

Typ	Art	Rolle	Stabilität	Seit
PiiDetector	class	Musterbasierte PII-Erkennung; unterstützt die Registrierung benutzerdefinierter Muster	stable	2.2.0
RedactionEngine	class	Detect-only- oder destruktive Textschwärzung nach Richtlinie	stable	2.2.0
DeIdentifier	class	Strategie-Dispatch für Schwärzung oder Zeilenunterdrückung	stable	2.2.0
RedactionPolicy	class	Ziel-Entitätstypen, Schwärzungsschalter, Ersetzungsstil	stable	2.2.0
PseudonymizationEngine	class	Deterministische, formatbewusste Pseudonym-Ersetzung	stable	2.2.0
PrivacyGateway	class	Dokumentbezogenes Pseudonymisieren/Rehydrieren mit Audit	stable	2.2.0
RehydrationService	class	Stellt Originale aus einer verschlüsselten Map wieder her	stable	2.2.0
EncryptedMapSerializer	class	AES-256-GCM-At-Rest-Map-Serialisierung mit Schlüsselversionierung	stable	2.2.0
PrivacyAuditTrail	class	Append-only-Log von Pseudonymisierungs-/Rehydrierungsoperationen	stable	2.2.0
EntityType / RedactionStyle / DeIdentificationStrategy	enums	Vokabular für Entität, Stil und Strategie	stable	2.2.0

Der Audit-Trail ist vertraglich Append-only: Er protokolliert eine Session-ID, eine Operation, eine Entitätsanzahl, einen Policy-Hash, einen Zeitstempel und eine Mandanten-ID. Er zeichnet die erkannten Werte nicht auf.

Codebeispiel — Schnellstart

Detect and redact configured PII

<?php

declare(strict_types=1);

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

use NextPDF\Enterprise\Privacy\PiiDetector;
use NextPDF\Enterprise\Privacy\RedactionEngine;
use NextPDF\Enterprise\Privacy\RedactionPolicy;

/**
 * Redact every configured entity type from text content.
 *
 * @param string $content The text to process.
 *
 * @return string The redacted text.
 */
function redactAll(string $content): string
{
    $engine = new RedactionEngine(new PiiDetector());

    return $engine->redact($content, RedactionPolicy::allEntities())
        ->redactedContent;
}

RedactionPolicy::allEntities() zielt auf die eingebauten Typen. Ein Wert, dem kein konfiguriertes Muster entspricht, wird nicht geschwärzt.

Codebeispiel — Produktion

Reversible pseudonymization with audit and safe logging

<?php

declare(strict_types=1);

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

use NextPDF\Enterprise\Privacy\PrivacyGateway;
use NextPDF\Enterprise\Privacy\PrivacyPolicy;
use NextPDF\Enterprise\Privacy\EntityType;
use Psr\Log\LoggerInterface;

final readonly class DocumentDeidentifier
{
    public function __construct(
        private PrivacyGateway $gateway,
        private LoggerInterface $logger,
    ) {}

    /**
     * Pseudonymize a document and return the encrypted reversal map.
     *
     * @param non-empty-string                                      $text     Document text.
     * @param list<array{text: non-empty-string, type: EntityType}> $entities Detected entities.
     *
     * @return array{text: string, encrypted_map: non-empty-string}
     */
    public function process(string $text, array $entities): array
    {
        $policy = PrivacyPolicy::piiOnly('session-' . bin2hex(random_bytes(6)));
        $result = $this->gateway->pseudonymize($text, $entities, $policy);

        $this->logger->info('Pseudonymization complete', [
            'entityCount' => $result['entity_count'],
        ]);

        return ['text' => $result['text'], 'encrypted_map' => $result['encrypted_map']];
    }
}

Der Log-Eintrag trägt nur eine Anzahl. Er trägt nicht den Dokumenttext, die erkannten Werte oder die verschlüsselte Map.

Sonderfälle & Fallstricke

• Die Erkennung ist musterbeschränkt. Ein Wert, dem kein Muster entspricht, wird nicht erkannt. Die Engine sichert nicht zu, dass alle personenbezogenen Daten gefunden werden, und das Ergebnis ist keine Garantie für vollständige PII-Entfernung.
• Gescannte Seiten haben keine Textschicht. Die Textmuster-Erkennung ergibt keine Treffer; kombinieren Sie sie mit der Intelligence-Searchable-Overlay-Oberfläche, falls zuerst Text erforderlich ist.
• Die Pseudonymisierung ist per Definition reversibel. Jeder mit dem korrekten Schlüssel und der passenden verschlüsselten Map kann die Originale wiederherstellen. Dies ist keine Anonymisierung; präsentieren Sie pseudonymisierte Ausgabe nicht als unwiderruflich.
• Formatbewusste Pseudonyme bewahren eine Form (zum Beispiel ein ID-ähnliches oder E-Mail-ähnliches Token). Ein nachgelagertes System, das Prüfsummen validiert, kann ein Pseudonym ablehnen; das ist zu erwarten.
• Die verschlüsselte Map ist das sensible Artefakt. Ihr Verlust macht die Rehydrierung unmöglich; ihr Leck zusammen mit ihrem Schlüssel macht die Pseudonymisierung für einen Dritten reversibel. Behandeln Sie die Schlüsselverwahrung und die Map-Speicherung als eine Deployment-Verantwortung.
• Die Schwärzung operiert auf dem ihr übergebenen Textinhalt. Sie flacht von sich aus kein Bild ab, entfernt kein Thumbnail und entfernt keine Dokument-Metadaten; dimensionieren Sie die Pipeline entsprechend.

Performance

Die Erkennungskosten skalieren mit der Musteranzahl und der Textlänge. Die Pseudonymisierung fügt einen HMAC pro eindeutiger Entität und eine AES-256-GCM-Versiegelung der Map hinzu. Das Wall-Budget von 1500 ms deckt ein typisches Geschäftsdokument ab. Das Reproduzierbarkeitsprofil ist structural: Pseudonyme sind für einen festen Seed deterministisch, aber der Audit-Zeitstempel und der zufällige Session-Seed variieren zwischen Läufen, sodass sich zwei Läufe in diesen Feldern unterscheiden.

Sicherheitshinweise

Die At-Rest-Map verwendet authentifizierte Verschlüsselung. Die Map wird mit AES-256-GCM und einem versionierten Schlüssel versiegelt; die Rehydrierung ist ohne die korrekte Schlüsselversion unmöglich. Die Schlüsselerzeugung, -verwahrung und -rotation liegen in der Verantwortung des Deployments; die Bibliothek verbraucht einen Schlüssel, sie verwaltet keinen Schlüsselspeicher. Der Audit-Trail ist Append-only und zeichnet Metadaten auf, niemals erkannte Werte. Jede normative Quelle ist paraphrasiert und keine wird wiedergegeben.

Datenresidenz & PII-Minderungen

Erkennung, Schwärzung und Pseudonymisierung laufen in-process auf dem Host. Bei keiner dieser Operationen verlässt Dokumentinhalt den Host. Die verschlüsselte Map und jegliche rehydrierte Ausgabe sind personenbezogene Daten; wo sie gespeichert werden und welche Rechtsordnung sie verarbeitet, ist eine Deployment-Verantwortung außerhalb der Grenze der Bibliothek. Die Bibliothek führt musterbeschränkte De-Identifizierung wie getestet durch; sie zertifiziert keine DSGVO-, HIPAA- oder sonstige regulatorische Compliance und führt keine Anonymisierung durch. Das verbleibende Re-Identifikationsrisiko hängt von den verbleibenden Attributen ab — ISO/IEC 29151:2017.

Sichere Telemetrie & Log-Bereinigung

Die Bibliothek wirft typisierte Ausnahmen mit strukturellen Meldungen und legt niemals erkannte Werte, Dokumentbytes oder die verschlüsselte Map in den Ausnahmetext. Ein Deployment, das um diese Oberfläche herum protokolliert, muss Zählwerte und den Policy-Hash protokollieren — wie im Produktionsbeispiel gezeigt — und darf die rohe PDF-Nutzlast, erkannten Entitätstext oder die Pseudonym-Map nicht in Logs oder ein APM-Backend protokollieren. Der Append-only-Audit-Trail ist der sichere Eintrag, der aufbewahrt werden sollte.

Verhalten im FIPS-Modus

Die At-Rest-Map verwendet AES-256-GCM über den Krypto-Provider der Plattform. Wenn der Host einen FIPS-validierten Provider ausführt, läuft diese Operation in der validierten Grenze. NextPDF Enterprise führt die strukturelle Zusammenstellung durch und ist selbst kein FIPS-validiertes kryptografisches Modul und erhebt keinen FIPS-Zertifizierungsanspruch.

Konformität

Anspruch	Standard	Klausel
Die De-Identifizierung entfernt die Verknüpfung zwischen Daten und der Person.	ISO/IEC 29100:2024	§2
Die Pseudonymisierung ersetzt einen Identifikator durch einen Alias und ist mit der separaten Zuordnung reversibel.	ISO/IEC 29100:2024	§2
Die Anonymisierung zielt darauf ab, die Identifizierung unwiderruflich zu verhindern (diese Oberfläche anonymisiert nicht).	ISO/IEC 29100:2024	§2
Das verbleibende Re-Identifikationsrisiko hängt von den verbleibenden Attributen ab.	ISO/IEC 29100:2024	§2
Datenschutzkontrollen werden auf PII angewendet.	ISO/IEC 29100:2024	§6.5
Die De-Identifizierung verringert das verbleibende Risiko, beseitigt es aber nicht.	ISO/IEC 29151:2017	de-identification controls
Minimieren Sie die Verknüpfbarkeit de-identifizierter Daten.	ISO/IEC 29151:2017	PII minimization
Kontrollen werden zum Schutz von PII angewendet.	ISO/IEC 29151:2017	controls

Alle Klauseln sind paraphrasiert. NextPDF gibt keinen normativen Text wieder. Konsultieren Sie die veröffentlichten Standards für den verbindlichen Wortlaut. NextPDF erhebt keinen Anspruch auf Compliance mit Datenschutzvorschriften; diese Seite nennt das getestete De-Identifizierungsverhalten und seine Grenzen, keinen zertifizierten Compliance-Status.

Verhaltensvertrag

• Die Erkennung ist musterbeschränkt: Sie findet ausschließlich die konfigurierten Typen; ein Wert, dem kein Muster entspricht, wird nicht erkannt, und eine Seite ohne Textschicht ergibt keine Treffer.
• Eine Schwärzungsrichtlinie wählt Detect-only, Span-Ersetzung (Black-Box / White-Box / Text) oder Ganzzeilen-Unterdrückung; jeder Lauf gibt den SHA-256 des Originaltexts, den modifizierten Inhalt, einen detaillierten Bericht und ein Modified-Flag zurück.
• Die Pseudonymisierung ist per Design reversibel: deterministische, HMAC-abgeleitete Pseudonyme sind innerhalb einer Sitzung konsistent, und die Rehydrierung erfordert die korrekte Schlüsselversion und die passende AES-256-GCM-At-Rest-Map.
• Der Append-only-Audit-Trail zeichnet Session-ID, Operation, Entitätsanzahl, Policy-Hash, Zeitstempel und Mandanten-ID auf — niemals die erkannten Werte.
• Die Ausgabe ist Inhalt, der den konfigurierten Regeln entsprechend wie getestet entfernt oder ersetzt wurde, keine Garantie für vollständige PII-Entfernung, Unwiderruflichkeit oder regulatorische Compliance.

Veröffentlichungsgrenze

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

Core-Fallback

NextPDF Core (Apache-2.0) hat keine Oberfläche für PII-Erkennung, Schwärzung oder Pseudonymisierung — keine; diese Fähigkeit hat kein Äquivalent in der Core-Stufe.

Pro-Fallback

NextPDF Pro liefert eine PII-Erkennungs-Oberfläche auf Textschicht-Ebene und Maskierung zur Erzeugungszeit; es stellt keine reversible Pseudonymisierung, keine verschlüsselte At-Rest-Map, keine Zeilenunterdrückung und keinen Append-only-Audit-Trail bereit. Diese werden ausschließlich im Paket nextpdf/enterprise ausgeliefert.

Hinweis zur Enterprise-Grenze

Erkennung, Schwärzung, Unterdrückung und Pseudonymisierung werden auf Verhaltensebene beschrieben. Die Bibliothek verbraucht einen Verschlüsselungsschlüssel; sie verwaltet keinen Schlüsselspeicher, und die Interna der Schlüsselerzeugung, -verwahrung und -rotation liegen außerhalb des Umfangs der öffentlichen Oberfläche.

Deployment-Grenze

Die verschlüsselte Map und jegliche rehydrierte Ausgabe sind personenbezogene Daten; wo sie gespeichert werden und welche Rechtsordnung sie verarbeitet, ist eine Deployment-Verantwortung außerhalb der Grenze der Bibliothek. Die Schlüsselerzeugung, -verwahrung und -rotation liegen in der Verantwortung des Deployments — die Bibliothek verbraucht eine Schlüsselversion, sie verwaltet keinen Schlüsselspeicher. Der Verlust der Map macht die Rehydrierung unmöglich; ihr Leck zusammen mit ihrem Schlüssel macht die Pseudonymisierung für einen Dritten reversibel.

Grenze der rechtlichen Compliance

Die At-Rest-Map verwendet authentifizierte Verschlüsselung. Die Bibliothek führt musterbeschränkte De-Identifizierung wie getestet durch und zertifiziert keine DSGVO-, HIPAA- oder sonstige regulatorische Compliance und führt keine Anonymisierung durch. Diese Dokumentation ist kein Rechtsgutachten; konsultieren Sie Ihre eigenen Compliance- und Rechtsberater.

Siehe auch

• Privacy-Referenz — die vollständige öffentliche API-Oberfläche des Privacy-Moduls.
• Pro security — Pro-Maskierung und PII-Erkennung auf Textschicht-Ebene.
• Forensics — schreibgeschützte Analyse der Revisionshistorie.
• NextPDF Enterprise — die vollständige Enterprise-Funktionsoberfläche.
• Datenschutzrichtlinie — der eigene Datenumgang des Dokumentationsprogramms.
• PII · Pseudonymization · De-identification · AES-GCM — Glossarbegriffe.