Ottimizzazione del flusso di posta con MTA-STS

Articolo
08/18/2023

Il supporto per lo standard SMTP MTA Strict Transport Security (MTA-STS) è stato aggiunto a Exchange Online. Lo standard è stato sviluppato per garantire che venga sempre usato il TLS per le connessioni tra server di posta elettronica. Offre anche un modo per inviare server per verificare che il server ricevente disponga di un certificato attendibile. Se il TLS non è disponibile o il certificato non è valido, il mittente si rifiuta di recapitare i messaggi. Questi nuovi controlli migliorano la sicurezza complessiva di SMTP e proteggono dagli attacchi man-in-the-middle.

MTA-STS può essere suddiviso in due scenari: protezione in ingresso e protezione in uscita. La protezione in ingresso copre la protezione dei domini ospitati in Exchange Online con MTA-STS. La protezione in uscita copre le convalide MTA-STS eseguite da Exchange Online durante l'invio di messaggi di posta elettronica a domini protetti da MTA-STS.

Consiglio

Se non si è cliente E5, usa la versione di valutazione delle soluzioni Microsoft Purview di 90 giorni per esplorare in che modo funzionalità aggiuntive di Purview possono aiutare l'organizzazione a gestire le esigenze di sicurezza e conformità dei dati. Iniziare subito dall'hub delle versioni di valutazione del Portale di conformità di Microsoft Purview. Informazioni dettagliate sui termini di registrazione e prova.

Protezione in uscita

Tutti i messaggi inviati in uscita da Exchange Online ai destinatari protetti da MTA-STS vengono convalidati con questi controlli di sicurezza aggiuntivi definiti dallo standard MTA-STS. Non c'è nulla che gli amministratori debbano fare per applicarlo. L'implementazione in uscita rispetta i desideri dei proprietari del dominio del destinatario tramite i criteri MTA-STS. MTA-STS fa parte dell'infrastruttura di sicurezza di Exchange Online ed è quindi sempre attivato (come altre funzionalità SMTP di base).

MTA-STS in uscita può impedire il recapito dei messaggi di posta elettronica a seconda dei risultati della convalida MTA-STS rispetto al dominio di destinazione. Se il dominio non è sicuro e il criterio MTA-STS è impostato su Imponi, è possibile che al mittente venga restituito un rapporto di mancato recapito con uno dei codici di errore seguenti:

Codice errore	Descrizione	Possibile causa	Informazioni aggiuntive
5.4.8	Convalida MTA-STS degli host MX di '{domain}' non riuscita	L'host MX di destinazione non era l'host previsto per i criteri stS del dominio.	Questo errore indica in genere un problema con i criteri MTA-STS del dominio di destinazione che non contengono l'host MX. Per altre informazioni su MTA-STS, vedere https://datatracker.ietf.org/doc/html/rfc8461.
5.7.5	Convalida MTA-STS del certificato remoto non riuscita. Motivo: {validityStatus}	Il certificato del server di posta di destinazione deve essere concatenato a un'autorità di certificazione radice attendibile e il nome comune o il nome alternativo del soggetto deve contenere una voce per il nome host nei criteri stS.	Questo errore indica in genere un problema con il certificato del server di posta elettronica di destinazione. Per altre informazioni su MTA-STS, vedere https://datatracker.ietf.org/doc/html/rfc8461.

Protezione in ingresso

I proprietari di dominio possono intervenire per proteggere i messaggi di posta elettronica inviati ai propri domini con MTA-STS, se il record MX punta a Exchange Online. Se il record MX punta a un servizio di terze parti intermediario, è necessario verificare se i requisiti MTA-STS sono soddisfatti e quindi seguire le istruzioni.

Dopo aver configurato MTA-STS per il dominio, tutti i messaggi inviati dai mittenti che supportano MTA-STS eseguiranno le convalide definite dallo standard per garantire una connessione sicura. Se si riceve un messaggio di posta elettronica da un mittente che non supporta MTA-STS, l'e-mail verrà comunque recapitata senza la protezione aggiuntiva. Analogamente, non si verifica alcuna interruzione dei messaggi se non si usa ancora MTA-STS ma il mittente lo supporta. L'unico scenario in cui i messaggi non vengono recapitati è quando entrambi i lati usano la convalida MTA-STS e questa non riesce.

Come adottare MTA-STS

MTA-STS consente a un dominio di dichiarare il supporto per TLS e comunicare il record MX e il certificato di destinazione previsti. Indica anche cosa deve fare un server di invio se si verifica un problema. Questa comunicazione viene eseguita tramite una combinazione di un record TXT DNS e un file di criteri pubblicato come pagina Web HTTPS. I criteri protetti da HTTPS introducono un'altra protezione di sicurezza che gli utenti malintenzionati devono superare.

Il record TXT MTA-STS di un dominio indica il supporto MTA-STS per un mittente, dopo di che i criteri MTA-STS basati su HTTPS del dominio vengono recuperati dal mittente. Il record TXT deve contenere v=STSv1; fino a quando STSv2 non è supportato e l'ID per i criteri. L'ID DEVE essere univoco per il proprietario del dominio e i criteri, in quanto una modifica dell'ID segnala ai mittenti che devono recuperare nuovamente i criteri. L'ID non deve essere univoco a livello globale, non preoccuparsi degli ID dei criteri di altri proprietari di dominio. Dopo gli aggiornamenti dei criteri MTA-STS, è necessario aggiornare l'ID oppure i mittenti continueranno a usare i criteri memorizzati nella cache per il dominio fino alla scadenza della max_age dei criteri memorizzati nella cache.

Un modello ripetibile per l'impostazione di un ID univoco consiste nell'usare l'ora UTC come tale:
id=<yyyymmddhh0000>Z;

Il record TXT seguente è un esempio che dichiara il supporto per MTA-STS, l'ID è stato impostato alle 8 del 1° gennaio 2022 UTC:

_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20220101080000Z;

I criteri MTA-STS di un dominio devono trovarsi in un URL predefinito ospitato dall'infrastruttura Web del dominio. La sintassi dell'URL è https://mta-sts.<domain name>/.well-known/mta-sts.txt. Ad esempio, i criteri di Microsoft.com sono disponibili all'indirizzo: https://mta-sts.microsoft.com/.well-known/mta-sts.txt.

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Qualsiasi cliente i cui record MX puntano direttamente a Exchange Online può specificare nei propri criteri gli stessi valori visualizzati in https://mta-sts.microsoft.com/.well-known/mta-sts.txt. Le informazioni obbligatorie univoche nel criterio sono il record MX che punta a Exchange Online (*con estensione mail.protection.outlook.com) e lo stesso certificato viene condiviso da tutti i clienti Exchange Online. Exchange Online consente solo a un'organizzazione di ricevere messaggi di posta elettronica per un determinato dominio in modo che l'uso di un carattere jolly non indeboli la sicurezza, tuttavia, potrebbe non essere il caso per altri servizi di posta elettronica. È possibile pubblicare i criteri in modalità di test per assicurarsi che siano validi prima di modificarli per applicare la modalità. Sono disponibili strumenti di convalida di terze parti che possono controllare la configurazione.

Questi criteri non sono qualcosa che Exchange Online possono ospitare per conto dei clienti, quindi i clienti devono configurare i criteri stS del dominio usando i servizi che preferiscono. I servizi di Azure possono essere facilmente usati per l'hosting di criteri ed è disponibile una procedura dettagliata di configurazione più avanti in questo articolo. Il criterio deve essere protetto da HTTPS con un certificato per il sottodominio mta-sts.<domain name>.

Dopo aver creato il record TXT DNS e aver reso disponibile il file dei criteri all'URL HTTPS richiesto, il dominio verrà protetto da MTA-STS. I dettagli su MTA-STS sono disponibili in RFC 8461.

Configurazione di MTA-STS in ingresso con Servizi di Azure

Nota

Questi flussi di configurazione sono stati sviluppati per aiutare Microsoft Exchange Online clienti a ospitare i criteri MTA-STS usando le risorse di Azure. Questo flusso di configurazione presuppone che l'utente sia un cliente Exchange Online che è a conoscenza del funzionamento di MTA-STS e dei relativi requisiti. Per altre informazioni sul protocollo oltre a questo argomento, vedere RFC8461.

Sono disponibili due risorse di Azure che possono essere usate per ospitare i criteri MTA-STS: App Web statica di Azure e Funzioni di Azure. Anche se questo articolo descrive come distribuire i criteri usando entrambe le risorse, il metodo consigliato è App Web statica di Azure perché è progettata per ospitare pagine statiche, ad esempio i criteri sts, e Azure semplifica la configurazione fornendo un certificato TLS per la pagina Web MTA-STS, senza richiedere più configurazione. Se non si è in grado di usare l'app Web statica di Azure, è anche possibile ospitare i criteri come codice serverless usando Funzioni di Azure. Questo approccio non è il metodo preferito perché Funzioni di Azure è una funzionalità progettata per altri scenari e non emette automaticamente un certificato TLS, a differenza di App Web statiche di Azure. Pertanto, l'uso di Funzioni di Azure per MTA-STS richiede l'emissione di "mta-sts". il certificato del dominio]" e associarlo alla funzione.

Indipendentemente dall'approccio adottato, è consigliabile verificare se i criteri sono stati configurati correttamente e se il tempo di risposta è accettabile: il timeout per le linee guida RFC è di 60 secondi.

Questi flussi di configurazione hanno lo scopo di fornire solo informazioni tecniche sulle funzionalità di Azure che possono essere usate per ospitare i criteri MTA-STS e non forniscono informazioni sui costi o sui costi delle funzionalità di Azure. Per conoscere i costi delle funzionalità di Azure, usare il Calcolatore prezzi di Azure.

Opzione 1 (SCELTA CONSIGLIATA): App Web statica di Azure

Creare un'organizzazione di Azure DevOps o usare un'organizzazione già esistente. In questo esempio verrà usata un'organizzazione denominata "ContosoCorporation" per ospitare i criteri MTA-STS.
In File Repos >clonare il repository in qualsiasi IDE preferito. In questo esempio il repository verrà clonato in Visual Studio.
Dopo aver clonato il repository, creare il percorso home\.well-known\della cartella . Creare quindi i file seguenti:
- File 1: home.well-known\mta-sts.txt
  
  Nota
  
  Questa configurazione consente solo a Exchange Online di ricevere messaggi per conto del dominio. Se si usano più provider di posta elettronica, è necessario fare riferimento agli host MX anche per i domini di tali altri provider. I caratteri jolly o '*' non devono essere usati come prefisso MX in tutti gli scenari MTA-STS; Le impostazioni seguenti sono specifiche solo per Exchange Online e NON devono essere usate come indicazioni generali per la configurazione di MTA-STS.
  1. Inserire il testo seguente nel mta-sts.txt file:
```
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800
```
    Nota
    
    È consigliabile impostare inizialmente la modalità dei criteri come test. Quindi, alla fine della configurazione e dopo aver verificato che i criteri funzionino come previsto, aggiornare il mta-sts.txt file in modo che la modalità sia applicata.
    
    Il file deve contenere solo il contenuto, come illustrato nello screenshot seguente:
- File 2: home\index.html
  1. Creare un index.html file e immettere il codice seguente:
```
<!DOCTYPE html>
<html lang="en">

<head>
<meta charset="UTF-8">
<title>MTA-STS</title>
</head>

<body>
<h1>MTA-STS Static Website index</h1>
</body>

</html>
```
    Il file deve contenere solo il contenuto, come illustrato nello screenshot seguente:
    
    Dopo aver creato il percorso della cartella e i file, non dimenticare di eseguire il commit delle modifiche ed eseguirne il push nel ramo principale.
Creare una nuova app Web statica di Azure con la configurazione seguente:
- Nome: MTA-STS-StaticWebApp
- Tipo di piano: Standard
- Dettagli distribuzione: Azure DevOps
- Organizzazione: ContosoCorporation
- Progetto: MTA-STS_Project
- Repository: MTA-STS_Project
- Ramo: master
- Set di impostazioni di compilazione: Angular
- Percorso dell'app: /home
Al termine della creazione dell'app Web statica e del provisioning della risorsa, passare a Panoramica > Gestire il token di distribuzione e quindi copiare il token come verrà usato nel passaggio successivo.
Passare a Pipelines > Create Pipeline > Azure Repos Git > MTA-STS_Project ed eseguire le sottoattività seguenti:
1. Passare a Variabili > nuova variabile e digitare quanto segue:
  1. Nome: token
  2. Valore: (incollare il token copiato in precedenza, nel passaggio 5)
2. Dopo aver salvato la variabile, tornare a Esaminare la pipeline YAML e incollare il file yml seguente, salvarla ed eseguirla:
```
trigger:
- main

pool:
vmImage: ubuntu-latest

steps:
- checkout: self
submodules: true
- task: AzureStaticWebApp@0
inputs:
 app_location: '/home'
 azure_static_web_apps_api_token: $(token)
```
  In Azure DevOps, durante la distribuzione, se si verifica l'errore Nessun parallelismo ospitato è stato acquistato o concesso, richiedere tramite questo modulo o implementare una configurazione tramite le impostazioni > dell'organizzazione Processi > paralleli Processi Microsoft Hosted > Change > Paid Parallel in modo che siano consentiti "processi paralleli a pagamento".
Al termine del processo, è possibile convalidare la distribuzione tramite il portale di Azure passando ad Azure Static Web App Environment Browser.Once the job successfully, you can validate the deployment through the portale di Azure by going to Azure Static Web App > Environment > Browser. È necessario visualizzare il index.html contenuto del file.
Aggiungere il dominio vanity in Azure Static Web App Custom domains Add (Aggiungi domini > personalizzati dell'app > Web statica di Azure). Sarà necessario creare un record CNAME tramite il provider DNS (ad esempio, GoDaddy) per verificare se la zona appartiene all'utente. Al termine della convalida, Azure rilascerà un certificato e lo associerà automaticamente all'app Web statica.
Verificare se i criteri MTA-STS vengono pubblicati tramite: https://mta-sts.[dominio]/.noto/mta-sts.txt.
Creare il record DNS TXT MTA-STS tramite il provider DNS. Il formato è il seguente:
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Nota

Un record TXT MTA-STS di esempio è disponibile in Come adottare MTA-STS.
Quando il record TXT è disponibile in DNS, convalidare la configurazione MTA-STS. Dopo aver convalidato correttamente la configurazione, aggiornare il mta-sts.txt file in modo che sia applicata la modalità dei criteri, quindi aggiornare l'ID criteri nel record TXT.

Opzione 2: Funzione di Azure

Creare una nuova app per le funzioni di Azure con la configurazione seguente:
- Nome app per le funzioni: [Come scelta]
- Pubblica: Codice
- Stack di runtime: .NET
- Versione: 6
- Sistema operativo: Windows
- Tipo di piano: [Come scelta]
Aggiungere il dominio personalizzato all'app per le funzioni. Sarà necessario creare un record CNAME per verificare se il dominio appartiene all'utente.
Associare i "mta-sts. [dominio]" nell'app per le funzioni.
In File app aggiungere l'estensione seguente alla host.json dell'app per le funzioni per eliminare routePrefix. Questa aggiunta è necessaria per rimuovere /api dall'URL della funzione.
```
"extensions": {
  "http": {
    "routePrefix": ""
  }
}
```
Nell'app per le funzioni passare a Funzioni > Creare e configurare i parametri seguenti:

Nota

Anche se questo esempio descrive lo sviluppo di funzioni tramite il portale, è possibile usare VS Code o qualsiasi altro strumento preferito.
- Ambiente di sviluppo: [Come scelta dell'utente; questo esempio userà "Sviluppare nel portale"]
- Selezionare un modello: trigger HTTP
- Nuova funzione: [Come scelta]
- Livello di autorizzazione: Anonimo
Dopo aver creato la funzione, aprire Code + Test e sviluppare in C# una semplice risposta HTTP asincrona che sarà il criterio MTA-STS. L'esempio seguente indica che è previsto che Exchange Online riceva messaggi di posta elettronica:

Nota

È consigliabile impostare inizialmente la modalità dei criteri come test. Quindi, alla fine della configurazione e dopo aver verificato che i criteri funzionino come previsto, aggiornare il mta-sts.txt file in modo che la modalità sia applicata.
In Integration > HTTP (req), modificare il trigger con i valori seguenti:
- Modello di route: .well-known/mta-sts.txt
- Metodi HTTP selezionati: GET
Verificare che i criteri MTA-STS siano pubblicati tramite: https://mta-sts.[dominio]/.noto/mta-sts.txt.
Creare il record DNS TXT MTA-STS tramite il provider DNS nel formato seguente:
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Nota

Un record TXT MTA-STS di esempio è disponibile in Come adottare MTA-STS.
Quando il record TXT è disponibile in DNS, convalidare la configurazione MTA-STS. Dopo aver convalidato correttamente la configurazione, aggiornare il mta-sts.txt file in modo che sia applicata la modalità dei criteri, quindi aggiornare l'ID criterio nel record TXT.