Gestione di dati, PII e telemetria

In breve

Questa pagina descrive come il motore core gestisce i dati: che cosa legge, che cosa mantiene nella memoria del processo, che cosa scrive, la trasformazione deterministica di rimozione delle PII applicata ai bundle di audit e il percorso di telemetria opt-in.

Confine. Questa pagina descrive il comportamento della libreria. La residenza dei dati a livello di distribuzione — la giurisdizione in cui vengono elaborati i documenti, dove finiscono i file temporanei, per quanto tempo viene conservato l’output e quale backend di telemetria (se presente) riceve gli span — resta responsabilità dell’integratore, non della libreria. Il motore fornisce impostazioni predefinite fail-closed e una trasformazione di rimozione; non può decidere al posto dell’utente la residenza dei dati o la base giuridica.

Installazione

composer require nextpdf/core:^3

Il sistema di rimozione delle PII e l’interceptor di telemetria fanno parte del pacchetto core; il percorso di telemetria resta inerte finché non sono presenti un SDK OpenTelemetry e un interceptor collegato dal chiamante.

Panoramica concettuale

Il motore è un responsabile del trattamento dei dati affidatigli, nel senso della ISO/IEC 29100 (iso_iec_29100#3.x56): agisce sul contenuto del documento secondo le istruzioni dell’integratore. Non comunica con server esterni, non conserva i contenuti al di fuori dell’output richiesto e non trasmette il contenuto dei documenti ad alcun endpoint gestito da NextPDF.

Sono rilevanti tre superfici dei dati:

1. I/O dei documenti. L’input viene letto dal percorso o dal flusso fornito; l’output viene scritto nel percorso o nel flusso fornito. I buffer intermedi risiedono nella memoria del processo per l’intera durata del rendering e vengono rilasciati al suo completamento.
2. Bundle di audit. Quando l’audit è abilitato, il motore può emettere un bundle diagnostico. Prima di essere serializzato, tale bundle attraversa un sistema deterministico di rimozione delle PII.
3. Telemetria. Un interceptor OpenTelemetry opzionale può emettere span e metriche. Resta disattivata finché l’SDK non è installato e l’interceptor non viene costruito; gli attributi degli span vengono passati attraverso un sanitizer degli attributi.

L’approccio alla privacy segue il principio dell’art. 32 del GDPR secondo cui la pseudonimizzazione e la minimizzazione sono esempi di garanzie. L’applicazione di queste garanzie è responsabilità del titolare del trattamento (eu_gdpr#x50). La libreria fornisce il meccanismo di rimozione; il titolare del trattamento decide la base giuridica, la conservazione e la residenza.

Superficie dell’API

Questa pagina non documenta di nuovo le API di audit o di telemetria (vedere /modules/core/audit/). I componenti rilevanti ai fini della fiducia sono il sanitizer PII predefinito applicato ai bundle di audit e il sanitizer degli attributi dell’interceptor OpenTelemetry; di seguito se ne descrive il comportamento in termini di effetto, non di firma.

Esempio di codice — Avvio rapido

Per impostazione predefinita, nulla esce dal processo se non viene richiesto. Nessuna parte del codice abilita un’uscita di rete; in assenza di codice, questa è l’impostazione predefinita:

<?php

declare(strict_types=1);

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

use NextPDF\Core\Document;

// Input read from disk, output written to disk. No telemetry SDK loaded,
// so the telemetry path completes in sub-microsecond no-ops. No content
// is transmitted anywhere.
$doc = Document::open('input.pdf');
$doc->save('output.pdf');

Esempio di codice — Produzione

Quando si produce un bundle di audit, il sistema deterministico di rimozione delle PII maschera le categorie comuni prima della serializzazione. La trasformazione è pura (nessun clock, nessuna casualità), quindi un bundle è stabile a livello di byte per un dato input:

<?php

declare(strict_types=1);

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

use NextPDF\Audit\DefaultPiiSanitiser;

$scrubber = new DefaultPiiSanitiser();
// E-mail → [EMAIL], IPv4 → [IPV4], IPv6 → [IPV6], X.500 DN attributes
// beyond CN → keyword preserved, value [REDACTED]. Deterministic.
$safe = $scrubber->sanitise($rawAuditField);

Casi limite e insidie

• Il sistema di rimozione opera in modalità best-effort, non è una garanzia. DefaultPiiSanitiser maschera le categorie che conosce (e-mail RFC 5321, IPv4/IPv6, diversi attributi DN RFC 4514). Un campo di testo libero contenente un nome o un identificatore che i pattern non riconoscono non viene mascherato. Va considerato come un livello di difesa in profondità, non come un controllo di conformità che elimina l’obbligo di revisione dell’operatore.
• I file temporanei sono di competenza della distribuzione. Il motore utilizza una gestione sicura dei file temporanei. La posizione di TMPDIR e il fatto che TMPDIR risieda su uno storage cifrato nella giurisdizione corretta sono decisioni di distribuzione. La libreria non può imporre la residenza dei dati.
• La telemetria è opt-in e sanitizzata, ma non priva di rischi. Quando è collegato, l’interceptor OpenTelemetry passa gli attributi degli span attraverso un sanitizer degli attributi che applica una politica zero-trust per i dati. Il backend di esportazione, la sua conservazione e la sua ubicazione sono interamente una scelta dell’integratore.
• La base giuridica non è una decisione della libreria. La liceità del trattamento di un determinato documento, e la relativa base, sono stabilite dal titolare del trattamento ai sensi del GDPR / della legge locale (eu_gdpr#x50); la libreria non ne ha visibilità.

Prestazioni

Il sistema di rimozione delle PII consiste in un insieme di trasformazioni regex pure senza I/O. Il controllo, da parte dell’interceptor di telemetria, della presenza dell’SDK viene eseguito una sola volta in fase di costruzione e memorizzato nella cache. Quando non è installato alcun SDK, ogni chiamata di telemetria si completa in meno di un microsecondo; pertanto l’impostazione predefinita rispettosa della privacy (telemetria disattivata) è anche l’impostazione predefinita a overhead zero.

Note sulla sicurezza

Regole sui confini della gestione dei dati, riformulate per chi effettua la revisione:

1. Nessuna uscita occulta. Il motore non trasmette alcun contenuto dei documenti ad alcun endpoint gestito da NextPDF. L’accesso di rete in uscita avviene solo per recuperi di risorse abilitati esplicitamente e limitati per schema, e per endpoint TSA/OCSP/CRL configurati, ciascuno protetto dalla difesa SSRF.
2. Rimozione deterministica e limitata. La trasformazione delle PII del bundle di audit è deterministica e viene applicata prima della serializzazione; è un ausilio alla minimizzazione nello spirito dell’art. 32 del GDPR (eu_gdpr#x50), non una certificazione di anonimizzazione.
3. La residenza è dell’integratore. L’inventario e la mappatura dei luoghi in cui i dati vengono elaborati sono attività organizzative secondo il NIST Privacy Framework (nist_privacy_framework_1_1#x9.x1.p3); la libreria espone i controlli, l’integratore esegue la mappatura.
4. I ruoli sono esterni. Stabilire se la distribuzione sia un titolare o un responsabile del trattamento, e quali obblighi ne conseguano, è una determinazione del ruolo ai sensi della ISO/IEC 29100 (iso_iec_29100#3.x56) che la libreria non può effettuare.

Conformità

Questa pagina non è un profilo di conformità. Fa riferimento all’art. 32 del GDPR, alla ISO/IEC 29100 e al NIST Privacy Framework per individuare il confine tra il comportamento della libreria e la responsabilità del titolare del trattamento; non afferma la conformità al GDPR, la conformità alla ISO/IEC 29100 o alcuna certificazione in materia di privacy. Tali determinazioni sono effettuate a livello di distribuzione dal titolare del trattamento dei dati, non dalla libreria.

Vedere anche

• Centro per la fiducia
• Modello delle minacce del motore
• Modello di sicurezza per firma e cifratura
• Riferimento del modulo di audit del core