Sicurezza

In breve

NextPDF Pro aggiunge una superficie di sicurezza sopra NextPDF Core: mascheramento dei contenuti in fase di generazione, rilevamento dei dati sensibili sul text layer, strategie di firma remota e con KMS cloud e firma sequenziale multi-parte. NextPDF Core produce i livelli PAdES B-B e B-T; Pro produce gli stessi livelli e vi aggiunge sopra questi flussi di firma (per il B-T, una firma B-B più una marca temporale di firma RFC 3161 sul valore della firma). Questa pagina è a livello di comportamento. Dichiara cosa fa ogni parte, cosa non fa e dove inizia il confine Enterprise.

Disponibilità e licenza

Questa funzionalità è distribuita in NextPDF Pro (nextpdf/pro) e si attiva con un envelope di licenza di livello Pro. Un deployment privo di quell’entitlement non carica le classi della funzionalità. Confronta le edizioni e ottieni una licenza.

Core distribuisce il signer CMS software, il client di timestamp RFC 3161, la validazione del percorso RFC 5280 e il controllo della revoca OCSP e CRL. Pro aggiunge il mascheramento, il rilevamento dei dati sensibili e i flussi di firma remota, con KMS cloud e sequenziale; quei flussi producono gli stessi livelli B-B e B-T di Core attraverso lo stack RFC 3161 di Core (per il B-T, una marca temporale di firma sul valore della firma). Un deployment privo di un entitlement Pro attivo non carica queste classi; il contratto di firma di Core continua a funzionare invariato.

Installazione

composer require nextpdf/pro:^3

Panoramica concettuale

Il motore di mascheramento applica una lista ordinata di regole al testo prima che la pagina venga scritta. Ogni regola corrisponde a un’espressione regolare. Una regola sostituisce una corrispondenza in uno di tre modi: un riempimento black-box che rimuove il testo dal content stream, una sequenza di asterischi dello stesso conteggio di caratteri, oppure un’etichetta fissa come [REDACTED]. Il motore rimuove gli oggetti di testo sottostanti per la modalità black-box, come verificato dai test; non asserisce che ogni forma di contenuto sensibile venga trovata. Il rilevamento dipende dalle regole che si configurano.

La superficie PII è uno strumento di rilevamento, non una garanzia di redazione. Estrae il text layer, quindi applica pattern integrati per indirizzi e-mail, numeri di telefono, numeri di previdenza sociale degli Stati Uniti e numeri di carta di credito. Restituisce una vista mascherata del testo e un conteggio delle corrispondenze. Non sovrascrive i glifi renderizzati nell’immagine della pagina. Una pagina scansionata priva di text layer non produce corrispondenze. Trattare il risultato come rilevamento basato su pattern dei tipi configurati, non come rimozione completa dei dati personali.

La superficie di firma aggiunge flussi di lavoro remoti e asincroni sopra il signer di Core. Una sessione calcola il digest del documento, costruisce gli attributi firmati CMS e consegna i byte degli attributi firmati a una strategia di firma. Una strategia può essere un KMS cloud, un firmatario esterno differito o un percorso di ingest che avvolge una firma CAdES o XAdES esistente. La sessione assembla quindi il CMS SignedData e lo archivia codificato in DER nella voce Contents del dizionario di firma — ISO 32000-2 §12.8.1. Il SignerInfo trasporta gli attributi firmati content-type e message-digest; il processo di calcolo del message digest è RFC 5652 §5.4. Un verificatore non deve fare affidamento sui digest calcolati dall’originatore; ricalcola in modo indipendente il digest del contenuto e lo confronta con l’attributo message-digest, e il confronto deve corrispondere affinché la firma sia valida — RFC 5652 §5.6 processo di verifica della firma.

NextPDF Core produce i livelli PAdES B-B e B-T; NextPDF Pro produce gli stessi livelli e vi aggiunge sopra i suoi flussi di firma. Per il B-B la sessione assembla un CMS SignedData con l’insieme di attributi firmati B-B e non applica alcuna marca temporale. Per il B-T la sessione aggiunge esattamente una signature-time-stamp RFC 3161 come attributo CMS non firmato sul valore della firma: una signature-time-stamp è un attributo non firmato che trasporta una marca temporale calcolata sul valore della firma digitale per un firmatario — ETSI EN 319 122-1 §5.3, e il suo MessageImprint è un hash del valore del campo di firma del SignerInfo, identificato dall’OID id-aa-timeStampToken — RFC 3161 Appendix A. Il genTime della marca temporale è l’istante UTC in cui il token è stato creato — RFC 3161 §2.4.2. Poiché la marca temporale è un attributo non firmato, il digest firmato B-B, il valore della firma del SignerInfo e il /ByteRange del PDF restano invariati; cresce soltanto il CMS. Il token RFC 3161 viene ottenuto da un timestamp provider configurato (il client RFC 3161 di Core predefinito, oppure un provider fornito dal chiamante); il B-T usa un message imprint SHA-256 sul percorso del provider predefinito. NextPDF Pro implementa il supporto alla firma PAdES B-T secondo ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 e RFC 5816; ciò è verificato con fixture. NextPDF Pro non asserisce una certificazione ETSI EN 319 142-1 indipendente e non asserisce la validità legale del documento. Il B-LT e il B-LTA aggiungono un Document Security Store e marche temporali di documento per la validazione di archiviazione a lungo termine — ETSI EN 319 142-2 §5.5; quei livelli sono una capability Enterprise (nextpdf/enterprise) e non sono prodotti da Pro. Vedere Confine Enterprise di seguito.

Perché funziona così

La superficie di firma consegna i byte degli attributi firmati a una SigningStrategy anziché detenere una chiave privata. Quella singola decisione è portante. Un KMS cloud, un firmatario esterno differito o un percorso di ingest CAdES/XAdES soddisfano tutti lo stesso contratto, pertanto il codice chiamante resta identico e il materiale della chiave non entra mai in NextPDF. Suddividere la sessione in RemoteSigningSession::prepare() e RemoteSigningSession::complete() consente alla firma di tornare in modo asincrono, poiché il digest è fissato prima che la chiave venga mai raggiunta. La marca temporale è allegata come attributo CMS non firmato, così il B-T resta additivo: il digest firmato B-B, il valore della firma del SignerInfo e il /ByteRange restano intatti. Ogni giuntura è fail-closed, poiché un percorso di firma che si degrada silenziosamente è peggiore di uno che si arresta. Contesto di design: Firma su scala, senza compromessi.

Superficie API

Tipo	Genere	Ruolo	Stabilità	Da
RemoteSigningSession	classe	Sessione di firma remota o asincrona in due fasi	stable	1.9.0
RemoteSigningConfig	classe	Configurazione immutabile della sessione, incluso il livello PAdES	stable	1.9.0
SequentialSigner	classe	Firma sequenziale multi-parte con supporto DocMDP	stable	1.9.0
SigningStrategy	interface	Il contratto del meccanismo di firma che una sessione invoca	stable	1.9.0
PadesWrapper	classe	Avvolge una firma CAdES o XAdES esistente per l’incorporamento PAdES	stable	1.9.0
KmsSignerInterface	interface (SPI)	Contratto di driver HSM e KMS di terze parti	stable	2.1.0
GenerationTimeMasker	classe	Mascheramento basato su regole applicato prima che la pagina venga scritta	stable	1.9.0
MaskingConfig / MaskingRule / MaskingMode	tipi	Configurazione, regola e modalità di sostituzione del mascheramento	stable	1.9.0

RemoteSigningConfig trasporta un campo di livello PAdES il cui enum è il SignatureLevel di Core. Il percorso di firma di Pro produce la baseline B-B e il livello B-T: configurare RemoteSigningConfig::default()->withLevel(SignatureLevel::PAdES_B_T) (oppure usare SequentialSigner::withTimestamping()) e fornire un timestamp provider, e la sessione aggiunge l’attributo non firmato della marca temporale di firma RFC 3161. Lo spazio /Contents riservato per il B-T viene aumentato automaticamente affinché la marca temporale vi rientri; uno spazio configurato sottodimensionato fallisce in modo fail-closed con un errore di configurazione tipizzato anziché troncare. Un livello superiore al B-T trasportato nella config (B-LT o B-LTA) è un valore dichiarato in anticipo su cui Pro non agisce; quel produttore a lungo termine si risolve in fase di esecuzione tramite il contratto di Core ed è distribuito nel pacchetto nextpdf/enterprise.

Esempio di codice — Avvio rapido

Sign with a cloud-KMS strategy

<?php

declare(strict_types=1);

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

use NextPDF\Pro\Security\Signing\RemoteSigningSession;
use NextPDF\Pro\Security\Signing\SigningStrategy;

/**
 * Produce a signed PDF using any signing strategy.
 *
 * @param string          $pdfWithPlaceholder PDF bytes with a signature placeholder.
 * @param SigningStrategy  $strategy           A cloud-KMS, deferred, or ingest strategy.
 *
 * @return string The signed PDF bytes.
 */
function signWithStrategy(string $pdfWithPlaceholder, SigningStrategy $strategy): string
{
    $session = RemoteSigningSession::create($pdfWithPlaceholder);

    $session->prepare(
        certDer: $strategy->getCertificateDer(),
        chainDer: $strategy->getCertificateChainDer(),
        algorithmOid: $strategy->getSignatureAlgorithmOid(),
        digestAlgorithm: $strategy->getDigestAlgorithm(),
        contentsHexStart: 0,
        contentsHexEnd: 0,
    );

    return $session->complete($strategy);
}

Il chiamante dipende dal contratto SigningStrategy. Una strategia con KMS cloud e una strategia di ingest CAdES lo soddisfano entrambe, pertanto questo codice non cambia da una strategia all’altra.

Esempio di codice — Produzione

Multi-party sequential signing with audit logging

<?php

declare(strict_types=1);

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

use NextPDF\Pro\Security\Signing\SequentialSigner;
use NextPDF\Pro\Security\Signing\SigningStrategy;
use Psr\Log\LoggerInterface;

final readonly class ApprovalWorkflow
{
    public function __construct(private LoggerInterface $logger) {}

    /**
     * Sign a PDF with two parties in sequence.
     *
     * @param string          $pdfData   The PDF bytes to sign.
     * @param SigningStrategy  $approver  The first-party strategy.
     * @param SigningStrategy  $reviewer  The second-party strategy.
     *
     * @return string The signed PDF bytes.
     */
    public function run(string $pdfData, SigningStrategy $approver, SigningStrategy $reviewer): string
    {
        try {
            $result = SequentialSigner::create($pdfData)
                ->addSigner($approver, 'Approver', reason: 'Approved')
                ->addSigner($reviewer, 'Reviewer', reason: 'Reviewed')
                ->sign();

            $this->logger->info('Sequential signing complete', [
                'signatures' => $result->signatureCount,
            ]);

            return $result->pdfData;
        } catch (\Throwable $e) {
            $this->logger->error('Sequential signing failed', ['error' => $e->getMessage()]);

            throw $e;
        }
    }
}

Ogni firmatario è una revisione incrementale separata. Il blocco catch effettua il logging e rilancia; non inghiotte il fallimento, il che mantiene il percorso di firma fail-closed.

Casi limite e accorgimenti

• Una firma prodotta non è una firma verificata. La validazione del percorso viene eseguita presso il verificatore con i trust anchor di quel verificatore — RFC 5280 §6.1. Il produttore non può asserirne il risultato.
• Il rilevamento del mascheramento dipende dalle regole configurate. Un insieme di regole che non corrisponde a un valore non lo maschera. Il motore non asserisce che tutti i contenuti sensibili vengano trovati.
• Il rilevamento dei dati sensibili è solo sul text layer. Una pagina scansionata priva di text layer non produce corrispondenze. Lo strumento non sovrascrive i glifi della pagina renderizzata.
• La struttura CMS deve rientrare nello spazio Contents riservato. Il SignedData B-B con una catena di certificati completa ha una dimensione; dimensionare di conseguenza lo spazio riservato, altrimenti la sessione solleva un errore di overflow.
• Una strategia con KMS cloud dipende dalla raggiungibilità di rete e dalla disponibilità del provider. Un errore di rete o di provider solleva un’eccezione tipizzata; la sessione non produce silenziosamente un documento non firmato.
• L’OCSP unknown non equivale a good. Trattare unknown come una non-determinazione — RFC 6960 §2.2.

Prestazioni

Una firma software è di pochi millisecondi a una cifra. Una firma con KMS cloud aggiunge un round trip di rete verso il provider. Una firma B-T aggiunge un round trip verso il timestamp provider configurato, oltre all’operazione di firma. Il budget di 1500 ms wall copre una singola firma B-B con un provider remoto su una connessione calda. Il costo del mascheramento scala con il conteggio delle regole e la lunghezza del testo. Il profilo di riproducibilità è structural: gli attributi firmati B-B incorporano l’istante di firma e una firma B-T incorpora inoltre una marca temporale, pertanto due esecuzioni differiscono nei byte di signing-time e di marca temporale mentre la struttura firmata è identica.

Note di sicurezza

Questo è un confine crittografico, pertanto il modello di minaccia è esplicito. Il byte range è calcolato dal motore e non viene mai accettato dal chiamante. Il percorso di firma è fail-closed: un fallimento di una primitiva o una lacuna di capability solleva un’eccezione tipizzata e non declassa mai silenziosamente a un algoritmo più debole. Una strategia con KMS cloud è un punto di integrazione, non un archivio di chiavi. La protezione della chiave dipende dalla gestione della chiave, dal KMS configurato e dal deployment; NextPDF Pro non detiene la chiave privata per una strategia KMS. Pro opera in una modalità FIPS-compatibile quando è configurato contro un KMS o un HSM convalidato FIPS; NextPDF Pro non è esso stesso un modulo crittografico convalidato FIPS. Questa pagina riguarda la firma crittografica; ogni fonte normativa è parafrasata e nessuna è riprodotta.

Residenza dei dati e mitigazioni PII

Le superfici di mascheramento e PII vengono eseguite in-process. Nessun contenuto del documento lascia l’host per il mascheramento o il rilevamento dei dati sensibili. Una strategia con KMS cloud invia al provider il digest degli attributi firmati, non il documento, per l’operazione di firma. Il rilevamento dei dati sensibili è basato su pattern sui tipi configurati e rimuove gli oggetti di testo sottostanti per la modalità black-box, come verificato dai test; non è una garanzia di rimozione completa dei dati personali e non è una dichiarazione di conformità normativa.

Telemetria sicura e scrubbing dei log

La libreria solleva eccezioni tipizzate con messaggi strutturali. Non scrive contenuti del documento o valori PII rilevati nei messaggi delle eccezioni o nei log. Un deployment che effettua logging attorno al percorso di firma dovrebbe registrare i campi strutturali mostrati nell’esempio di produzione, non i byte del documento.

Comportamento in modalità FIPS

Pro seleziona l’algoritmo dall’algoritmo di firma configurato e dalla strategia. Quando configurato contro un KMS o un HSM convalidato FIPS, l’operazione crittografica viene eseguita all’interno di quel confine convalidato. NextPDF Pro esegue di per sé l’assemblaggio strutturale e il calcolo del digest; non è un modulo convalidato FIPS e non avanza alcuna pretesa di certificazione FIPS.

Confine Enterprise

NextPDF Pro produce la baseline B-B e il livello B-T. Il B-T aggiunge una signature-time-stamp RFC 3161 come attributo CMS non firmato sul valore della firma, calcolata sul valore della firma digitale per un firmatario — ETSI EN 319 122-1 §5.3. NextPDF Pro implementa ciò secondo ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 e RFC 5816; è verificato con fixture. NextPDF Pro non asserisce una certificazione ETSI EN 319 142-1 indipendente e non asserisce la validità legale del documento.

I livelli B-LT e B-LTA sono capability Enterprise e non sono prodotti da Pro. Il B-LT e il B-LTA aggiungono un Document Security Store e marche temporali di documento per la validazione di archiviazione a lungo termine — ETSI EN 319 142-2 §5.5. Una configurazione che richiede un Document Security Store o il ciclo di archiviazione a lungo termine risolve quel produttore in fase di esecuzione tramite il contratto di Core; quel produttore è distribuito nel pacchetto nextpdf/enterprise. In un deployment solo-Pro, una richiesta di B-LT o B-LTA fallisce in modo fail-closed con un messaggio che nomina il componente Enterprise mancante. Pro non produce alcun Document Security Store, alcun dizionario VRI, alcuna marca temporale di documento e alcun ciclo di archiviazione, e non avanza alcuna pretesa di validazione a lungo termine (LTV). Anche la custodia delle chiavi su hardware tramite PKCS#11 e il profilo di crypto-policy FIPS 140-3 sono capability Enterprise.

Livello PAdES	Aggiunge	Edizione produttrice
B-B	Firma CMS con attributi firmati	Core, Pro, Enterprise
B-T	Una marca temporale di firma RFC 3161 come attributo non firmato sul valore della firma	Core, Pro, Enterprise
B-LT	Document Security Store con materiale di validazione	Enterprise (nextpdf/enterprise)
B-LTA	Marche temporali di documento per la validità di archiviazione	Enterprise (nextpdf/enterprise)

Contratto di comportamento

• Il mascheramento applica le regole configurate prima che la pagina venga scritta e rimuove gli oggetti di testo sottostanti per la modalità black-box, come verificato dai test.
• Il rilevamento dei dati sensibili estrae il text layer, applica i pattern configurati e restituisce una vista mascherata e un conteggio delle corrispondenze. Non sovrascrive i glifi renderizzati.
• La firma remota è in due fasi: prepare calcola il digest e costruisce gli attributi firmati; complete assembla il CMS e lo incorpora.
• Pro produce la baseline B-B e il livello B-T. Per il B-T, la sessione aggiunge una signature-time-stamp RFC 3161 come attributo CMS non firmato sul valore della firma; il digest firmato B-B e il /ByteRange restano invariati. Una richiesta B-T priva di timestamp provider, o con uno spazio Contents configurato sottodimensionato, fallisce in modo fail-closed con un errore di configurazione tipizzato. Una richiesta di B-LT o B-LTA priva del pacchetto Enterprise fallisce in modo fail-closed con un errore nominato.
• Una strategia con KMS cloud riceve il digest degli attributi firmati, non il documento, e restituisce i byte della firma grezza.

Conformità

Asserzione	Standard	Clausola
La firma CMS è archiviata codificata in DER nella voce Contents del dizionario di firma.	ISO 32000-2	§12.8.1
Il processo di calcolo del message digest; gli attributi firmati trasportano content-type e message-digest.	RFC 5652	§5.4
Il verificatore non deve fare affidamento sui digest calcolati dall’originatore; li ricalcola e li confronta in modo indipendente (processo di verifica della firma).	RFC 5652	§5.6
Una signature-time-stamp PAdES B-T è un attributo non firmato che trasporta una marca temporale calcolata sul valore della firma digitale per un firmatario (Pro produce il B-T).	ETSI EN 319 122-1	§5.3
Il MessageImprint della marca temporale id-aa-timeStampToken della signature-time-stamp è un hash del valore del campo di firma del SignerInfo.	RFC 3161	Appendix A
Sul lato di verifica, NextPDF vincola il MessageImprint di una signature-time-stamp al valore della firma del SignerInfo e fallisce in modo fail-closed in caso di mancata corrispondenza, token mancante/duplicato o imprint SHA-1 (verifica rigorosa, non una certificazione).	RFC 3161	Appendix A
Una marca temporale B-T trasporta un genTime UTC che è l’istante in cui il token è stato creato.	RFC 3161	§2.4.2
La validazione del percorso di certificazione verifica i basic constraint e gli input del percorso verso un trust anchor.	RFC 5280	§6.1
L’OCSP riporta certStatus come good, revoked o unknown.	RFC 6960	§2.2
Il B-LT e il B-LTA aggiungono un Document Security Store e marche temporali di documento per la validazione a lungo termine (confine Enterprise).	ETSI EN 319 142-2	§5.5

Tutte le clausole sono parafrasate. NextPDF non riproduce il testo normativo. Consultare gli standard pubblicati per la formulazione autorevole. NextPDF Pro implementa il supporto alla firma PAdES B-T secondo ETSI EN 319 122-1 §5.3 (signature-time-stamp), RFC 3161, RFC 5652 e RFC 5816, ed è verificato con fixture. ETSI EN 319 142-1 (la parte sui livelli baseline PAdES) è al di fuori dell’insieme di evidenze citato; NextPDF Pro pertanto non asserisce una certificazione, conformità o compliance ETSI EN 319 142-1 indipendente, e non asserisce la validità legale del documento. Questa pagina dichiara la struttura prodotta, gli standard che il supporto B-T implementa e il confine Enterprise B-LT/B-LTA, non un livello di conformità certificato.

Confine di pubblicazione

Questa pagina documenta solo il comportamento osservabile esternamente e la superficie API pubblica supportata. Percorsi di namespace interni, classi helper, tabelle di meccanismi, nomi di file di runbook e prefissi di ticket sono fuori ambito.

Vedere anche

• Sicurezza — Riferimento approfondito — il riferimento approfondito per questa superficie di sicurezza di Pro.
• Core signing — il signer CMS, il timestamp RFC 3161, la validazione del percorso RFC 5280, OCSP e CRL.
• Mappatura baseline PAdES — B-B, B-T, B-LT, B-LTA tra le edizioni.
• NextPDF Pro — l’intera superficie di funzionalità di Pro.
• Core security — la cifratura e la più ampia superficie di firma.
• CMS · PAdES · RFC 3161 timestamp · KMS · DSS — voci di glossario.