LinkedIn
Instagram
WhatsApp
Telegramma
Calendario di Google
Partecipare alla comunità SlackCostruisci integrazioni email che i tuoi utenti possono fiducia
La connessione alle caselle di posta dei tuoi utenti comporta rischi reali per la sicurezza. Password memorizzate, ambiti OAuth eccessivamente ampi e token non ruotati creano superfici di attacco che minano la fiducia degli utenti e violano il GDPR.
Unipile's Guida all'API Email copre l'intero quadro di integrazione. Questo articolo si concentra sul livello di sicurezza: cosa deve garantire un'API di posta elettronica sicura, quali rischi evitare e come Unipile è architettata per proteggere i dati dei tuoi utenti per progettazione.
Gmail
Prospettiva
IMAP
Cosa Rende un'API Email "Sicura"?
La sicurezza in un'API di posta elettronica non è una singola funzionalità. È una scelta architetturale che abbraccia autenticazione, autorizzazione, gestione dei dati e infrastruttura. Un'API di posta elettronica sicura deve garantire quattro cose contemporaneamente.
Gli utenti autorizzano l'accesso tramite il flusso OAuth ufficiale del loro provider. Nessuna password lascia mai il server del provider o finisce nel tuo database.
Ogni account collegato richiede solo le autorizzazioni di cui ha effettivamente bisogno: sola lettura quando non è necessaria l'invio, ambito di invio solo quando è esplicitamente necessario.
Tutto il traffico API utilizza TLS 1.2+. I token memorizzati sono crittografati a riposo utilizzando AES-256. Il contenuto delle email non viene mai memorizzato oltre il ciclo di vita della richiesta.
OAuth 2.0 contro l'archiviazione di una password
La decisione di sicurezza più fondamentale in qualsiasi integrazione di posta elettronica è come autenticarsi. Molte integrazioni IMAP legacy chiedono agli utenti di inserire la propria password di posta elettronica e di memorizzarla. Questo approccio crea un unico punto di guasto: una violazione del database espone la casella di posta di ogni utente. OAuth 2.0 elimina completamente questo problema. Guarda come Google OAuth 2.0 e Microsoft OAuth 2.0 implementa questo flusso.
Ambiti del token: sola lettura vs. invio
LeOAuth scope definiscono esattamente cosa può fare la tua applicazione con la casella di posta di un utente. Richiedere ambiti ampi quando quelli più ristretti sarebbero sufficienti è un grave anti-pattern di sicurezza. Per un CRM che legge solo le email per registrare le attività, richiedere modifica gmail è superfluo e espone gli utenti a un rischio maggiore se il tuo token viene compromesso. Se la tua applicazione necessita di API per inviare email richieste, troverai anche una ripartizione completa degli ambiti richiesti per provider nella nostra guida API per l'invio di e-mail.
| Ambito | Fornitore | Ciò che permette | Livello di rischio |
|---|---|---|---|
| gmail.solodlettura | Gmail | Leggi solo email | Minimo |
| gmail.invia | Gmail | Invia per conto dell'utente | Mirato |
| Posta.Leggi | Prospettiva | Leggi solo email | Minimo |
| Mail.Send | Prospettiva | Invia per conto dell'utente | Mirato |
| https://mail.google.com/ | Gmail | Accesso completo alla casella di posta | Ampio |
| Mail.ReadWrite | Prospettiva | Leggere, scrivere, eliminare | Ampio |
Crittografia in transito e a riposo
Un'API di posta elettronica sicura impone TLS 1.2 o superiore su tutti gli endpoint API. Nessuna comunicazione in chiaro è accettabile. Oltre al transito, tutti i token o le credenziali che devono essere mantenuti persistenti, ad esempio i token di aggiornamento OAuth, devono essere crittografati a riposo utilizzando una cifratura simmetrica forte (AES-256). Altrettanto importante: il contenuto dell'email stesso non dovrebbe mai essere memorizzato oltre quanto richiesto dalla richiesta. La lettura e la visualizzazione di un'email nella tua interfaccia utente non richiedono la persistenza del suo corpo nel tuo database.
Rischi di sicurezza delle API di posta elettronica da evitare
La maggior parte dei fallimenti di sicurezza nell'integrazione delle e-mail non sono attacchi esotici, ma errori prevedibili nel modo in cui vengono gestite credenziali, token e dati. I quattro schemi seguenti rappresentano la maggior parte degli incidenti nel mondo reale nelle integrazioni di API di posta elettronica.
Chiedere agli utenti di inserire la loro password email e memorizzarla - anche crittografata - è il pattern a più alto rischio nell'integrazione email. Rende il tuo database un obiettivo di alto valore. Se un attaccante ottiene l'accesso al tuo archivio di credenziali, ottiene accesso diretto alla casella di posta di ogni utente. Oltre al rischio per la sicurezza, Google e Microsoft proibiscono esplicitamente l'accesso basato su password agli account Gmail e Outlook per app di terze parti. IMAP con password è accettabile solo per server di posta self-hosted o legacy dove OAuth non è realmente disponibile.
Richiesta https://mail.google.com/ (accesso completo a Gmail) quando è sufficiente leggere la cartella inviata di un utente è uno scope anti-pattern. Ampi scope aumentano il raggio d'azione di un compromesso di token e minano la fiducia degli utenti durante la schermata di consenso OAuth: gli utenti che vedono "leggi, componi, invia e elimina definitivamente tutte le tue email" sono giustificati nell'esitare. Sia Google che Microsoft ora segnalano l'uso non necessario di scope durante le revisioni delle app.
I token di accesso OAuth hanno una durata limitata per progettazione, solitamente un'ora per Gmail e Outlook. I token di aggiornamento possono persistere per mesi o indefinitamente. Se si archiviano token di aggiornamento senza una strategia di rotazione, un token di aggiornamento compromesso concede l'accesso a lungo termine alla casella di posta dell'utente. Alcune integrazioni memorizzano nella cache anche i token di accesso ben oltre la loro scadenza e non gestiscono correttamente gli eventi di revoca (quando un utente rimuove l'app dalle impostazioni dell'account Google o Microsoft).
I log delle applicazioni sono spesso meno protetti dei database primari, conservati più a lungo e replicati su più sistemi (aggregatori di log, servizi di monitoraggio, tracker di errori). La registrazione di interi corpi di email, intestazioni contenenti dati personali o elenchi di destinatari crea un'esposizione significativa al GDPR: si stanno elaborando dati personali in un contesto a cui l'utente non ha mai acconsentito e che non può essere verificato. I log di errore che includono risposte API grezze possono catturare involontariamente interi thread di email.
Conformità GDPR per integrazioni API di posta elettronica
I dati delle email sono tra le categorie di dati personali più sensibili ai sensi del GDPR. Quando la tua applicazione accede alla casella di posta di un utente tramite un'API, diventi un elaboratore di dati. Ciò crea obblighi legali concreti in merito a residenza, consenso ed eliminazione che la tua architettura API per le email deve supportare.
I dati personali UE devono rimanere all'interno dell'UE o in paesi con una decisione di adeguatezza. L'infrastruttura della tua API di posta elettronica deve offrire endpoint ospitati nell'UE.
Gli utenti devono autorizzare esplicitamente l'accesso alla loro casella di posta elettronica. La schermata di consenso OAuth deve dichiarare chiaramente quali dati verranno accessi e per quale scopo.
Quando un utente richiede la cancellazione o disconnette il proprio account, tutti i token associati, i dati memorizzati nella cache e i dati personali devono essere eliminati entro le tempistiche stabilite dal GDPR.
Residenza dei dati
Ai sensi dell'articolo 44 del GDPR, il trasferimento di dati personali al di fuori dello Spazio Economico Europeo richiede una decisione di adeguatezza, clausole contrattuali standard (SCC) o un altro meccanismo legale valido. Per le integrazioni di API di posta elettronica al servizio di utenti UE, l'infrastruttura che memorizza i token OAuth, elabora metadati di posta elettronica o memorizza nella cache il contenuto dei messaggi deve essere ospitata nell'UE. La scelta di un provider API senza opzioni di residenza dei dati nell'UE ti costringe a fare affidamento sulle SCC e comporta un ulteriore onere di conformità. Per i casi d'uso sanitari o finanziari in cui si applicano requisiti analoghi all'HIPAA, la residenza dei dati diventa ancora più critica.
Il tuo provider di API per le email è un sub-responsabile del trattamento ai sensi del GDPR. Devi avere un Accordo sul Trattamento dei Dati (DPA) in vigore con loro e la loro infrastruttura deve supportare la residenza dei dati nell'UE per tutti i dati degli utenti dell'UE che elaborano per tuo conto.
Flusso di consenso dell'utente
Il flusso di autorizzazione OAuth funge da implementazione tecnica del consenso GDPR per l'accesso alle email, ma solo se progettato correttamente. La schermata di consenso deve descrivere accuratamente ciò a cui l'applicazione accederà, in un linguaggio semplice. La richiesta di ambiti (scope) oltre a quanto descritto nella tua informativa sulla privacy crea una lacuna di conformità. Gli utenti devono inoltre essere in grado di completare questo flusso senza coercizione: la connessione del loro account email non deve essere una condizione forzata per l'accesso al tuo servizio principale, a meno che l'accesso alle email non sia effettivamente il servizio stesso.
Diritto alla cancellazione - disconnessione dell'account
L'articolo 17 del GDPR concede agli utenti il diritto alla cancellazione. In un contesto di integrazione via email, ciò significa che la tua applicazione deve essere in grado di rimuovere immediatamente e in modo completo ogni traccia dell'accesso email di un utente su richiesta. Non si tratta solo di eliminare il token OAuth, ma copre ogni artefatto creato durante il ciclo di vita dell'integrazione.
Come Unipile gestisce la sicurezza delle API di posta elettronica
La sicurezza non è una funzionalità che si aggiunge a Unipile: è il comportamento predefinito della piattaforma. Unipile è progettato specificamente per offrire un'API e-mail sicura, dove autenticazione, sicurezza dei dati e-mail e controlli di conformità sono integrati per impostazione predefinita, non aggiunti in un secondo momento. Ogni decisione architetturale su come Unipile si connette agli account Gmail, Outlook e IMAP viene presa con la sicurezza e la privacy degli utenti finali come vincolo primario.
Unipile si connette a Gmail tramite Google OAuth 2.0 e Outlook e Microsoft 365 tramite Microsoft OAuth 2.0. I tuoi utenti si autenticano direttamente tramite la schermata di consenso ufficiale del provider. Nessuna password passa mai attraverso l'infrastruttura di Unipile. Per gli account IMAP dove OAuth non è disponibile, le credenziali sono crittografate a riposo con AES-256 e non vengono mai esposte tramite alcuna risposta API, inclusa la Guida all'API IMAP copre questa architettura nel dettaglio.
Unipile richiede gli ambiti OAuth più ristretti necessari per le funzionalità abilitate dalla tua applicazione SaaS. Se la tua integrazione legge solo le email per popolare un feed di attività CRM, Unipile richiede ambiti di sola lettura. L'invio di un ambito viene aggiunto solo quando la tua implementazione lo richiede esplicitamente. Ciò riduce il raggio d'azione di eventuali problemi di credenziali e rende la schermata di consenso OAuth della tua app di facile approvazione per gli utenti finali.
Per i team SaaS che servono clienti UE, Unipile offre opzioni di infrastruttura ospitate in UE. I token OAuth, i metadati degli account collegati e qualsiasi dato di posta elettronica elaborato in modo transitorio rimangono sotto la giurisdizione UE. Ciò consente di mantenere un registro pulito dell'elaborazione dei dati GDPR e di stipulare un Accordo sul Trattamento dei Dati con Unipile come sub-processore, un requisito legale ai sensi dell'Articolo 28 del GDPR per qualsiasi processore che gestisce dati personali UE per vostro conto.
Unipile espone un endpoint DELETE per gli account collegati. Chiamarlo revoca immediatamente il token OAuth a livello di provider, elimina tutti i metadati associati dall'infrastruttura di Unipile e annulla tutte le sottoscrizioni webhook attive. Ciò ti fornisce un percorso pulito, con una singola chiamata API, per soddisfare le richieste di "diritto all'oblio" del GDPR relative all'accesso via email, senza richiedere alcuna pulizia manuale su più dashboard di provider.
Leggi il riferimento completo dell'API - flussi di autenticazione, gestione dei token e sicurezza degli webhook.
Certificazioni di conformità
Unipile è sottoposta a audit certificati indipendenti secondo i tre quadri normativi più pertinenti per le integrazioni sicure di API di posta elettronica: operazioni di sicurezza, protezione dei dati e accesso alle API di Google.
Verificato da una terza parte indipendente. Copre i criteri di affidabilità per sicurezza, disponibilità e riservatezza relativi all'infrastruttura di Unipile'.
Piena conformità alle normative UE sulla protezione dei dati. Unipile agisce come Data Processor. Tutti i dati ospitati esclusivamente nell'UE. DPA disponibile su richiesta.
Valutazione della sicurezza delle applicazioni Google Cloud. Valida i controlli di sicurezza per le applicazioni che accedono ai dati degli utenti Google, inclusi gli ambiti OAuth di Gmail.
Quando costruisci su Unipile, la tua integrazione di posta elettronica sicura beneficia degli stessi controlli di sicurezza che hanno superato questi audit. Ciò è particolarmente rilevante per CASA Tier II: le app costruite sopra un'API di posta elettronica sicura certificata CASA possono mantenere il proprio stato di conformità lungo l'intera catena di integrazione, senza un audit separato del livello di posta elettronica.
Lista di controllo per la sicurezza dell'integrazione API email
Usa questa checklist prima di distribuire in produzione qualsiasi integrazione con API di posta elettronica. Tutti gli elementi devono essere convalidati prima che l'integrazione possa essere considerata pronta per la produzione dal punto di vista della sicurezza.
OAuth 2.0, ambiti minimi, residenza dei dati nell'UE, disconnessione istantanea dell'account: tutto incluso in una singola API di posta elettronica sicura. Collega Gmail, Outlook e IMAP con accesso crittografato alle email e archiviazione password inesistente.
API Email Sicura - Domande frequenti
Domande comuni sulla sicurezza delle API email, OAuth e conformità
L'IMAP può essere sicuro, ma dipende interamente dall'implementazione. Il protocollo stesso trasmette dati tramite TLS se configurato correttamente, quindi il livello di transito non è il problema. Il rischio risiede nella gestione delle credenziali. L'IMAP richiede un nome utente e una password - a differenza di Gmail e Outlook che supportano OAuth 2.0, l'IMAP non ha uno standard di autorizzazione delegata. Ciò significa che la tua applicazione deve archiviare o recuperare la password dell'utente ogni volta che si connette. Ciò è gestibile se le credenziali sono crittografate a riposo con AES-256, l'accesso allo store delle credenziali è strettamente limitato e le password non vengono mai registrate o esposte tramite risposte API. Per Gmail e Outlook, preferisci sempre OAuth 2.0 rispetto all'IMAP con password - entrambi i provider lo richiedono per applicazioni di terze parti. L'IMAP con password è appropriato solo per server di posta auto-ospitati o ambienti aziendali legacy in cui OAuth non è realmente disponibile. Leggi di più nella Guida all'API IMAP.
La conformità HIPAA per un'integrazione API di posta elettronica è possibile, ma richiede un'architettura accurata. L'HIPAA non certifica i provider di posta elettronica, ma richiede che qualsiasi sistema che gestisce informazioni sanitarie protette (PHI) implementi specifiche misure di salvaguardia tecnica: crittografia in transito e a riposo, controlli di audit, controlli di accesso e disattivazione automatica delle sessioni inattive. Per un'API di posta elettronica, ciò significa: utilizzare OAuth 2.0 in modo da non memorizzare password, garantire che i token e qualsiasi metadato memorizzato nella cache siano crittografati a riposo, non registrare mai i contenuti delle e-mail che potrebbero contenere informazioni sanitarie protette e avere un accordo con il fornitore di API (Business Associate Agreement). Gmail e Outlook offrono entrambi configurazioni idonee all'HIPAA nell'ambito dei piani Google Workspace e Microsoft 365 Business rispettivamente, con un BAA firmato dal provider. Anche il vostro livello API di posta elettronica deve firmare un BAA con voi se elabora o trasmette PHI per vostro conto. Da un punto di vista pratico, la strada più sicura per l'HIPAA è quella di trattare il contenuto delle e-mail come transitorio - leggerlo, elaborarlo, visualizzarlo - ma non conservare mai il corpo o gli allegati nel proprio database.
Revocare l'accesso all'email di un utente comporta due azioni distinte che devono entrambe verificarsi. Innanzitutto, revoca il token a livello del provider. Per Gmail, chiama l'endpoint di revoca dei token di Google (https://oauth2.googleapis.com/revoke). Per Outlook, chiama l'endpoint di revoca di Microsoft o rimuovi l'app dall'account Microsoft dell'utente. Eliminare semplicemente il token dal tuo database non è sufficiente: il token rimane valido presso il provider finché non viene esplicitamente revocato. Secondo, elimina tutti i dati locali. Elimina il token di aggiornamento, eventuali token di accesso memorizzati nella cache, tutti i metadati delle email archiviati per quell'account collegato, le sottoscrizioni webhook e il record dell'account collegato stesso. Con Unipile, un singolo ELIMINA /accounts/{id} la chiamata esegue entrambi i passaggi: revoca il token presso il provider e cancella contemporaneamente tutti i dati associati sull'infrastruttura di Unipile.
La sicurezza delle e-mail si riferisce in genere alla protezione della comunicazione e-mail stessa: filtro antispam, rilevamento di phishing, autenticazione DKIM/SPF/DMARC e crittografia del messaggio in transito tra i server di posta. La sicurezza delle API di posta elettronica è un livello completamente diverso: riguarda come un'applicazione di terze parti ottiene l'accesso programmatico alla casella di posta di un utente, quali dati gestisce di conseguenza e come protegge tale accesso. È possibile avere un'eccellente sicurezza delle e-mail (DMARC configurato, TLS applicato tra i server) pur avendo una scarsa sicurezza delle API di posta elettronica (password memorizzate in chiaro, ambiti OAuth eccessivamente ampi). Entrambi sono importanti indipendentemente. Questo articolo si concentra sul livello di sicurezza delle API: le decisioni architetturali che il tuo team di sviluppo prende quando si integra con Gmail, Outlook o IMAP tramite un'API.
Unipile non memorizza in modo persistente il contenuto delle email. Quando la tua applicazione chiama l'API Unipile per recuperare le email, Unipile recupera i dati dal provider (server Gmail, Outlook o IMAP) in tempo reale e li restituisce alla tua applicazione. I corpi delle email e gli allegati non vengono memorizzati nella cache o archiviati sull'infrastruttura Unipile oltre il ciclo di vita della richiesta. Ciò che Unipile memorizza è il token OAuth (crittografato a riposo) e i metadati di base dell'account collegato necessari per mantenere la connessione: tipo di provider, identificatore dell'account e stato della connessione. Questa architettura significa che il contenuto delle email rimane tra la tua applicazione e il provider, con Unipile che funge da intermediario sicuro piuttosto che da archivio dati. Per dettagli completi su come Unipile gestisce i dati, fare riferimento a documentazione per sviluppatori e richiedere un DPA al team Unipile.
OAuth 2.0 migliora la sicurezza dell'integrazione email in quattro modi concreti. Nessuna esposizione di credenziali: la password dell'utente non lascia mai il server del provider - la tua applicazione riceve solo un token di accesso di breve durata. Permessi granulari: Gli ambiti OAuth ti consentono di richiedere esattamente l'accesso di cui hai bisogno (sola lettura, solo invio) anziché il controllo completo della casella di posta. Revocabilità: un utente può rimuovere l'accesso della tua applicazione dalle impostazioni del proprio account Google o Microsoft in qualsiasi momento, senza cambiare la password, e il token diventa immediatamente non valido. Token di breve durata: i token di accesso scadono (tipicamente dopo un'ora), limitando la finestra di esposizione qualora un token venga compromesso. Queste proprietà rendono OAuth 2.0 l'unico meccanismo di autenticazione accettabile per le integrazioni di Gmail e Outlook nelle applicazioni SaaS in produzione. Scopri come implementarlo per Google OAuth 2.0 e Microsoft OAuth 2.0.
Avete ancora domande? Il nostro team è qui per aiutarvi.
IT 
EN 
FR 
ES 
DE 
BR 
NL 
PL 
TR