Perché il PPAP è dannoso per la sicurezza delle email e cosa fare invece

· Aggiornato il: · · Sicurezza email, PPAP, Prevenzione perdita dati, B2B, Riutilizzo asset legacy

“È davvero sicuro inviare uno ZIP protetto da password e poi mandare la password in una seconda email?” Questa domanda si presenta ancora regolarmente. In superficie sembra sicuro perché qualcosa è cifrato, ma in pratica è proprio lì la trappola.

La pratica conosciuta in Giappone come PPAP è debole come protezione contro l'intercettazione, insufficiente come protezione contro l'errore di destinatario e inoltre tende a ostacolare l'ispezione lungo il percorso di consegna — quindi è difficile raccomandarla sotto la pratica attuale di sicurezza delle email.1234

In questo articolo, basato su documenti del settore pubblico e fonti primarie verificabili ad aprile 2026, esaminiamo i problemi del PPAP e come appaiono le sostituzioni naturali in pratica.12536748910

1. Le conclusioni prima

Abbandonare il PPAP non significa abbandonare la cifratura. Ciò che va abbandonato è il design di “cifrare l’allegato come ZIP e poi inviare la password attraverso lo stesso canale email”.

Cosa considerare invece: queste tre cose.

  1. Per le email aziendali ordinarie, considerare la protezione del trasporto come TLS / STARTTLS.710
  2. Se serve autenticità o cifratura dell’email stessa, usare un meccanismo come S/MIME.536
  3. Per la consegna di file riservati, passare dagli allegati a download autenticati o condivisione con controllo degli accessi.489

In breve, ciò che conta è non cercare di risolvere ogni problema di email con la password di uno ZIP.

2. Cos’è il PPAP, in fondo?

Con PPAP qui si intende generalmente il flusso seguente.

  1. Mettere il file in uno ZIP protetto da password
  2. Inviare lo ZIP in una prima email
  3. Inviare la password in una seconda email

Questa pratica tende a essere interpretata come “sicura perché non inviamo in chiaro”. In realtà, però, la gamma di ciò che protegge effettivamente è piuttosto limitata.

Aspetto Il PPAP è sufficiente? Valutazione effettiva
Riservatezza sul percorso di trasporto Debole Inviare separatamente attraverso lo stesso canale email ha scarso effetto
Protezione contro email erronee Insufficiente L’incidente è sostanzialmente completo quando l’indirizzo è sbagliato
Protezione malware Attivamente dannoso Tende a ostacolare l’ispezione in percorso
Autenticità del mittente Non protetta Non è una misura anti-spoofing
Controllo di accesso Non protetto Controllo debole su chi può visualizzare il file

Il PPAP è molto meno universale di quanto sembri: appare “vagamente sicuro” pur fallendo nella protezione delle parti che contano.

3. Perché il PPAP è dannoso

3.1 Debole come protezione contro l’intercettazione

Il Governo giapponese ha concluso che inviare automaticamente la password attraverso lo stesso canale dello ZIP file non è un metodo appropriato.1 Il punto importante è che cifrare il file ha poco valore se il design non copre anche come viene consegnata la chiave.

Se si limita a inviare un seguito attraverso lo stesso ambiente email, nella stessa casella, allo stesso destinatario, l’insieme di chi può vedere lo ZIP e l’insieme di chi può vedere la password finiscono per essere quasi identici. Rimane solo il fatto di “aver cifrato”, con scarsa riservatezza reale dietro.

3.2 Insufficiente come protezione contro email erronee

Alcune operazioni considerano il PPAP una salvaguardia contro email al destinatario sbagliato, ma anche qui è debole.

L’IPA, nelle risposte pubblicate per l’esame di Ingegnere applicato dell’informazione, elenca come problema del PPAP che se l’email principale viene inviata a un destinatario errato, anche la password di decifratura raggiunge il destinatario sbagliato.3 Anche un documento dell’Agenzia per la Digitalizzazione conclude, in sostanza, che “inviarlo come email separata significa inviarlo alla stessa parte, quindi non funziona come controllo”.4

In altre parole, una volta che lo ZIP è andato al destinatario sbagliato, se poi si invia abitualmente anche la password, l’incidente si completa semplicemente. Ciò che serve davvero è un metodo di consegna che consenta verifica del destinatario, approvazione, revisione pre-invio e revoca o richiamo post-invio.

3.3 Ostacola l’ispezione dei malware

Questo è un punto sul PPAP che non va trascurato.

L’IPA ha avvertito, riguardo alle email di attacco Emotet con allegati ZIP protetti da password, che poiché l’allegato è cifrato, c’è un’alta probabilità che sfugga a rilevazione e quarantena da parte dei prodotti di sicurezza lungo il percorso di consegna email e arrivi al destinatario.2

Il mittente può credere di aver “reso le cose sicure cifrando”, ma dal punto di vista del ricevente e dei relay è diventato un allegato di cui è difficile ispezionare il contenuto. Anche su questo punto il PPAP non può essere definito un metodo che si integra bene con le difese email moderne.

3.4 Non garantisce né autenticità né controllo di accesso

Il PPAP non prova che il mittente sia autentico. Né fornisce un controllo di accesso significativo: chi ha scaricato cosa e quando, se l’accesso può essere revocato in seguito, se i permessi possono essere differenziati per destinatario.

Nel frattempo, l’IPA tratta le email con firma digitale come S/MIME, che si collegano contestualmente come alternativa al PPAP.56 E i materiali di sicurezza web dell’IPA concludono che i siti web che trattano informazioni non pubbliche hanno bisogno di autenticazione e controllo di accesso.8

Mettendo insieme questi due elementi, la risposta è piuttosto chiara.

  • Se si vuole autenticità delle email e rilevazione di manomissione: S/MIME
  • Se si vogliono permessi di visualizzazione e gestione della revoca per i file: download autenticati

Inviare la password dello ZIP separatamente non risolve in modo pulito nessuno dei due.

4. L’approccio corretto è “separare per scopo”

Il requisito “vogliamo inviare in sicurezza” in realtà non è un unico requisito. Se non lo si separa, il design collassa nel tentativo di coprire tutto con il PPAP.

4.1 Email aziendali ordinarie

Per le email aziendali ordinarie, la protezione del trasporto come TLS / STARTTLS è la linea di base.710 Oltre a ciò, se serve autenticità del mittente, rilevazione di manomissione o cifratura del corpo dell’email stessa, la mossa sensata è considerare S/MIME.536

4.2 Consegna di file riservati

Si vuole che il file arrivi solo alla persona destinata, che sia possibile controllare i permessi di visualizzazione, che si possa revocare in seguito. Per questi requisiti, i download autenticati o la condivisione con controllo degli accessi sono più naturali degli allegati.489

Per esempio, requisiti come i seguenti sono più facili da gestire sul lato web che tramite allegati.

  • Download disponibile solo dopo l’accesso
  • I link possono avere una scadenza
  • I permessi possono essere differenziati per destinatario
  • Dove necessario, è possibile tenere uno storico

4.3 Quando un allegato è davvero inevitabile

Ci sono situazioni in cui le circostanze dell’altra parte non lasciano alternative all’allegato. In quel caso, come indicato anche dalle linee guida del Governo giapponese, il minimo indispensabile è consegnare il file e la password attraverso canali del tutto separati.1

Ma questa è una soluzione temporanea, non una forma finale. Meglio pianificare di migrare progressivamente verso una condivisione autenticata.

5. Una procedura di sostituzione per le piccole imprese

Quando una piccola azienda abbandona il PPAP, chiarire prima la classificazione funziona meglio che introdurre subito un grande sistema.

5.1 Cosa fermare per prima

  • Cifratura automatica degli ZIP
  • Invio automatico separato della password attraverso lo stesso canale email
  • La regola generale “tutti i file importanti passano via PPAP”

5.2 Cosa decidere poi

  • Cosa può essere inviato per email normale
  • Cosa è vietato come allegato
  • Cosa viene instradato su download autenticati
  • Qual è la procedura di approvazione per gli allegati eccezionali

5.3 Pensare in termini di configurazione minima

All’inizio, bastano le due seguenti piste.

  1. Email ordinaria
    • Comunicazione aziendale
    • S/MIME dove necessario
  2. File riservati
    • Download autenticati
    • Impostazione dei permessi
    • Condivisione a tempo limitato

Se questo resta vago, sul campo si torna inevitabilmente a “PPAP, per sicurezza”.

6. Un flusso decisionale

NoNoNoCosa vuoi consegnareÈ un file altamente riservatoEmail aziendale ordinariaInvio assumendo TLS / STARTTLSSe importa autenticità o cifratura, S/MIMEIl destinatario può accedere con loginDownload autenticato / condivisione con controllo accessiImposta permessi, scadenza e revoca secondo necessitàL'allegato è davvero inevitabileFile cifrato + password manuale tramite canale separato

Ciò che conta in questo diagramma non è posizionare il PPAP come una soluzione universale di mezzo. Email e consegna file sono più facili da progettare se si ragiona separatamente.

7. Malintesi comuni

7.1 “Lo ZIP è cifrato, quindi è sicuro”

Anche con la cifratura, non è sufficiente se la consegna della chiave è debole. Inoltre, gli ZIP protetti da password possono ostacolare l’ispezione in percorso.12

7.2 “Inviarlo in una email separata è sufficiente”

Un seguito allo stesso destinatario attraverso lo stesso canale email non è un controllo robusto.14

7.3 “Se smettiamo di usare il PPAP, non possiamo più inviare allegati”

Non è vero. Si usa semplicemente lo strumento giusto per ogni caso: email ordinaria, S/MIME, download autenticati e password out-of-band per le eccezioni.

7.4 “S/MIME è per le grandi aziende e non è realistico”

Bisogna verificare il supporto dell’altra parte, ma al minimo è più coerente del PPAP rispetto a ciò che si sta cercando di proteggere. E per le controparti in cui S/MIME non si adatta, resta l’opzione dei download autenticati.

Ciò che rende il PPAP dannoso è che cifrare rende facile sentirsi al sicuro senza esserlo. In realtà, questi problemi restano:

  • L’invio separato attraverso lo stesso canale email fornisce una riservatezza debole
  • È insufficiente contro l’errore di destinatario
  • Gli ZIP protetti da password ostacolano l’ispezione in percorso
  • Non garantisce né autenticità del mittente né controllo di accesso

1234

Quindi la cosa da fare non è mantenere in vita le operazioni in stile PPAP con piccole modifiche. È proteggere le email come email, e progettare la consegna dei file come consegna di file.

In una frase:

Abbandonare il PPAP non significa abbandonare la cifratura — significa abbandonare il controllo sbagliato e sostituirlo con controlli adatti allo scopo.

Articoli correlati

Riferimenti

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Cos'è il PPAP nella sicurezza delle email?
Il PPAP è una pratica, nota soprattutto in Giappone, che consiste nel mettere un file in uno ZIP protetto da password, inviare lo ZIP in una prima email e poi inviare la password in una seconda email. Tende a essere considerata sicura perché niente viene inviato in chiaro, ma la gamma di ciò che protegge effettivamente è piuttosto limitata. È debole contro l'intercettazione, insufficiente contro email erronee, ostacola l'ispezione da parte di antivirus lungo il percorso di consegna, e non garantisce né autenticità del mittente né controllo di accesso.
Perché inviare la password dello ZIP in una seconda email non è sicuro?
Poiché il seguito transita sullo stesso canale email, nella stessa casella di posta e verso lo stesso destinatario, l'insieme di chi può vedere lo ZIP e l'insieme di chi può vedere la password finiscono per essere quasi identici. Il Governo giapponese ha concluso che inviare automaticamente la password attraverso lo stesso canale non è un metodo appropriato. Fallisce anche come salvaguardia contro l'errore di destinatario: se la prima email va a una persona sbagliata e poi si invia abitualmente anche la password, l'incidente si completa semplicemente.
Un allegato ZIP protetto da password protegge dai malware?
No — è addirittura dannoso su questo punto. L'IPA ha avvertito, riguardo alle email di attacco Emotet con allegati ZIP protetti da password, che poiché l'allegato è cifrato c'è un'alta probabilità che sfugga a rilevazione e quarantena da parte dei prodotti di sicurezza lungo il percorso di consegna email e arrivi al destinatario. Il mittente può credere che cifrare abbia reso le cose sicure, ma dal punto di vista del ricevente e dei relay è diventato un allegato di cui è difficile ispezionare il contenuto.
Cosa dovremmo usare al posto del PPAP?
Separare i requisiti per scopo invece di coprire tutto con la password di uno ZIP. Per le email aziendali ordinarie, considerare la protezione del trasporto come TLS o STARTTLS. Se serve autenticità del mittente, rilevazione di manomissione o cifratura dell'email stessa, usare S/MIME. Per la consegna di file riservati, passare dagli allegati a download autenticati o condivisione con controllo degli accessi, permessi, scadenza e revoca. Quando un allegato è davvero inevitabile, comunicare la password tramite un canale del tutto separato — ma trattarlo come una soluzione temporanea, non come pratica standard.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.

Torna al blog