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

2021年7月31日

[ad_1]

多くの組織にとって、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 に示すように設定できます。

EXO 管理者がデフォルトで EXO をセキュアにするために必要な最も重要な手順 — *図 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 レコードは次のようになります。

</p> <p> v=DMARC1;p=拒否。rua=mailto:DMARCValidation@adminseanmc.com;ruf=mailto:DMARCIndividualReports@adminseanmc.com;fo=1;adkim=s;aspf=s;

v=ドマルク1; p=リジェクト; ルア=メールト:ドマークの検証@管理者向けmc.com; ルフ=メールト:個人レポート@管理者向けmc.com; フォ=1; アドキム=s; アスプフ=s;

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

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

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

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

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

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

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

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

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

図 5: HTML 免責事項

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

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

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

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

</p> <p>外部を設定するOutlook -有効:$true

セット–外部インOutlook –有効:$真

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

マイクロソフトエンドポイントマネージャー (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 のライセンスの最小値が必要です。