MTA-STS を使用したメールフローの強化

[アーティクル]
01/15/2025

SMTP MTA Strict Transport Security (MTA-STS) 標準のサポートが Exchange Online に追加されます。この標準は、メールサーバー間の接続に TLS が常に使用されるようにするために開発されました。また、受信側のサーバーに信頼できる証明書があることを検証するためにサーバーを送信する方法も提供されます。 TLS が提供されていないか、証明書が有効でない場合、送信者はメッセージの配信を拒否します。これらの新しいチェックにより、SMTP の全体的なセキュリティが向上し、中間者攻撃から保護されます。

MTA-STS は、受信保護と送信保護の 2 つのシナリオに分類できます。受信保護は、MTA-STS を使用してExchange Onlineでホストされるドメインの保護をカバーします。送信保護では、MTA-STS で保護されたドメインに電子メールを送信するときにExchange Onlineによって実行される MTA-STS 検証について説明します。

ヒント

E5 のお客様でない場合は、90 日間の Microsoft Purview ソリューション試用版を使用して、Purview の追加機能が組織のデータセキュリティとコンプライアンスのニーズの管理にどのように役立つかを確認してください。 Microsoft Purview 試用版ハブから開始します。サインアップと試用期間の詳細については、こちらをご覧ください。

送信保護

Exchange Onlineから MTA-STS で保護された受信者に送信されるすべてのメッセージは、MTA-STS 標準によって設定された追加のセキュリティチェックで検証されています。管理者が適用する必要はありません。送信の実装では、MTA-STS ポリシーを介して受信者ドメイン所有者の希望を尊重します。 MTA-STS は、Exchange Onlineのセキュリティインフラストラクチャの一部を形成するため、(他の主要な SMTP 機能と同様に) 常にオンになります。

送信 MTA-STS は、宛先ドメインに対する MTA-STS 検証の結果によっては、電子メールの配信を妨げる場合があります。ドメインがセキュリティで保護されておらず、MTA-STS ポリシーが [強制] に設定されている場合は、次のいずれかのエラーコードを含む NDR が送信者に返されることがあります。

エラーコード	説明	考えられる原因	ページの先頭へ
5.4.8	'{domain}' の MX ホストが MTA-STS 検証に失敗しました	宛先 MX ホストが、ドメインの STS ポリシーに従って予想されるホストではありませんでした。	このエラーは通常、宛先ドメインの MTA-STS ポリシーに MX ホストが含まれていない問題を示します。 MTA-STS の詳細については、「 https://datatracker.ietf.org/doc/html/rfc8461」を参照してください。
5.7.5	リモート証明書が MTA-STS 検証に失敗しました。理由: {validityStatus}	宛先メールサーバーの証明書は信頼されたルート証明機関にチェーンする必要があり、共通名またはサブジェクトの別名には STS ポリシーのホスト名のエントリが含まれている必要があります。	このエラーは通常、宛先メールサーバーの証明書に関する問題を示します。 MTA-STS の詳細については、「 https://datatracker.ietf.org/doc/html/rfc8461」を参照してください。

受信保護

ドメイン所有者は、MX レコードが Exchange Online を指す場合、MTA-STS を使用してドメインに送信されたメールを保護するために対処できます。 MX レコードが中間サードパーティサービスを指している場合は、MTA-STS 要件が満たされているかどうかを確認し、その指示に従う必要があります。

ドメインに対して MTA-STS が設定されると、MTA-STS をサポートする送信者から送信されたすべてのメッセージが、セキュリティで保護された接続を確保するために標準でレイアウトされた検証を実行します。 MTA-STS をサポートしていない送信者からメールを受信した場合でも、追加の保護なしでメールが配信されます。同様に、まだ MTA-STS を使用していないものの送信者がメッセージをサポートしている場合、メッセージが中断されることはありません。メッセージが配信されない唯一のシナリオは、MTA-STS と MTA-STS 検証を使用した両側で失敗した場合です。

MTA-STS の導入方法

MTA-STS を使用すると、ドメインで TLS のサポートを宣言し、予想される MX レコードと宛先証明書の通信を行うことができます。また、問題が発生した場合に送信サーバーが実行する必要があることも示します。この通信は、DNS TXT レコードと、HTTPS Web ページとして公開されているポリシーファイルの組み合わせによって行われます。 HTTPS で保護されたポリシーでは、攻撃者が克服する必要がある別のセキュリティ保護が導入されています。

ドメインの MTA-STS TXT レコードは、送信者によってドメインの HTTPS ベースの MTA-STS ポリシーが取得された後で送信者に対する MTA-STS サポートを示します。 TXT レコードには v=STSv1 が含まれている必要があります。STSv2 がサポートされるまで、およびポリシーの ID。 ID は、ドメイン所有者とポリシーに対して一意である必要があります。ID の変更は、ポリシーを再フェッチする必要があることを送信者に通知します。 ID はグローバルに一意である必要はありません。他のドメイン所有者のポリシー ID については心配しないでください。 MTA-STS ポリシーの更新後、ID を更新する必要があります。または、キャッシュされたポリシーのmax_ageが期限切れになるまで、送信者はドメインに対してキャッシュされたポリシーを使用し続けます。

一意の ID を設定するための繰り返し可能なパターンは、次のように UTC 時刻を使用することです。
id=<yyyymmddhh0000>Z;

次の TXT レコードは MTA-STS のサポートを宣言する例であり、ID は 2022 年 1 月 1 日 UTC 時刻の午前 8 時に設定されています。

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

ドメインの MTA-STS ポリシーは、ドメインの Web インフラストラクチャによってホストされている事前定義済みの URL に配置される必要があります。 URL 構文は https://mta-sts.<domain name>/.well-known/mta-sts.txt です。たとえば、Microsoft.com のポリシーは https://mta-sts.microsoft.com/.well-known/mta-sts.txt で見つかります。

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

MX レコードがExchange Onlineを直接指す顧客は、https://mta-sts.microsoft.com/.well-known/mta-sts.txtに表示されるのと同じ値を独自のポリシーで指定できます。ポリシーで必要な一意の情報は、Exchange Online (*.mail.protection.outlook.com) を指す MX レコードであり、同じ証明書がすべてのExchange Online顧客によって共有されます。 Exchange Onlineでは、ワイルドカードを使用してもセキュリティが低下しないように、特定のドメインのメールを受信できるorganizationは 1 つだけです。ただし、他の電子メールサービスの場合には当てはまらない可能性があります。 ポリシーをテスト モードで発行して、ポリシーを適用モードに変更する前に有効であることを確認できます。構成を確認できるサードパーティの検証ツールがあります。

これらのポリシーは、Exchange Online顧客の代わりにホストできるものではありません。そのため、お客様は、必要なサービスを使用してドメインの STS ポリシーを構成する必要があります。 Azure サービスはポリシーホスティングに簡単に使用でき、この記事の後半で構成のチュートリアルがあります。ポリシーは、サブドメイン mta-sts.<domain name> の証明書を使用して HTTPS で保護される必要があります。

DNS TXT レコードが作成され、ポリシーファイルが必要な HTTPS URL で使用できるようになると、ドメインは MTA-STS によって保護されます。 MTA-STS の詳細については、 RFC 8461 を参照してください。

Azure Services を使用した受信 MTA-STS の構成

注:

これらの構成フローは、お客様が Azure リソースを使用して MTA-STS ポリシーをホストMicrosoft Exchange Online役立つよう開発されました。この構成フローは、MTA-STS のしくみとその要件を認識しているExchange Online顧客であることを前提としています。このトピック以外のプロトコルの詳細については、「 RFC8461」を参照してください。

MTA-STS ポリシーのホストに使用できる Azure リソースには、Azure Static Web App と Azure Functions の 2 種類があります。この記事では、両方のリソースを使用してポリシーをデプロイする方法について説明しますが、推奨される方法は、STS ポリシーなどの静的ページをホストするように設計されているため、 Azure Static Web App であり、構成を増やす必要なく、MTA-STS Web ページの TLS 証明書をすぐに提供することで構成が簡素化されます。 Azure Static Web App を使用できない場合は、Azure Functionsを使用してサーバーレスコードとしてポリシーをホストすることもできます。 Azure Functionsは他のシナリオ用に設計された機能であり、Azure Static Web Appsとは異なり、TLS 証明書を自動的に発行しないため、この方法は推奨されません。そのため、MTA-STS にAzure Functionsを使用するには、独自の "mta-sts.[ドメイン]" 証明書を使用して関数にバインドします。

どの方法を使用したかに関係なく、ポリシーが適切に構成されているかどうか、および応答時間が許容されるかどうかを検証することをお勧めします。RFC ガイダンスごとのタイムアウトは 60 秒です。

これらの構成フローは、MTA-STS ポリシーのホストに使用できる Azure 機能に関する技術情報のみを提供することを目的としており、Azure 機能の課金やコストに関する情報は提供しません。 Azure の機能のコストを知りたい場合は、Azure 料金計算ツールを使用します。

オプション 1 (推奨): Azure Static Web App

Azure DevOps organizationを作成するか、既に存在するorganizationを使用します。この例では、"ContosoCorporation" という名前のorganizationを使用して MTA-STS ポリシーをホストします。
[ Repos > Files] で、任意の IDE でリポジトリを複製します。この例では、リポジトリが Visual Studio で複製されます。
リポジトリが複製されたら、フォルダーパス home\.well-known\を作成します。次に、次のファイルを作成します。
- ファイル 1: home.well-known\mta-sts.txt
  
  注:
  
  この構成では、Exchange Onlineのみがドメインの代わりにメッセージを受信できます。複数のメールプロバイダーを使用している場合は、他のプロバイダーのドメインについても MX ホストを参照する必要があります。すべての MTA-STS シナリオでは、ワイルドカードまたは '*' を MX プレフィックスとして使用しないでください。以下の設定はExchange Onlineのみに固有であり、MTA-STS を構成するための一般的なガイダンスとして使用しないでください。
  1. mta-sts.txt ファイルに次のテキストを入力します。
```
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800
```
    注:
    
    ポリシーモードは最初に テストとして設定することをお勧めします。次に、構成の最後で、ポリシーが期待どおりに動作していることを検証した後、モードが適用されるように mta-sts.txt ファイルを更新 します。
    
    ファイルには、次のスクリーンショットに示すようにコンテンツのみが含まれている必要があります。
- ファイル 2: home\index.html
  1. index.html ファイルを作成し、次のコードを入力します。
```
<!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>
```
    ファイルには、次のスクリーンショットに示すようにコンテンツのみが含まれている必要があります。
    
    フォルダーパスとファイルが作成されたら、変更をコミットしてメインブランチにプッシュすることを忘れないでください。
次の構成で新しい Azure Static Web アプリを作成します。
- 名前: MTA-STS-StaticWebApp
- プランの種類: Standard
- デプロイの詳細: Azure DevOps
- 組織: ContosoCorporation
- プロジェクト: MTA-STS_Project
- リポジトリ: MTA-STS_Project
- ブランチ: master
- ビルドプリセット: Angular
- アプリの場所: /home
静的 Web アプリの作成が完了し、リソースがプロビジョニングされたら、[ 概要] > [デプロイトークンの管理] に移動し、次の手順で使用するようにトークンをコピーします。
[Pipelines > Create Pipeline > Azure Repos Git > MTA-STS_Project に移動し、次のサブタスクを実行します。
1. [変数] > [新しい変数] に移動し、次のように入力します。
  1. 名前: トークン
  2. 値: (手順 5 で、以前にコピーしたトークンを貼り付けます)
2. 変数が保存されたら、[ パイプライン YAML の確認] に戻り、次の yml を貼り付けて保存して実行します。
```
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)
```
  Azure DevOps では、デプロイ中に [ホストされた並列処理が購入または付与されていません] というエラーが発生した場合は、このフォームを使用して要求するか、組織の設定> [並列ジョブ] > Microsoft Hosted > [有料並列ジョブの変更] >有料並列ジョブを使用して構成を実装します。"有料並列ジョブ" が許可されます。
ジョブが正常に完了したら、Azure Static Web App > Environment > Browser に移動して、Azure portalを介してデプロイを検証できます。 index.html ファイルのコンテンツが表示されている必要があります。
Azure Static Web App >カスタムドメインにバニティドメインを追加>追加します。ゾーンが自分に属しているかどうかを検証するには、DNS プロバイダー (GoDaddy など) を使用して CNAME レコードを作成する必要があります。検証が完了すると、Azure によって証明書が発行され、静的 Web アプリに自動的にバインドされます。
MTA-STS ポリシーが発行されているかどうかを検証します。 https://mta-sts.[your domain]/.well-known/mta-sts.txt。
DNS プロバイダーを使用して MTA-STS TXT DNS レコードを作成します。形式は次のとおりです。
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
注:

MTA-STS TXT レコードの例については、「 MTA-STS を採用する方法」を参照してください。
DNS で TXT レコードが使用可能になったら、MTA-STS 構成を検証します。構成が正常に検証されたら、ポリシーモードが適用されるようにmta-sts.txt ファイルを更新し、TXT レコードのポリシー ID を更新します。

オプション 2: Azure 関数

次の構成で新しい Azure 関数アプリを作成します。
- 関数アプリ名: [任意]
- 発行: コード
- ランタイムスタック: .NET
- バージョン: 6
- オペレーティングシステム: Windows
- プランの種類: [任意]
カスタムドメインを関数アプリに追加します。ドメインが自分に属しているかどうかを検証するには、 CNAME レコードを作成する必要があります。
"mta-sts" をバインドします。[お使いのドメイン]" を関数アプリに追加します。
[アプリファイル] で、関数アプリのhost.jsonに次の拡張子を追加して、routePrefix を削除します。この追加は、関数 URL から /api を削除するために必要です。
```
"extensions": {
  "http": {
    "routePrefix": ""
  }
}
```
関数アプリで、[ 関数] > [作成 ] に移動し、次のパラメーターを構成します。

注:

この例では、ポータルを介した関数開発について説明しますが、VS Code やその他の任意のツールを自由に使用できます。
- 開発環境: [お好みで、この例では "ポータルで開発" を使用します]
- テンプレートの選択: HTTP トリガー
- 新しい関数: [お好みで]
- 承認レベル: 匿名
関数が作成されたら、 Code + Test を開き、MTA-STS ポリシーとなる単純な非同期 HTTP 応答を C# で開発します。次の例は、Exchange Onlineが電子メールを受信することが予想されることを示しています。

注:

ポリシーモードは最初に テストとして設定することをお勧めします。次に、構成の最後で、ポリシーが期待どおりに動作していることを検証した後、モードが適用されるように mta-sts.txt ファイルを更新 します。
[ Integration > HTTP (req)] で、トリガーを次の値に編集します。
- ルートテンプレート: .well-known/mta-sts.txt
- 選択した HTTP メソッド: GET
MTA-STS ポリシーが https://mta-sts.[your domain]/.well-known/mta-sts.txt で発行されていることを検証します。
次の形式で、DNS プロバイダーを使用して MTA-STS TXT DNS レコードを作成します。
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
注:

MTA-STS TXT レコードの例については、「 MTA-STS を採用する方法」を参照してください。
DNS で TXT レコードが使用可能になったら、MTA-STS 構成を検証します。構成が正常に検証されたら、ポリシーモードが適用されるようにmta-sts.txt ファイルを更新し、TXT レコードのポリシー ID を更新します。