EXO 管理者がデフォルトで EXO をセキュアにするために必要な最も重要な手順

多くの組織にとって、Exchange オンライン (EXO) はマイクロソフト 365 への最初のアクセス ポイントになります。クラウド サービスの管理方法はオンプレミスの Exchange 展開と比較して多くの類似点がありますが、新しい概念やリスクも数多く導入されています。EXO に移行した後の従来の Exchange 管理者の役割は、以前とは大きく異なります。

この記事では、既定で EXO をセキュリティで保護するために Exchange オンライン管理者が実行する必要がある最も重要な手順について説明します。適切なライセンスで活用できるセキュリティ ツールはたくさんありますが、この記事で説明する手順はすべて基本ライセンスで実現できます。

レガシ認証の無効化

これは誰にとっても驚くべきことではありません。Exchange Online 環境を既定でセキュリティ保護するために実行する最初の手順は、レガシ認証を無効にすることです。Microsoft 365 のコンテキストでは、レガシ認証は単一のプロトコルではなく、基本認証を使用するプロトコルを記述するために使用されるより多くの傘の用語です。スティーブ・グッドマンは書いた 偉大な記事 私は強くあなたがレビューをお勧めしますこれを行う方法について.

Azure Active Directory Premium を持つテナントの場合、条件付きアクセスを使用して、テナント、アプリ、またはユーザー レベルでレガシ認証をブロックできます。しかし、条件付きアクセスのみが適用されるように 後 初期認証が行われる場合、Exchange のサービス レベルでレガシ認証を無効にする必要があります。

マイクロソフトはレガシー認証を無効にすることを推し進めています 最近発表された 現在使用していないテナントから退出すること。これらのテナントの所有者は、メッセージ センター通知によって通知されます。

多要素認証の実装

多要素認証 (MFA) は、ユーザーサインインの追加の検証を提供する非常に効果的な方法です。大規模な組織ではフィッシング攻撃が日常的に行われるため、多くの場合、機密データにアクセスできる攻撃者に対する最後の防御手段となる可能性があります。また、実装も非常に簡単です。

Azure Active Directory Premium を使用するテナントの場合、条件付きアクセスを実装して、MFA をバイパスするなど、いくつかのクールなシナリオを可能にできます。 信頼できるデバイスを使用し、信頼されたネットワークから、ユーザー状態の変更に基づいて要件を再評価することさえできます。 継続的な評価 特徴。

Azure AD Premium を持っていない場合でも、テナントを保護することができます。 Azure AD のセキュリティの既定値.これにより、条件付きアクセスの柔軟性は失われますが、すべてのユーザーに MFA を非常に簡単に適用できます。

Exchange オンライン メール コネクタの理解とセキュリティ保護

Exchange Online には既定の送受信コネクタがあり、Exchange オンプレムとは異なり、それらを表示または変更することはできません。Exchange Online には、Office 365 のマイクロソフト ディフェンダーを通じて利用可能なトップクラスのメール保護がいくつかありますが、活用するには追加のライセンスが必要です。一部の組織では、受信メールと送信メールの保護をマイクロソフトに完全に移行するのではなく、サードパーティのサービスを維持することを選択しますが、Exchange Online では完全にサポートされていますが、この構成に関する考慮事項がいくつかあります。

最も重要な考慮事項は、上記の既定のコネクタです。サードパーティ製のゲートウェイを経由して受信メールをルーティングするように MX レコードを設定する場合、MX レコードは強制的なメール ルートではなく、他のメール システムにアドバタイズ/優先パブリック メール ルートを知らせることを覚えておくことが重要です。既定では、外部システムが Exchange Online に直接メールを送信するのを阻止するものは何もありません。

この問題を防ぐために、Exchange Online では、外部ドメインからのメールが指定された送信元からのみ受け入れられるように、新しいコネクタが必要です。このコネクタは、すべての受信メールをキャッチするドメインとして “*" を指定する必要があり、図 1 に示すように設定できます。

私の推奨は、設定したメール コネクタに対して、可能な限り証明書の検証を使用し、TLS を適用することです。IP ベースの制限は利用できますが、パブリック証明書を使用して TLS を適用するほど安全ではありません。

このコネクタを設定すると、メールが Exchange Onli に直接送信されるときne は、配信状態通知 5.7.1 で拒否されます。

SPF、DKIM、DMARC を実装します。

送信者ポリシー フレームワーク (SPF)、ドメインキー識別メール標準 (DKIM)、およびドメイン ベースのメッセージ認証、レポートおよび準拠 (DMARC) は、パブリック メール ドメインの評判を保護する電子メール セキュリティ コントロールです。これらは、ドメインからのスプーフィングされたメールが受信者によってブロックされていることを確認しながら、送信メールを確実に検証するために使用されます。

他の組織のメール システムの保護標準を制御することはできませんが、ドメインから受信したメールが正当なものかどうかを判断し、ドメインがスプーフィングされている場合に通知を受け取ることができます。

各コントロールの簡単な説明を見てみましょう。

• SPF は、パブリック DNS TXT レコードを使用して、ドメインの承認された送信元メール システムを組織に通知します。これは、ドメインの送信元 IP アドレス/範囲を公開することによって行われます。また、A レコードまたは MX レコードを許可されたソースとして指定できる検索機能もあります。
• DKIM は、電子メールのソースを確認することで SPF と同様のジョブを実行しますが、送信メールに証明書署名を使用するため、複雑なシナリオでより効果的です。暗号化されたヘッダーは、DKIM 署名証明書を使用して送信メールに追加され、パブリック DNS CNAME レコードを介してアドバタイズされる公開キーに対して検証できます。

SPFとDKIMのセットアップの詳細な内訳については、アラン・バーンの記事をチェックしてください ここは.

• DMARC は、特定のコントロールではなく、ドメインから SPF と DKIM を検証する際に外部メール サーバーが受け入れるべき一連の命令であるという点で、少し異なります。DMARC は、ドメインからメールを受け取ったときにサーバーがフォローするようにサーバーを受信するために、パブリック DNS でこれらの「指示」を公開することで機能します。このレコードは、次の値を指定できる TXT レコードです。
  • v – 使用されている DMARC のバージョンは何ですか?(現在、唯一のバージョンはバージョン1です)
  • aspf – SPF を検証する必要がありますか?
  • adkim – DKIMを検証する必要がありますか?
  • p / fo – SPFおよび/またはDKIMが失敗した場合はどうなりますか?(何もない、検疫、拒否)
  • rua – 集約レポートは、メールシステムとアドレスに返信する必要がありますか?
  • ruf – 個々の障害/フォレンジックレポートをメールシステムに送信し、どのアドレスに送り返す必要がありますか?
  • sp – サブドメインに対して別のポリシーを設定する必要がありますか?
  • pct – *DMARCが適用されるメールの割合は?

*DMARCを展開する際、メールの適用対象の割合を指定し、100% の方向に徐々に作業することができます。

完全に実装された DMARC TXT レコードは次のようになります。

これらの各コントロールを使用すると、単にドメインをスプーフィングから保護するだけでなく、正当なメールが受信者側でスパムと見なされる可能性を最小限に抑えることができます。これは、適切な送信メール フィルタリングを実施することに代わるものではありませんが、パブリック ドメインを保護し、潜在的な問題に関する洞察を得るのには、大いに道のりがつきます。

Azure AD アプリの管理者の同意を有効にする

ユーザー認証のセキュリティ保護は、組織内のデータへの不正アクセスを防止する上で効果的な手順ですが、攻撃者がユーザーのアカウントを制御するために使用できる他の手段もあります。これらの方法の1つは、データ/プロファイルの側面(スコープ)へのアクセス許可をユーザーに付与するよう要求するアプリケーションを作成することです。これは、ユーザーの代わりにサービスにアクセスする必要があるアプリケーション開発者にとって非常に便利です。

ティとのリスクs タイプのアクセスは、どのアプリケーションがテナントにアクセスできるかを (デフォルトで) 事前に定義しない、ユーザーが悪意のあるアプリからのアクセスに同意してしまう可能性があります。アプリケーションに定義されたスコープのアクセス許可が付与されると、ユーザーの代わりにユーザーパスワードや MFA がデータにアクセスする必要はありません。ユーザーは、アプリにサインアップするときに同意するように求められます(図 3 参照)。

このリスクに対処するには、Azure AD で管理者の同意を構成できます。これにより、ユーザーが直接アプリケーションに同意を与えることを防ぎ、代わりに管理者がアプリケーションの安全を確保した後で承認することができます。チェックアウトすることをお勧めします この記事 Azure AD で管理者の同意を実装する方法の詳細な詳細については、を参照してください。

外部電子メールタグ付けの実装

ユーザーが外部メールを簡単に識別できるように支援することは、フィッシングやスプーフィングの試みから保護するために長い道のりを歩むことができます。メールにタグを追加すると、メールに機密性の高いコンテンツが含まれている場合は、余分な警戒が必要であることがエンドユーザーに明らかになります。外部メールのタグ付けを実装する方法はいくつかありますが、それぞれが同様の結果を提供するため、どちらを使用するかはあなた次第です。

これを実現する最初の方法は、図 5 に示すような外部から発信される電子メールに免責事項を追加するトランスポート ルールを実装することです。

このルールは、ユーザーの注意を引くためにHTMLコンテンツを追加することさえできます、この例は図5に示されています:

この方法の欠点は、最初の数行のテキストが常に免責事項であるため、メール クライアントのメッセージ プレビュー機能を中断する傾向にあります。

これを実装するもう 1 つの方法は、単にテキストを件名に付加することです。これはトランスポート ルールでも実行できます。メッセージ・トレイルに対する応答が出るたびにこのルールのトリガーを停止するには、図 6 に示すように、ルールに例外を追加してください。

Outlook を使用して異なるプラットフォームから Exchange Online にアクセスするだけの組織には、組織全体で有効にできる組み込みの外部電子メール タグ機能もあります。このタグ (図 7 に示す) は Outlook/Outlook Web にのみ表示されるため、組織内のメール アプリを考慮する必要があります。

この機能を有効にする方法は、図 8 に示すように、Exchange オンライン PowerShell で単一のコマンドを実行するのと同じくらい簡単です。

モバイル アプリケーション管理

マイクロソフト エンドポイント マネージャー (MEM) / Intune – あなたがそれに対してライセンスを受けているなら ユーザーが組織内のデータに接続するときに、信頼できないデバイスまたは場所へのエクスポートからデータを保護できる強力な機能を提供できます。モバイル アプリケーション管理ポリシーを実装することで、企業アプリケーション (Outlook Mobile など) からのデータのエクスポートを制限できます。これにより、企業データを危険にさらすことなく、多くの BYOD シナリオのロックを解除できます。モバイル アプリケーション管理は、モバイル アプリケーション管理の操作のみであることに注意してください。 サポートされているアプリケーション したがって、MAM を有効にする場合は、図 9 に示すように、条件付きアクセスを使用してこれらのアプリケーションへのモバイル アクセスも制限するようにしてください。

Office 365 のマイクロソフト ディフェンダーを構成する

Office 365 (以前の Office 365 ATP) のマイクロソフトディフェンダーは、フィッシング、マルウェア、通常のスパムなどの悪意のある電子メール トラフィックのすべての種類から Exchange Online を保護するための強力なツールです。それはいくつかを必要としますが プレミアム ライセンス、利用可能な機能セットと保護は、利用可能な 機能の長いリスト.

Office 365 の Defender の使用を開始する場合も、痛みである必要はありません。 あなたはここでその詳細を読むことができます.

データ損失防止ポリシーの定義

データ損失防止 (DLP) ポリシーを使用すると、組織が組織を離れるデータをセキュリティで保護し、制御できます。DLP ポリシーを定義することで、コンテンツ内で外部で共有される特定のパターン (または機密情報の種類) を検出でき、一連のルールを適用して、データがテナントの終了を許可されているかどうかを判断できます。

たとえば、クレジット カード番号のリストを含む電子メールはコンテンツのためにブロックできますが、1 つのクレジット カード番号を送信することはできますが、Office メッセージ暗号化が適用されている場合は、その番号を送信できます。DLP はユーザーの警戒とトレーニングと共に使用する必要があり、データの保護に関しては良い方法を置き換えるようには設計されていません。

定義されると、DLP は SharePoint オンライン、OneDrive、さらには Microsoft Teams.ポリシーを拡張するには、次のように設定する必要があります。 統一されたポリシー マイクロソフト 365 コンプライアンス センター内で。任意のメソッドを介して外部で共有できる(またはできない)ものに対してテナント内のルールのセットを1つだけ持つことは、コントロールの「抜け穴」を避けることができます。

Office 365 の DLP ポリシーの詳細については、チェックアウトをお勧めします この記事 ポール・カニンガム著。

注: Exchange 用 DLP には、Exchange オンライン プラン 2 のライセンスの最小値が必要です。

---

概要

Exchange Online 環境のセキュリティを向上させるために実装できる方法は多数あり、マイクロソフトやサードパーティの企業がセキュリティイニシアチブを支援するツールも増えます。

また、多くの高度な機能と設定を検討する必要がありますが、この記事では、Exchange Online テナントを適切なセキュリティ ベースラインと姿勢に合わせてすぐにすぐに実装できる最も重要な手順について詳しく説明しました。