Informazioni sulle protezione VoIP per la Messaggistica unificata
Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Ultima modifica dell'argomento: 2016-11-28
Un aspetto importante della protezione di rete è la possibilità di proteggere l'infrastruttura di messaggistica unificata. All'interno dell'ambiente di messaggistica unificata esistono componenti da configurare correttamente per agevolare la protezione dei dati inviati e ricevuti dai server Messaggistica unificata sulla rete. Esempi di questi componenti sono i server Messaggistica unificata e i dial plan. In questo argomento viene descritto come aumentare la protezione di dati e server della rete di messaggistica unificata nell'organizzazione. Per agevolare la protezione dell'ambiente di messaggistica unificata e abilitare la protezione VoIP, procedere come segue:
Installare il ruolo del server Messaggistica unificata.
Creare un nuovo certificato autofirmato o pubblico da utilizzare per il Mutual TLS.
Associazione di un certificato al server Messaggistica unificata.
Configurare il dial plan di messaggistica unificata come dial plan SIP con protezione o protetto.
Configurazione della modalità di avvio su un server Messaggistica unificata.
Associare i server Messaggistica unificata al dial plan di messaggistica unificata.
Configurare i gateway IP di messaggistica unificata utilizzati in modo che abbiamo un nome di dominio completo (FQDN, fully qualified domain name) e utilizzino la porta TCP 5061.
Esportare e importare i certificati necessari per consentire ai server Messaggistica unificata, ai gateway IP, ai PBX (Private Branch eXchange) IP e ad altri server che eseguono Microsoft Exchange Server 2010 l'utilizzo di Mutual Transport Layer Security (Mutual TLS).
Sommario
Protezione della messaggistica unificata
Tipi di certificati
Configurazione di Mutual TLS
IPsec
Dial plan di messaggistica unificata e protezione VoIP
Come la messaggistica unificata determina la modalità di protezione e seleziona i certificati
Protezione della messaggistica unificata
Sono disponibili diversi metodi di protezione dei server Messaggistica unificata e del traffico di rete inviato tra i gateway IP e i server Messaggistica unificata, nonché tra i server Messaggistica unificata e altri server Exchange 2010 nell'organizzazione. La tabella seguente elenca alcune possibili minacce per l'infrastruttura di messaggistica unificata e i metodi di protezione che è possibile implementare.
Protezione della messaggistica unificata
| Possibile minaccia | Metodo di protezione |
|---|---|
Monitoraggio del traffico vocale |
|
Attacco a un gateway IP o a un PBX IP |
|
Chiamate su lunghe distanze non autorizzate |
|
Attacco Denial of Service |
|
Rappresentazione proxy di Session Initiation Protocol (SIP) |
|
Intercettazione telefonica e dirottamento di sessione |
|
Diversi metodi di protezione elencati nella tabella precedente consentono di proteggere l'ambiente di messaggistica unificata. Uno dei meccanismi più importanti per la protezione dell'infrastruttura di messaggistica unificata e del traffico di rete generato dalla messaggistica unificata è Mutual TLS.
È possibile utilizzare Mutual TLS per crittografare il traffico Voice over IP (VoIP) tra i gateway IP, i PBX IP, gli altri server Exchange 2010 e i server Messaggistica unificata sulla rete. La scelta migliore per la protezione di questi dati è l'utilizzo di Mutual TLS per la crittografia dei dati VoIP.
Tuttavia, a seconda della minaccia al sistema di protezione, è inoltre possibile configurare criteri IPsec per abilitare la crittografia dati tra i gateway IP o i PBX IP e un server Messaggistica unificata oppure tra un server Messaggistica unificata e altri server Exchange 2010 sulla rete. In alcuni ambienti, potrebbe non essere possibile utilizzare IPsec perché non disponibile o non supportato dai gateway IP o dai PBX IP. IPsec, inoltre, aggiunge un ulteriore carico di elaborazione alle risorse del sistema sui server Messaggistica unificata. Considerando questi due fattori, Mutual TLS è la scelta migliore per la protezione del traffico di rete VoIP nell'ambiente di messaggistica unificata.
Dopo aver implementato e configurato correttamente Mutual TLS, il traffico SIP tra i gateway IP, i PBX IP, gli altri server Exchange e i server Messaggistica unificata viene crittografato. Tuttavia, quando non è possibile utilizzare Mutual TLS per agevolare la protezione del traffico inviato o ricevuto da un server Messaggistica unificata, ad esempio quando un server Messaggistica unificata comunica con un altro server in rete quale un controller di dominio Active Directory o un server Cassette postali di Exchange 2010, per proteggere i dati vengono utilizzati altri tipi di crittografia. Nella figura seguente sono riportati i metodi di crittografia disponibili per la protezione della messaggistica unificata.
Protezione VoIP per la messaggistica unificata
Inizio pagina
Tipi di certificati
I certificati digitali sono file elettronici che funzionano come un passaporto in linea per verificare l'identità di un utente o di un computer e sono utilizzati per creare un canale crittografato utilizzato per la protezione dei dati. Un certificato è fondamentalmente una dichiarazione digitale emessa da un'autorità di certificazione (CA, Certification Authority) che si fa garante dell'identità del titolare del certificato e consente a terzi di comunicare in modo sicuro utilizzando la crittografia. I certificati possono essere emessi da una CA di terze parti attendibile, quali Servizi certificati, oppure possono essere autofirmati. Ogni tipo di certificato ha i suoi vantaggi e svantaggi. Tuttavia, i certificati sono sempre inalterabili e non possono essere contraffatti. È possibile emettere certificati per svariate funzioni, ad esempio l'autenticazione utente Web, l'autenticazione server Web, S/MIME, IPsec, TLS e la firma del codice.
Un certificato associa una chiave pubblica all'identità della persona, del computer o del servizio che possiede la chiave privata corrispondente. La chiave pubblica e quella privata sono utilizzate dal client e dal server per crittografare i dati prima di trasmetterli in rete. I certificati sono utilizzati per svariati servizi e applicazioni di protezione a chiave pubblica che forniscono autenticazione, integrità dei dati e comunicazioni protette su reti quali Internet. Per utenti, computer e servizi basati su Windows, l'attendibilità di una CA viene stabilita quando c'è una copia del certificato radice nell'archivio certificati radice attendibili e il certificato contiene un percorso di certificazione valido. Ciò significa che nel percorso di certificazione nessun certificato è stato revocato o è scaduto.
I certificati digitali eseguono le seguenti operazioni:
Garantiscono che i titolari, ossia persone, siti Web e anche risorse di rete quali i router, siano effettivamente chi o cosa dichiarano di essere.
Proteggono i dati scambiati in linea da furto o manomissione.
In genere sono disponibili tre opzioni o tipi di certificati per la messaggistica unificata e i gateway IP o i PBX IP. In tutti e tre gli approcci o opzioni, la chiave pubblica del titolare del certificato è parte del certificato stesso, in modo che il server, l'utente, il sito Web o altre risorse dall'altra parte siano in grado di decrittografare i messaggi. Solo il firmatario del certificato conosce la chiave privata. Su ogni certificato è impostato un attributo EnhancedKeyUsage per stabilire l'utilizzo specifico del certificato. Ad esempio, è possibile specificare l'utilizzo solo per l'autenticazione del server o con EFS (Encrypting File System). La messaggistica unificata utilizza il certificato per l'autenticazione dei server e la crittografia dei dati.
Certificati autofirmati
Un certificato autofirmato viene firmato dal suo stesso autore. L'oggetto e il nome del certificato corrispondono. Per i certificati autofirmati, l'emittente e l'oggetto sono definiti nel certificato. I certificati autofirmati non richiedono la presenza di una CA dell'organizzazione o di terzi. Occorre configurare esplicitamente questi certificati e copiarli nell'archivio certificati radice attendibili di ogni gateway IP, PBX IP, server Messaggistica unificata e computer Exchange 2010 affinché il server Messaggistica unificata che ha emesso il certificato sia in grado di considerarli attendibili.
Se non è disponibile un certificato di terzi o basato sull'infrastruttura a chiave pubblica (PKI), il server Messaggistica unificata cercherà un certificato autofirmato nell'archivio certificati locale. Se non trova un certificato PKI o di terze parti, genererà un certificato autofirmato per Mutual TLS. Tuttavia, poiché il certificato è autofirmato, non sarà ritenuto attendibile dai gateway IP, dai PBX IP in rete o dagli altri server in rete. Per garantire che il certificato autofirmato sia ritenuto attendibile dai gateway IP, dai PBX IP o dagli altri server, occorre importare il certificato autofirmato nell'archivio certificati radice attendibili locale dei dispositivi e dei server. Dopo aver eseguito questa operazione, quando il server Messaggistica unificata presenta il certificato autofirmato al gateway IP, al PBX IP o al server, sarà in grado di verificare che il certificato sia stato emesso da un'autorità attendibile perché l'emittente sarà uguale all'oggetto definito sul certificato autofirmato.
Se si utilizzano solo certificati autofirmati, occorre importare un singolo certificato autofirmato per ogni gateway IP, PBX IP o server. In ambienti di rete di grandi dimensioni con più dispositivi o computer, questa potrebbe non essere la soluzione migliore per l'implementazione di Mutual TLS. L'utilizzo di certificati autofirmati in reti aziendali di grandi dimensioni non consente una buona scalabilità a causa dell'ulteriore sovraccarico amministrativo. Il sovraccarico amministrativo, tuttavia, non è un problema se si dispone di più dispositivi e si utilizza un certificato PKI o commerciale di terze parti. Ogni dispositivo è dotato infatti di un certificato emesso dalla stessa autorità radice attendibile. Il certificato emesso dalla stessa autorità radice attendibile garantisce che tutti i gateway IP, i PBX IP e gli altri server riconoscano come attendibile il server Messaggistica unificata.
Per il funzionamento di Mutual TLS con i certificati autofirmati:
Importare il certificato autofirmato del server Messaggistica unificata nell'archivio certificati radice attendibili di ogni gateway IP, PBX IP e degli altri server utilizzati, ad esempio i server Accesso client e i server che comunicheranno con il server Messaggistica unificata mediante Mutual TLS.
Importare il certificato autofirmato di ogni gateway IP, PBX IP e degli altri server nell'archivio certificati radice attendibili del server Messaggistica unificata. Se si utilizza un certificato PKI o di terze parti, importare il certificato dell'autorità di certificazione nell'archivio certificati radice attendibili su tutti i dispositivi e i server.
I certificati autofirmati spesso non sono l'opzione migliore quando si utilizza Mutual TLS o l'autenticazione basata su certificato. Tuttavia, organizzazioni più piccole con un numero limitato di dispositivi o di computer possono decidere di utilizzare il metodo del certificato autofirmato perché è il più semplice da configurare e il meno costoso da utilizzare con l'implementazione Mutual TLS. Spesso le organizzazioni più piccole decidono di non utilizzare un certificato di terze parti o di installare la propria PKI per emettere i certificati a causa dei costi, perché l'amministratore non possiede l'esperienza e la conoscenza necessarie per creare una gerarchia di certificati o per entrambi i motivi. Quando si utilizzano certificati autofirmati, il costo è minimo e la configurazione è semplice. Tuttavia, stabilire un'infrastruttura per la gestione del ciclo di vita, il rinnovo, la gestione attendibile e la revoca dei certificati è molto più difficile con i certificati autofirmati. Per ulteriori informazioni su come creare un certificato per i servizi TLS, vedere Informazioni sui certificati TLS.
Inizio pagina
Infrastruttura a chiave pubblica (PKI)
Un'infrastruttura a chiave pubblica (PKI) è un sistema di certificati digitali, di Autorità di certificazione (CA) e di autorità di registrazione (RA) che verificano e autenticano la validità di ciascuna parte coinvolta in una transazione elettronica, utilizzando la crittografia a chiave pubblica. Quando si implementa una CA in un'organizzazione che utilizza Active Directory, si fornisce un'infrastruttura per la gestione del ciclo di vita, il rinnovo, la gestione attendibile e la revoca dei certificati. Queste qualità offrono un'infrastruttura solida per tutti i certificati nell'organizzazione. Tuttavia, la distribuzione di server e infrastrutture aggiuntivi per creare e gestire questi tipi di certificati implica dei costi.
È possibile installare Servizi certificati su qualsiasi server nel dominio. Se si ottengono certificati da una CA di dominio basata su Windows, è possibile utilizzarla per richiedere o firmare certificati da emettere sui propri server o computer in rete. Ciò consente di utilizzare una PKI, opzione simile all'utilizzo di un fornitore di certificati di terze parti ma meno costosa. Poiché non è possibile distribuire pubblicamente una PKI, come altri tipi di certificati, quando si utilizza una PKI una CA firma il certificato del richiedente utilizzando la chiave privata e il richiedente viene verificato. La chiave pubblica della CA viene inclusa nel certificato emesso dalla CA stessa. Chiunque possieda questo certificato della CA come certificato radice può utilizzare la chiave pubblica per decrittografare il certificato del richiedente e autenticarlo.
Quando si utilizza un certificato PKI per implementare Mutual TLS, è necessario copiare i certificati richiesti nei gateway IP o nei PBX IP. Occorre quindi copiare i certificati dei gateway IP o dei PBX IP nei server Messaggistica unificata associati al dial plan di messaggistica unificata configurato in modalità protetta.
L'installazione e la configurazione per l'utilizzo di certificati PKI e di terze parti sono simili alle procedure eseguite per l'importazione e l'esportazione dei certificati autofirmati. Tuttavia, non è sufficiente installare il certificato computer nell'archivio dei certificati radice attendibili disponibili nell'elenco locale. È necessario anche importare o copiare il certificato radice attendibile per la PKI in un archivio di certificati radice attendibili disponibili nell'elenco locale nei server Messaggistica unificata e nei gateway IP e IP PBX presenti nella rete.
Per distribuire Mutual TLS quando è già stata distribuita un'infrastruttura PKI, procedere come segue:
Generare una richiesta di certificato su ogni gateway o PBX IP.
Copiare la richiesta di certificato da utilizzare quando il certificato viene richiesto da un'autorità di certificazione.
Richiedere un certificato da un'autorità di certificazione utilizzando la richiesta di certificato. Salvare il certificato.
Importare il certificato salvato in ogni dispositivo o computer.
Scaricare il certificato radice attendibile dalla PKI.
Importare il certificato radice attendibile dalla PKI su ogni dispositivo. Se si importa il certificato radice attendibile su un computer Exchange 2010 su cui è in esecuzione il ruolo Messaggistica unificata, è possibile utilizzare anche i Criteri di gruppo per importare il certificato radice attendibile nell'archivio certificati radice attendibili sul server Messaggistica unificata o su altri server di Exchange 2010. Tuttavia, questo processo viene utilizzato anche per la configurazione di un server su cui è in esecuzione il ruolo del server Messaggistica unificata.
Nota
Seguire la stessa procedura se si utilizza un certificato commerciale di terze parti per implementare Mutual TLS.
Per ulteriori informazioni su certificati e PKI, vedere gli argomenti seguenti:
Per ulteriori informazioni sui certificati, vedere Public Key Infrastructure for Windows Server 2003 (le informazioni potrebero essere in lingua inglese).
Per ulteriori informazioni sulle modalità migliori di implementazione di una infrastruttura a chiave pubblica di Windows Server 2003, vedere Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure (informazioni in lingua inglese).
Per ulteriori informazioni su come distribuire una infrastruttura a chiave pubblica basata su Windows Server 2008, vedere Step-By-Step Example Deployment of the PKI Certificates Required for Configuration Manager Native Mode: Windows Server 2008 Certification Authority (informazioni in lingua inglese).
Per ulteriori informazioni sui Servizi certificati di Windows Server 2008 per una infrastruttura a chiave pubblica basata su Windows Server 2008, vedere Panoramica di Servizi certificati Active Directory.
Autorità di certificazione di terze parti
I certificati di terze parti o commerciali sono certificati generati da una CA di terze parti o commerciale e acquistati dall'utente per l'utilizzo sui propri server di rete. Poiché i certificati autofirmati e basati su PKI non sono attendibili, occorre accertarsi di importare il certificato nell'archivio certificati radice attendibili dei computer client, dei server e degli altri dispositivi. I certificati di terze parti o commerciali non presentano questo problema. La maggior parte dei certificati CA commerciali sono già attendibili perché il certificato risiede già nell'archivio certificati radice attendibili. Poiché l'emittente è attendibile, lo sarà anche il certificato. L'utilizzo di certificati di terze parti semplifica molto la distribuzione.
Per organizzazioni più grandi o per organizzazione che devono distribuire i certificati pubblicamente, l'utilizzo di un certificato di terze parti o commerciale è la soluzione migliore, anche se esistono dei costi associati al certificato. I certificati commerciali potrebbero non essere la soluzione migliore per organizzazioni più piccole e di medie dimensioni e si può decidere di utilizzare le altre opzioni di certificato disponibili.
A seconda della configurazione del gateway IP o del PBX IP, al fine di utilizzare il certificato di terze parti per Mutual TLS potrebbe essere necessario importare il certificato di terze parti o commerciale nell'archivio certificati attendibili sui gateway IP e sui PBX IP. In alcuni casi, tuttavia, il certificato di terze parti sarà incluso nell'archivio certificati radice attendibili sul server Messaggistica unificata e su altri computer Exchange 2010 nell'organizzazione.
Le procedure eseguite per l'utilizzo di un certificato di terze parti commerciale per abilitare Mutual TLS sono le stesse eseguite per l'utilizzo di un certificato PKI. L'unica differenza è che non occorre generare un certificato PKI perché è già stato acquistato un certificato da un fornitore di certificati di terze parti commerciale che sarà importato nell'archivio certificati radice attendibili sui server e sui dispositivi in rete.
Inizio pagina
Configurazione di Mutual TLS
Per impostazione predefinita, quando si riceve una chiamata in arrivo da un gateway IP, il traffico VoIP non viene crittografato e non utilizza Mutual TLS. Tuttavia, l'impostazione di protezione per un server Messaggistica unificata è configurata sul dial plan di messaggistica unificata associato al server Messaggistica unificata. Per abilitare la comunicazione protetta del server Messaggistica unificata con gateway IP, con PBX IP e con altri server Exchange 2010, occorre utilizzare il cmdlet Set-UMDialPlan per configurare la protezione VoIP sul dial plan di messaggistica unificata, quindi abilitare Mutual TLS per i server Messaggistica unificata associati al dial plan stesso.
Dopo aver abilitato la protezione VoIP sul dial plan di messaggistica unificata, tutti i server Messaggistica unificata associati al dial plan sono in grado di comunicare in modalità protetta. Tuttavia, a seconda del tipo di certificato utilizzato per abilitare Mutual TLS, occorre innanzitutto importare ed esportare i certificati richiesti sia sui server Messaggistica unificata sia sui gateway e sui PBX IP. Una volta importati il certificato o i certificati richiesti nel server Messaggistica unificata, per poter utilizzare il certificato importato e stabilire una connessione crittografata con i gateway IP o PBX IP è necessario riavviare il servizio Messaggistica unificata di Microsoft Exchange. Per ulteriori informazioni sull'importazione e sull'esportazione dei certificati, vedere Importare ed esportare i certificati.
Dopo aver importato ed esportato correttamente i certificati attendibili richiesti, il gateway IP richiederà un certificato dal server Messaggistica unificata, quindi quest'ultimo richiederà un certificato dal gateway IP. Lo scambio di certificati attendibili tra il gateway IP e il server Messaggistica unificata abilita la comunicazione tra il gateway IP e il server Messaggistica unificata mediante una connessione crittografata con Mutual TLS. Quando un gateway IP o un PBX IP riceve una chiamata in arrivo, viene avviato uno scambio di certificati e viene negoziata la protezione utilizzando Mutual TLS con il server Messaggistica unificata. Il servizio Messaggistica unificata di Microsoft Exchange non è implicato nel processo di scambio di certificati o nella determinazione della validità del certificato. Tuttavia, se non è possibile individuare un certificato attendibile su un server Messaggistica unificata, se si trova un certificato attendibile ma non valido oppure se una chiamata viene rifiutata a causa di un errore della negoziazione MTLS, il server Messaggistica unificata riceverà una notifica dal servizio Messaggistica unificata di Microsoft Exchange.
Benché il servizio Messaggistica unificata di MicrosoftExchange non partecipi allo scambio di certificati tra il server Messaggistica unificata e i gateway IP, il servizio Messaggistica unificata di MicrosoftExchange svolge le funzioni seguenti:
Fornisce un elenco di nomi di dominio completi al servizio vocale di MicrosoftExchange che consente di accettare solo le chiamate provenienti da gateway IP o da PBX IP inclusi nell'elenco.
Passa gli attributi issuerName e SerialNumber di un certificato al servizio di riconoscimento vocale di Microsoft Exchange. Tali attributi identificano in modo univoco il certificato che il server Messaggistica unificata utilizzerà quando un gateway IP o un sistema IP PBX richiede un certificato.
Al termine dello scambio di chiave eseguito tra il server Messaggistica unificata e i gateway IP o i PBX IP per stabilire una connessione crittografata utilizzando Mutual TLS, i server Messaggistica unificata comunicheranno con i gateway IP e i PBX IP utilizzando la connessione crittografata. I server Messaggistica unificata comunicheranno inoltre con altri server Exchange 2010, ad esempio i server Accesso client e i server Trasporto Hub, mediante una connessione crittografata che utilizza Mutual TLS. Tuttavia, Mutual TLS sarà utilizzato solo per crittografare il traffico o i messaggi inviati dal server Messaggistica unificata a un server Trasporto Hub.
Importante
Per abilitare Mutual TLS tra un gateway IP di messaggistica unificata e un dial plan che opera in modalità protetta, occorre innanzitutto configurare il gateway IP di messaggistica unificata con un nome di dominio completo e configurarlo per l'ascolto sulla porta 5061. Per configurare un gateway IP di messaggistica unificata, eseguire il comando riportato di seguito: Set-UMIPGateway -Identity MyUMIPGateway -Port 5061.
Inizio pagina
IPsec
Anche IPsec utilizza i certificati per crittografare i dati. Fornisce una misura di difesa chiave contro gli attacchi provenienti da reti private e Internet.
IPsec ha i seguenti obiettivi:
Proteggere il contenuto dei pacchetti IP.
Garantire la difesa dagli attacchi alla rete attraverso il filtro dei pacchetti e la tutela di una comunicazione attendibile.
IPsec è un framework di standard aperti che garantisce comunicazioni private sicure sulle reti IP utilizzando i servizi di protezione di crittografia.
IPsec utilizza servizi di protezione basati sulla crittografia, protocolli di protezione e gestione delle chiavi dinamica. Offre la complessità e la flessibilità per proteggere le comunicazioni tra computer, domini, siti, siti remoti, Extranet e client remoti di reti private. Può anche essere utilizzato per bloccare la ricezione o la trasmissione di particolari tipi di traffico.
IPsec si basa su un modello di protezione end-to-end che stabilisce attendibilità e protezione da un indirizzo IP di origine a un indirizzo IP di destinazione. L'indirizzo IP in sé non deve essere considerato un'identità. Il sistema dietro l'indirizzo IP, invece, ha un'identità convalidata da un processo di autenticazione. Gli unici computer che devono avere informazioni sul traffico in fase di protezione sono i computer di invio e ricezione. Ogni computer gestisce la protezione come il rispettivo sistema e funziona presupponendo che il supporto su cui si verifica la comunicazione non sia protetto. Non è necessario che i computer che instradano i dati solo dall'origine alla destinazione supportino IPsec, eccetto quando si esegue il filtro di pacchetti di tipo firewall o la NAT (network address translation) tra i due computer. Ciò abilita la distribuzione corretta di IPsec per i seguenti scenari organizzativi:
LAN Client-server, server-server e server-dispositivo VoIP
WAN router-router e gateway-gateway
Accesso remoto Client remoti e accesso a Internet da reti private
In genere entrambi i lati richiedono la configurazione di IPsec per l'impostazione di opzioni di protezione che consentono ai due sistemi di concordare sulle modalità di protezione del traffico scambiato. Quanto sopra è noto come criterio IPsec. Le implementazioni di IPsec di Microsoft Windows 2000 Server, Windows XP, Windows Server 2003 e del sistema operativo Windows Server 2008 si basano sugli standard del settore sviluppati dal gruppo di lavoro IPsec di Internet Engineering Task Force (IETF). Parti dei servizi relativi a IPsec sono state sviluppate unitamente da Microsoft e Cisco Systems, Inc. Per ulteriori informazioni sulla configurazione dei criteri IPsec, vedere Creazione, modifica e assegnazione di criteri IPSec.
Per ulteriori informazioni su IPsec, vedere Concetti relativi a IPSec.
Avviso
Se i criteri IPsec sono già stati implementati sulla rete, occorre escludere i gateway IP e i PBX IP dal criterio IPsec. In caso contrario, per ogni 3 secondi di segreteria telefonica, si verificherà un'interruzione di 1 secondo della trasmissione vocale. Questo è un problema noto ed è presente un aggiornamento rapido per Windows Server 2003. Per ulteriori informazioni su questo aggiornamento rapido, vedere Come semplificare la creazione e la manutenzione dei filtri di protezione IP (IPsec) in Windows Server 2003 e Windows XP.
Dial plan di messaggistica unificata e protezione VoIP
I server Messaggistica unificata sono in grado di comunicare con i gateway IP, i PBX IP e gli altri computer di Exchange 2010 in modalità non protetta, SIP con protezione o protetta a seconda della modalità di configurazione del dial plan. Un server Messaggistica unificata è in grado di operare in qualsiasi modalità configurata in un dial plan perché il server stesso è configurato per l'ascolto contemporaneo sulla porta TCP 5060 per le richieste non protette e sulla porta TCP 5061 per le richieste protette. Un server Messaggistica unificata può essere associato a uno o più dial plan di messaggistica unificata e può essere associato a dial plan con impostazioni di protezione VoIP diverse. Un singolo server Messaggistica unificata può essere associato a dial plan configurati per l'utilizzo di una combinazione di modalità protetta, SIP con protezione o non protetta.
Per impostazione predefinita, quando si crea un dial plan di messaggistica unificata le comunicazioni avvengono in modalità non protetta e i server di messaggistica unificata associati al dial plan inviano e ricevono i dati da gateway IP, da PBX IP e da altri computer Exchange 2010 senza utilizzare la crittografia. Nella modalità non protetta, le informazioni relative al canale di supporto RTP (Realtime Transport Protocol) e alla segnalazione SIP non vengono crittografate.
È possibile configurare un server Messaggistica unificata per l'utilizzo di Mutual TLS al fine di crittografare il traffico SIP e RTP inviato e ricevuto da altri dispositivi e server. Se si aggiunge un server Messaggistica unificata a un dial plan di messaggistica unificata e si configura il dial plan per l'utilizzo della modalità SIP con protezione, viene crittografato solo il traffico di segnalazione SIP, mentre i canali di supporto RTP utilizzano sempre il protocollo non crittografato TCP. TCP non è crittografato. Tuttavia, se si aggiunge un server Messaggistica unificata a un dial plan di messaggistica unificata e si configura il dial plan per l'utilizzo della modalità protetta, vengono crittografati sia il traffico di segnalazione SIP sia i canali di supporto RTP. Un canale dei supporti di segnalazione protetto che utilizza il protocollo SRTP (Secure Realtime Transport Protocol) utilizza anche Mutual TLS per crittografare i dati VoIP.
È possibile configurare la modalità di protezione VoIP sia quando si crea un nuovo dial plan sia dopo la sua creazione, utilizzando Exchange Management Console o il cmdlet Set-UMDialPlan. Se si configura il dial plan di messaggistica unificata per l'utilizzo delle modalità protetta o SIP con protezione, i server Messaggistica unificata associati al dial plan utilizzeranno la crittografia per il traffico di segnalazione SIP, per i canali di supporto RTP o per entrambi. Tuttavia, per essere in grado di inviare i dati crittografati a e da un server Messaggistica unificata, occorre configurare correttamente il dial plan di messaggistica unificata e i dispositivi quali i gateway IP o i PBX IP per il supporto di Mutual TLS.
Il cmdlet Get-UMDialPlan in Exchange Management Shell consente di determinare le impostazioni di protezione per uno specifico dial plan di messaggistica unificata. Se il parametro di protezione VoIP è stato abilitato, è possibile verificare che il servizio Messaggistica unificata di MicrosoftExchange sia stato avviato in modalità protetta controllando il registro eventi dell'applicazione per verificare la registrazione degli eventi di informazione 1114 e 1112.
Importante
Se si sta configurando l'autenticazione reciproca TLS per crittografare i dati scambiati tra un gateway Dialogic modello 2000 o 4000 IP, è necessario utilizzare il modello di certificato Computer V3 che supporta sia l'autenticazione server sia quella client. Il modello di certificato server Web che supporta l'autenticazione server funzionerà correttamente soltanto con gateway IP Dialogic 1000 e 3000, gateway IP AudioCodes e MicrosoftOffice Communications Server 2007.
Inizio pagina
Come la messaggistica unificata determina la modalità di protezione e seleziona i certificati
All'avvio, il servizio Messaggistica unificata di Microsoft Exchange controlla il dial plan associato e l'impostazione del parametro VoipSecurity, quindi identifica se attivare la modalità protetta o non protetta. Se determina che è necessario l'avvio in modalità protetta, determina se ha accesso ai certificati richiesti. Se il server Messaggistica unificata non è associato ad alcun dial plan di messaggistica unificata, determina quale in modalità eseguire l'avvio in base al parametro StartSecured del file Msexchangeum.config. È possibile impostare il valore di questo parametro su 0 o 1. Un valore 1 avvia il server Messaggistica unificata utilizzando la crittografia per proteggere il traffico VoIP. Un valore pari a 0 avvia il server, ma la crittografia non verrà utilizzata per proteggere il traffico VoIP. Per modificare il comportamento all'avvio del server Messaggistica unificata dalla modalità protetta alla modalità non protetta e viceversa, è possibile associare il server ai dial plan di messaggistica unificata appropriati e riavviare il server Messaggistica unificata. È inoltre possibile modificare l'impostazione di configurazione nel file di configurazione UMRecyclerConfig.xml e riavviare il servizio Messaggistica unificata di Microsoft Exchange.
Se il servizio Messaggistica unificata di Microsoft Exchange viene avviato in modalità non protetta, verrà avviato correttamente. Accertarsi, tuttavia che anche i gateway IP e i PBX siano eseguiti in modalità non protetta. Inoltre, se si esegue il test della connettività del server Messaggistica unificata in modalità non protetta, utilizzare il cmdlet Test-UMConnectivity con il parametro -Secured:false.
Se si avvia il servizio Messaggistica unificata di Microsoft Exchange in modalità protetta, per consentire a Mutual TLS di abilitare la crittografia viene eseguita la ricerca di un certificato valido nell'archivio certificati locale. Il servizio cercherà innanzitutto un certificato PKI o commerciale valido, quindi, se non trova un certificato appropriato, cercherà un certificato autofirmato da utilizzare. Se non vengono individuati certificati PKI, commerciali o autofirmati, il servizio Messaggistica unificata di Microsoft Exchange crea un certificato autofirmato da utilizzare per l'avvio in modalità protetta. Se il server Messaggistica unificata viene avviato in modalità non protetta, non sono necessari certificati.
Tutti i dettagli del certificato utilizzato per l'avvio in modalità protetta saranno registrati ogni qualvolta si utilizza un certificato o se il certificato viene modificato. Tra i dettagli registrati sono inclusi:
Nome dell'emittente
Numero di serie
Identificazione personale
L'identificazione personale è l'hash Secure Hash Algorithm (SHA1) e può essere utilizzato per identificare in modo univoco il certificato utilizzato. È quindi possibile esportare dall'archivio certificati locale il certificato utilizzato dal servizio Messaggistica unificata di Microsoft Exchange per l'avvio in modalità protetta, quindi importarlo nell'archivio certificati attendibili dei gateway IP e dei PBX IP presenti nella rete.
Dopo aver trovato e utilizzato il certificato appropriato e se non sono state apportate ulteriori modifiche, il servizio Messaggistica unificata di Microsoft Exchange registrerà un evento un mese prima della scadenza del certificato in uso. Se il certificato non viene modificato in questo periodo, il servizio Messaggistica unificata di Microsoft Exchange registrerà un evento ogni giorno fino alla scadenza del certificato e ogni giorno dopo la scadenza del certificato.
Quando il server Messaggistica unificata cerca un certificato per consentire a Mutual TLS di stabilire un canale crittografato, la ricerca viene eseguita nell'archivio certificati radice attendibili. Se sono disponibili più certificati validi di diversi emittenti, il server Messaggistica unificata sceglierà il certificato valido con la scadenza più lunga. Se esistono più certificati, il server Messaggistica unificata sceglierà i certificati in base all'emittente e alla data di scadenza. Il server Messaggistica unificata cercherà un certificato valido in questo ordine.
Certificato PKI o commerciale con la scadenza più lunga.
Certificato PKI o commerciale con la scadenza più breve.
Certificato autofirmato con la scadenza più lunga.
Certificato autofirmato con la scadenza più breve. È richiesto un certificato commerciale, PKI o autofirmato valido. Se non è possibile individuare un certificato valido, il server Messaggistica unificata genera un certificato autofirmato. Il certificato è necessario per consentire al server Messaggistica unificata di crittografare il traffico VoIP se opera in modalità SIP con protezione o protetta.
Importante
Quando si installa un nuovo certificato in un server Accesso client utilizzato per crittografare i dati della funzionalità Ascolta al telefono tra il server Accesso client e un server Messaggistica unificata, è necessario eseguire il comando IISreset da un prompt dei comandi per caricare il certificato corretto.
Inizio pagina
©2010 Microsoft Corporation. Tutti i diritti riservati.