Opzioni di trasporto nelle distribuzioni ibride di Exchange

Una distribuzione ibrida contiene cassette postali in un'organizzazione di Exchange locale e anche in un'organizzazione di Exchange Online. Per ulteriori informazioni sull'ambiente ibrido, vedere Distribuzioni ibride di Exchange Server.

Una componente fondamentale per far apparire queste due organizzazioni separate come una sola è il trasporto ibrido. I messaggi inviati tra destinatari in entrambe le organizzazioni vengono autenticati, crittografati e trasferiti tramite TLS (Transport Layer Security). Questi messaggi vengono visualizzati come "interni" ai componenti di Exchange, ad esempio come regole di trasporto, inserimento nel journal e criteri di protezione dalla posta indesiderata. La Configurazione guidata ibrida configura automaticamente il trasporto ibrido in Exchange 2013.

Affinché il trasporto ibrido funzioni con la Configurazione guidata ibrida, l'endpoint SMTP locale che accetta connessioni da Exchange Online deve essere uno dei seguenti server Exchange:

• Exchange 2016 aggiornamento cumulativo 8 (CU8) o versione successiva:
  • Server Cassette postali
  • Server Trasporto Edge.
• Aggiornamento cumulativo 15 (CU15) di Exchange 2013 o versione successiva:
  • Server Accesso client.
  • Server Trasporto Edge.
• Exchange 2010 Service Pack 3 (SP3) con aggiornamento cumulativo 11 (RU11) o versione successiva:
  • Server Trasporto Hub.
  • Server Trasporto Edge.

Importante

Non inserire host o servizi SMTP tra Microsoft 365 e l'endpoint dell'organizzazione di Exchange locale. Le informazioni critiche per il trasporto ibrido vengono rimosse dai messaggi che passano attraverso un endpoint che esegue una versione non supportata di Exchange o un host SMTP generico.

Opzioni di routing ibrido

Quando si pianifica e si configura la distribuzione ibrida, è necessario scegliere come instradare la posta in ingresso e in uscita:

• Si vuole instradare la posta in ingresso da mittenti Internet esterni a destinatari locali e cloud tramite Microsoft 365 o tramite l'organizzazione di Exchange locale? La configurazione dipende da vari fattori:

  • La maggior parte delle cassette postali si trova nel cloud o in Exchange locale?
  • Si vuole usare il componente aggiuntivo per la sicurezza predefinita per le cassette postali locali per proteggere l'organizzazione di Exchange locale?
  • Dove è configurata l'infrastruttura di conformità?

  Il percorso per i messaggi in entrata verso entrambe le organizzazioni dipende dall'abilitazione del trasporto centralizzato della posta nella distribuzione ibrida.

• Si desidera instradare la posta in uscita da mittenti di Exchange Online a destinatari esterni attraverso l'organizzazione locale (trasporto centralizzato della posta) o direttamente a Internet?

  Il trasporto centralizzato della posta instrada tutta la posta dai mittenti di Exchange Online attraverso l'organizzazione locale prima della consegna a Internet. Questo approccio è importante negli scenari di conformità in cui i server locali devono elaborare tutta la posta inviata da e verso Internet. In alternativa, è possibile inviare messaggi da mittenti di Exchange Online a destinatari esterni direttamente su Internet.

  Nota

  È consigliabile centralizzare il trasporto della posta solo per le organizzazioni con esigenze di trasporto specifiche relative alla conformità. In genere, è consigliabile non usare il trasporto centralizzato della posta a causa dell'aumento della larghezza di banda e del sovraccarico di elaborazione della posta nell'organizzazione locale.

• Si desidera distribuire un server Trasporto Edge nell'organizzazione locale?

  Se non si desidera esporre i server Exchange interni aggiunti al dominio direttamente a Internet, è possibile distribuire i server Trasporto Edge supportati nella rete perimetrale. Per ulteriori informazioni, vedere Server Trasporto Edge con distribuzioni ibride.

Indipendentemente dalla selezione, tutti i messaggi inviati tra l'organizzazione di Exchange locale e l'organizzazione di Exchange Online usano il trasporto sicuro. Per altre informazioni, vedere Comunicazione attendibile più avanti in questo articolo.

Per ulteriori informazioni sull'effetto di queste opzioni sul routing dei messaggi nell'organizzazione, vedere Transport routing nelle distribuzioni ibride di Exchange.

Funzionalità di sicurezza cloud integrate nelle distribuzioni ibride

Tutte le organizzazioni cloud Microsoft con cassette postali cloud includono funzionalità di sicurezza integrate per proteggere i destinatari da virus, posta indesiderata, tentativi di phishing e violazioni dei criteri. Queste stesse funzionalità di sicurezza integrate sono disponibili anche per proteggere gli ambienti di posta elettronica locali (non solo Exchange) nel componente aggiuntivo per la sicurezza integrata per le cassette postali locali.

Le funzionalità di sicurezza integrate per tutte le cassette postali cloud sono la porta d'ingresso per l'organizzazione di Exchange Online. Tutti i messaggi in arrivo, indipendentemente dalla loro origine, passano attraverso queste funzionalità di sicurezza integrate prima di raggiungere i destinatari nell'organizzazione cloud. Tutti i messaggi inviati dall'organizzazione di Exchange Online passano attraverso queste funzionalità di sicurezza integrate prima di raggiungere Internet.

Comunicazione attendibile

Il flusso di posta tra l'organizzazione locale e l'organizzazione di Exchange Online è configurato per l'utilizzo di TLS forzato. Questa configurazione garantisce che i messaggi inviati tra le organizzazioni non vengano intercettati. Il trasporto sicuro della posta usa certificati TLS forniti da un'autorità di certificazione (CA) commerciale attendibile.

Nel trasporto TLS forzato, i server di invio e ricezione esaminano i certificati l'uno dell'altro. Il campo Subject o Subject Alternative Name (SAN) del certificato deve contenere il nome di dominio completo che identifica l'altro server.

Ad esempio, l'organizzazione Exchange Online è configurata per accettare e proteggere i messaggi inviati dal mail.contoso.com FQDN. Il certificato TLS nel server Accesso client locale o nel server Trasporto Edge di origine deve contenere mail.contoso.com nel campo Soggetto o Nome alternativo soggetto (SAN). In caso contrario, Microsoft 365 rifiuta la connessione.

Consiglio

Non è necessario che il nome di dominio completo corrisponda al nome del dominio di posta elettronica dei destinatari. Il campo Soggetto o Nome alternativo soggetto (SAN) del certificato deve contenere il nome di dominio completo che i server di ricezione o invio sono configurati per accettare.

Oltre a usare TLS, i messaggi tra le organizzazioni locali e cloud vengono trattati come "interni". Questo approccio consente ai messaggi di ignorare alcuni filtri di protezione dalle minacce e altri servizi.

Per altre informazioni, vedere Requisiti dei certificati per le distribuzioni ibride e Informazioni sui certificati TLS.