# Sicurezza di PDF Blocks Come l’API di PDF Blocks tratta i documenti che le vengono inviati e i controlli alla base del servizio, dalla crittografia alla risposta agli incidenti. Questa pagina descrive la sicurezza dell’**API di elaborazione documenti di PDF Blocks**: il servizio che riceve, trasforma e restituisce i suoi documenti PDF. È lì che vengono trattati i suoi dati, quindi è questo l’oggetto della pagina. È un servizio **stateless** che non memorizza nulla e funziona separatamente dai nostri sistemi di account e fatturazione, che non ricevono mai i suoi documenti. Questa pagina è rivolta ai team di sicurezza e acquisti che ci valutano; per un controllo non trattato qui, scrivere a [security@pdfblocks.com](mailto:security@pdfblocks.com). **Preferisce un documento?** Scaricare il [PDF Blocks Security Whitepaper (PDF)](/pdf-blocks-security-whitepaper.pdf): una sintesi condivisibile di tutto ciò che si trova in questa pagina. ## Due impegni che definiscono l’API Gran parte di ciò che rende PDF Blocks sicuro da adottare si riduce a due dati strutturali sul funzionamento dell’API: - **Non memorizziamo mai i suoi documenti.** L’API elabora ogni file in memoria e restituisce il risultato nella stessa risposta. I documenti non vengono mai scritti in un database o in un’archiviazione durevole. Un upload di grandi dimensioni può essere brevemente messo in buffer in un file temporaneo per la durata di una singola richiesta e viene eliminato nel momento in cui la richiesta si conclude. - **La nostra pipeline è deterministica e non usa LLM.** Ogni azione è una manipolazione di documenti implementata nel codice: lo stesso documento e gli stessi parametri producono sempre lo stesso output. Nessun modello linguistico di grandi dimensioni legge i suoi documenti, la pipeline non chiama alcun servizio di IA di terze parti e nulla di ciò che ci invia viene usato per addestrare o perfezionare un modello. ## Come vengono trattati i suoi documenti Quando invia un documento all’API, questo viene ricevuto su TLS, elaborato in memoria e restituito in streaming nella risposta. Del contenuto del documento non viene conservato nulla. Per ogni richiesta registriamo soltanto metadati (un hash della chiave API, l’azione richiesta, il numero di byte in input e in output, lo stato della risposta e un timestamp), che utilizziamo per la fatturazione, la sicurezza e la prevenzione degli abusi. Il trattamento che svolgiamo per suo conto è disciplinato dal nostro [Addendum sul trattamento dei dati](/docs/trust/dpa), disponibile per i clienti aziendali. Poiché i documenti non vengono mai resi persistenti, non esistono dati documentali da esportare, da eliminare o per cui produrre un certificato di distruzione: la garanzia è strutturale, non una politica che dobbiamo far rispettare. ## IA e apprendimento automatico PDF Blocks non è un prodotto di IA. Azioni come unire, dividere, ruotare, applicare filigrane, apporre timbri e proteggere con password sono trasformazioni deterministiche scritte nel codice e costituiscono tutto ciò che l’API fa del suo file. Nessun modello linguistico di grandi dimensioni legge i suoi documenti e nessun contenuto di documento viene inviato a un servizio di IA di terze parti. Alcune operazioni devono lavorare sull’aspetto di una pagina anziché sulla sua struttura. La lettura di un codice a barre è l’esempio più chiaro: individuare il simbolo sulla pagina e decodificarlo può ricorrere all’elaborazione visiva. Si tratta di analisi di immagini, non di un modello linguistico, e viene eseguita nello stesso ambiente isolato e privo di accesso a Internet in uscita di tutto il resto. In entrambi i casi la regola è la stessa: **non addestriamo modelli di apprendimento automatico sui suoi documenti** e non ne utilizziamo mai i contenuti per nulla che vada oltre l’operazione richiesta. ## Crittografia - **In transito.** Tutte le connessioni sono crittografate con TLS. Applichiamo una policy moderna TLS 1.3 / 1.2 e le richieste in HTTP semplice vengono reindirizzate in modo permanente a HTTPS. Anche il traffico tra i componenti interni dell’API è crittografato con TLS. - **A riposo.** L’API non mantiene alcuna archiviazione durevole, quindi per progettazione non c’è nulla da crittografare a riposo. Un upload di grandi dimensioni può essere brevemente messo in buffer in un file temporaneo per la durata di una singola richiesta: quel file viene eliminato nel momento in cui la richiesta si conclude e non viene mai conservato. ## Autenticarsi all’API Le richieste sono autenticate con una chiave API, che identifica il suo account in modo che possiamo autenticare la richiesta e misurare l’utilizzo ai fini della fatturazione. Memorizziamo ogni chiave soltanto come hash SHA-256 con un breve prefisso visualizzabile: la chiave completa viene mostrata una sola volta, alla creazione, e in seguito non è più recuperabile da noi. Le chiavi possono essere revocate in qualsiasi momento e le revoche vengono conservate come traccia di audit. Le chiavi sono associate a un piano, che regola le regioni, le dimensioni dei documenti e i volumi che possono utilizzare. Una chiave API è una credenziale di utilizzo, non una porta d’accesso ai suoi dati. Ci dice a quale account appartiene una richiesta, così possiamo autorizzarla e conteggiarla sul suo piano, e non fa altro. Non esiste alcun endpoint che elenchi, scarichi o riproduca i documenti già elaborati, perché non li abbiamo mai memorizzati. Chi ruba una chiave può consumare la sua quota, motivo per cui le chiavi possono essere revocate all’istante, ma **non può raggiungere nemmeno uno dei suoi documenti**. La risposta a ogni richiesta è l’unica copia ed è sua. ## Infrastruttura L’API è eseguita su Amazon Web Services e Microsoft Azure, definita come infrastructure-as-code e distribuita tramite una pipeline automatizzata e sottoposta a revisione. Proprietà principali: - **Isolamento della rete.** L’elaborazione dei documenti viene eseguita in reti private isolate *senza accesso a Internet in uscita*, quindi non può esfiltrare dati nemmeno in linea di principio. - **Protezione perimetrale.** L’API è protetta da un web application firewall con rate limiting. - **Host rafforzati ed effimeri.** Il calcolo viene eseguito su immagini di base aggiornate e con le patch applicate: i dischi delle istanze sono crittografati e vengono distrutti quando un’istanza viene dismessa. - **La sicurezza fisica** dei data center sottostanti è ereditata da AWS e Microsoft Azure, che mantengono attestazioni SOC 2, ISO 27001 e PCI DSS per le proprie strutture. ## Regioni e residenza dei dati È Lei a scegliere dove vengono elaborati i suoi documenti, rivolgendosi a un endpoint regionale: la richiesta viene elaborata interamente all’interno di quella giurisdizione e in nessun altro luogo. L’API è disponibile nelle regioni seguenti, ciascuna *stateless* e in grado di eseguire il catalogo completo delle azioni: | Regione | Endpoint | | ----------------------------------- | ----------------------- | | Globale (instradamento per latenza) | api.pdfblocks.com | | Stati Uniti | us.api.pdfblocks.com | | Stati Uniti (allineati a HIPAA) | hipaa.api.pdfblocks.com | | Unione europea | eu.api.pdfblocks.com | | Regno Unito | uk.api.pdfblocks.com | | Canada | ca.api.pdfblocks.com | | Australia | au.api.pdfblocks.com | | Giappone | jp.api.pdfblocks.com | | India | in.api.pdfblocks.com | | Brasile | br.api.pdfblocks.com | Poiché l’elaborazione è *stateless*, la residenza dei dati si riduce a una sola decisione: a quale host viene inviata la richiesta. I dettagli sono nella nostra documentazione [Regioni e residenza dei dati](/docs/api/regions-and-data-residency). L’endpoint allineato a HIPAA è destinato ai flussi di lavoro che trattano informazioni sanitarie protette, con un Business Associate Agreement firmato. Vedere [HIPAA](/docs/trust/hipaa). ## Sicurezza applicativa e dello sviluppo - Ogni modifica è sottoposta a controllo di versione e a revisione tra pari, e viene unita tramite un’integrazione continua che esegue test automatici unitari, di integrazione e di contratto prima che il codice possa essere rilasciato. - Ogni commit viene analizzato con strumenti di sicurezza automatici (analisi statica del codice applicativo e audit delle vulnerabilità nelle dipendenze) e gli aggiornamenti delle dipendenze vengono proposti automaticamente e sottoposti a revisione. - Le distribuzioni si autenticano con credenziali federate di breve durata (nessuna chiave cloud di lunga durata) e richiedono un passaggio esplicito di approvazione umana per arrivare in produzione. - I rilasci sono sottoposti a controlli di integrità e ne viene eseguito automaticamente il rollback se una nuova versione non supera il proprio test di idoneità. ## Gestione delle vulnerabilità e risposta agli incidenti Le vulnerabilità vengono individuate in modo continuo (scansione delle dipendenze, analisi statica, avvisi dei fornitori e segnalazioni esterne), classificate per gravità e corrette entro tempi definiti, con i problemi critici affrontati nel giro di pochi giorni. Gestiamo gli incidenti di sicurezza secondo un piano documentato con gravità e passaggi di risposta definiti e informiamo i clienti interessati degli incidenti confermati o sospetti che li riguardano senza indebito ritardo, in linea con il nostro [Addendum sul trattamento dei dati](/docs/trust/dpa) e con la legge applicabile. ## Disponibilità e resilienza - In ogni regione l’API funziona con capacità ridondante distribuita su più zone di disponibilità, dietro bilanciatori di carico sottoposti a controlli di integrità, con sostituzione automatica della capacità non integra. - Le distribuzioni usano aggiornamenti in sequenza con rollback automatico, così un rilascio fallito non interrompe il servizio. - Poiché l’API è *stateless*, il ripristino è solo una questione di capacità integra (non ci sono dati documentali da ripristinare) e un’interruzione in una regione non ha effetti sulle altre. ## Registrazione e monitoraggio Registriamo soltanto i metadati della richiesta (l’azione, il numero di byte, un hash della chiave API, lo stato e il timestamp) e **mai** il contenuto dei suoi documenti. I log oscurano credenziali e token. Metriche e allarmi dell’infrastruttura sorvegliano i tassi di errore, la latenza e lo stato degli host, così possiamo rilevare i problemi e intervenire rapidamente. ## Come i nostri controlli si mappano sui framework più diffusi L’API di PDF Blocks è progettata per allinearsi ai criteri valutati da framework formali come SOC 2 e ISO 27001. La tabella seguente riassume la corrispondenza tra i nostri controlli e i Trust Services Criteria di SOC 2: siamo lieti di illustrare a un revisore le evidenze alla base di ciascuno di essi. | Trust Services Criterion | Come vi risponde l’API di PDF Blocks | | --- | --- | | **Security** (criteri comuni) | TLS 1.3 in transito; web application firewall e rate limiting; reti private isolate senza accesso in uscita; chiavi API memorizzate come hash; accesso con privilegio minimo; scansione automatica delle vulnerabilità. | | **Availability** | Capacità ridondante su più zone di disponibilità, controlli di integrità, un’API multiregione e distribuzioni in sequenza con rollback automatico. | | **Confidentiality** | Documenti elaborati in memoria e mai memorizzati; crittografia in transito; segmentazione di rete rigorosa; obblighi di riservatezza per il personale e per i sub-responsabili. | | **Processing Integrity** | Operazioni deterministiche sui documenti; revisione tra pari, integrazione continua e test di contratto che condizionano ogni rilascio; gestione delle modifiche con distribuzione automatica sottoposta a controlli di integrità. | | **Privacy** | Nessuna conservazione dei documenti; documenti mai condivisi con alcun sub-responsabile; nessun utilizzo dei dati dei clienti per addestrare l’IA; residenza dei dati selezionabile per regione. | ## Sub-responsabili L’elaborazione dei documenti avviene su Amazon Web Services e Microsoft Azure. Il contenuto dei suoi documenti **non è condiviso con alcun sub-responsabile**: viene elaborato all’interno della nostra infrastruttura, nella regione a cui si rivolge. L’elenco completo dei sub-responsabili, con la finalità e la sede di ciascun fornitore, è mantenuto nella nostra pagina [Sub-responsabili](/docs/trust/subprocessors). ## Documentazione disponibile su richiesta I clienti e i potenziali clienti del **piano Business** possono richiedere, con un NDA reciproco, le nostre politiche di sicurezza interne (Sicurezza delle informazioni, Controllo degli accessi, Crittografia, Protezione e conservazione dei dati, Gestione delle vulnerabilità, Sviluppo sicuro, Risposta agli incidenti e Continuità operativa) e un questionario di sicurezza già compilato. Per iniziare, scrivere a [security@pdfblocks.com](mailto:security@pdfblocks.com). ## Segnalare una vulnerabilità Se ritiene di aver trovato una vulnerabilità di sicurezza in PDF Blocks, la preghiamo di segnalarla a [security@pdfblocks.com](mailto:security@pdfblocks.com). Accogliamo con favore la divulgazione coordinata, confermeremo la ricezione della sua segnalazione e le chiediamo di concederci una ragionevole possibilità di correggere il problema prima di qualsiasi divulgazione pubblica. I nostri recapiti leggibili da una macchina sono pubblicati su [/.well-known/security.txt](/.well-known/security.txt).