Uno strumento di firma può leggere le vostre email? La risposta tecnica
A seconda della sua architettura, uno strumento di firma accede o meno al contenuto dei vostri messaggi. La differenza tra add-in lato client, regola di trasporto e relay SMTP, spiegata per una revisione di sicurezza.
- Esistono tre architetture, e non hanno lo stesso perimetro di accesso.
- Un add-in lato client scrive nel messaggio in fase di composizione, senza leggerlo né archiviarlo.
- Una regola di trasporto lascia il messaggio all'interno del vostro server di posta, senza transito presso il fornitore.
- Un relay SMTP fa transitare le vostre email da una terza parte: è il caso da esaminare con attenzione.
È la prima domanda di una revisione di sicurezza, ed è legittima: uno strumento che interviene sulle vostre email ha accesso al loro contenuto? La risposta dipende interamente dall’architettura adottata, e le tre architetture presenti sul mercato non hanno lo stesso perimetro.
Architettura 1 — L’add-in lato client
L’add-in viene eseguito nel client di posta, nel momento in cui l’utente scrive il messaggio. Inserisce un blocco HTML nel corpo del messaggio in corso.
Il perimetro di accesso corrisponde alle autorizzazioni dichiarate nel manifest dell’add-in: la scrittura nell’elemento in fase di composizione e la lettura degli attributi della directory necessari per compilare i campi.
Ne derivano due proprietà, ed è su queste che si gioca una revisione di sicurezza:
Il messaggio non transita dal fornitore. L’inserimento avviene sulla postazione, nella finestra di composizione. Il messaggio parte poi dal vostro tenant Microsoft o Google verso il destinatario, attraverso il routing abituale, senza deviazioni.
La casella di posta non viene letta. L’add-in interviene su un messaggio in fase di composizione, non sulla posta in arrivo, sulla cronologia o sugli archivi.
È l’architettura di Signally, descritta nella pagina add-in Microsoft 365.
Architettura 2 — La regola di trasporto
La firma viene aggiunta dal vostro stesso server di posta — Exchange Online, dove si parla di regola del flusso di posta, oppure il servizio di conformità di Google Workspace — durante l’instradamento.
In questo caso il fornitore non interviene affatto nel trattamento del messaggio: fornisce il contenuto del piè di pagina, il vostro server lo applica. Nessun accesso, nessun transito.
In compenso, questa architettura ha limiti funzionali importanti — il mittente non vede mai la propria firma, le conversazioni accumulano blocchi, i messaggi cifrati sfuggono alla regola — illustrati in add-in o regola di trasporto.
Architettura 3 — Il relay SMTP
È quella che richiede un esame attento. Il messaggio lascia il vostro server, transita dall’infrastruttura del fornitore che vi aggiunge la firma, quindi riparte verso il destinatario.
Questa architettura implica per costruzione che l’intero contenuto dei vostri messaggi passi da una terza parte — corpo, allegati, destinatari. Implica inoltre una modifica del routing in uscita, con le relative conseguenze sulla deliverability e sulla configurazione SPF e DKIM.
Non è illegittima in sé, e alcuni fornitori la implementano con serietà. Ma cambia la natura della domanda posta al vostro responsabile della sicurezza: non si tratta più di autorizzare un componente, ma di inserire una terza parte nella catena di instradamento.
Come verificare, anziché fidarsi
Tre verifiche concrete, che non si basano sulla parola del fornitore.
La schermata di consenso. Al momento della connessione del tenant, il vostro provider di identità — Microsoft Entra ID o Google — mostra l’elenco esatto delle autorizzazioni richieste. Questo elenco proviene da Microsoft o da Google, non dal fornitore. È la prova più diretta del perimetro.
La documentazione delle API. Le autorizzazioni richieste corrispondono a scope documentati pubblicamente da Microsoft e Google. È possibile verificare cosa copre ciascuno di essi.
La configurazione del routing. Se l’installazione richiede di modificare i connettori, i record MX o l’SPF, si tratta di un’architettura a relay. Se non tocca nulla del routing, no.
Buono a sapersi: fate acquisire uno screenshot della schermata di consenso durante l’installazione e allegatelo al fascicolo di sicurezza. È una prova datata e documentale, che vale più di un impegno commerciale.
Il perimetro del rischio residuo
Nessuno strumento ha un rischio nullo, ed è più onesto delimitare il rischio che negarlo.
Con un add-in, ciò che un attaccante otterrebbe in caso di compromissione del fornitore sono i dati detenuti: la directory sincronizzata — nomi, qualifiche, numeri di telefono aziendali — e i modelli. Non il contenuto dei messaggi, che non è mai stato accessibile.
È una differenza di natura, non di grado. La fuga di una directory aziendale è un incidente serio; quella della cronologia delle email di un’organizzazione è tutt’altra cosa.
La localizzazione e la giurisdizione applicabili a questi dati detenuti sono l’altra metà del fascicolo, trattata in sovranità dei dati.
La sintesi da trasmettere al vostro responsabile della sicurezza
Per l’architettura add-in bastano quattro righe:
- La firma viene inserita in fase di scrittura, lato client, nel messaggio in corso.
- Nessun contenuto email viene letto, analizzato, archiviato o fatto transitare dal fornitore.
- Gli unici dati sincronizzati sono gli attributi della directory visualizzati nella firma.
- Nessuna modifica del routing in uscita: nessun connettore, nessun relay, nessuna modifica dell’SPF.
Questi elementi e il dettaglio di ciò che Signally non fa si trovano nella nostra pagina sicurezza e GDPR, pensata per essere inoltrata così com’è a un reparto IT.
Domande frequenti
Un add-in può leggere il contenuto delle mie email?
Come si verifica cosa richiede davvero un add-in?
Le mie email transitano dai server del fornitore?
Cosa succede se lo strumento viene compromesso?
Distribuite la vostra firma con Signally
Create il vostro modello gratuitamente, poi distribuitelo a tutta l'organizzazione dalla vostra console di amministrazione.
Crea la mia firma