Microsoft 365の不正ログイン対策、外注するときの依頼項目

Microsoft 365 の不正ログイン対策を外部に委託する際は、まず自社で利用中のライセンス種別と管理者権限を正確に把握し、MFA やメール保護の対象範囲を明確にします。次に、整理した情報をもとにベンダーへ依頼すべき設定項目と期待する成果物をリスト化し、契約書に落とし込むことが重要です。

最初の具体的なアクションは、管理画面で現在のライセンスと全管理者ロールを一覧化し、担当者に共有することです。

現状把握と依頼前の準備

ライセンスと権限の確認ポイント

まず管理者に、契約しているMicrosoft 365のプラン、追加契約、利用者への割り当て、現在の認証設定を一覧にしてもらいます。名前が似たプランでも利用できる機能や条件は異なるため、希望する対策が現契約で使えるかは、Microsoftの最新資料と契約先に確認してください。

Microsoft Entra IDなど、認証を担うサービスとの関係も、必要な範囲で提供会社に説明してもらいます。

次に管理者ロールと担当を整理します。誰が設定を変えられるか、外部の保守会社が何にアクセスできるか、緊急時に会社として管理を続けられるかが確認点です。外注の見積もりには、この現状点検と不足条件の説明を含めましょう。管理権限や秘密の認証情報を、見積もりの段階で無制限に渡す必要はありません。共有する資料は必要な範囲へ絞り、安全な受け渡し方法を決めます。

ユーザー影響の把握方法

不正ログイン対策は、ユーザーの操作感に直接影響します。例えば MFA の強制適用はログイン手順が増えるため、業務に支障が出ないか事前に確認が必要です。まずは主要な業務フロー（メール送受信、Teams 会議、ファイル共有）を洗い出し、各フローで必要な認証レベルを評価します。

影響が大きい部署や外部取引先がいる場合は、段階的導入や例外設定の有無も検討材料になります。

ユーザーへの周知方法も合わせて計画してください。社内ポータルやメールで「MFA 導入に伴う手順」を案内し、テストユーザーで事前に動作確認を行うと本格導入時のトラブルを減らせます。ベンダーに依頼する際は、影響評価結果と周知プランを添付し、「この範囲で設定を行い、影響が出た場合は事前に通知してください」と具体的に指示するとスムーズです。

依頼資料に必要な情報リスト

外部ベンダーに作業を委託する際は、以下の情報をまとめた資料を用意するとやり取りが円滑になります。

1. ライセンス一覧：プラン名、ユーザー数、Premium の有無。
2. 管理者ロール表：全管理者の氏名、メールアドレス、ロール種別。
3. MFA 現況：適用済みユーザー、未適用ユーザー、使用中の認証アプリ。
4. メールフロー：使用しているドメイン、外部メールサーバー情報、既存の SPF/DKIM 設定。
5. デバイス管理：Intune の適用範囲、モバイルデバイスの登録状況。
6. 業務影響評価：主要業務と認証要件、例外が必要なケース。

このリストをベースに、ベンダーへ「上記項目を踏まえて、MFA と条件付きアクセスの設定、メール認証の強化、ログ取得とアラート設定を実施してください」と依頼書を作成します。資料が揃っていれば、ベンダーは作業範囲を正確に見積もり、余計な質問を減らすことができます。

認証・アクセス制御の設定項目

多要素認証（MFA）の導入範囲

MFA は不正ログイン防止の基本ですが、全ユーザーに一律適用すると業務負荷が増えるリスクがあります。まずはリスクが高いと判断したユーザー（管理者、外部取引先、特権アカウント）に優先的に適用し、段階的に範囲を拡大する計画を立てます。

ベンダーに依頼する際は、対象ユーザーリストと適用開始日を明示し、「対象外ユーザーには例外ポリシーを設定し、理由を記録してください」と指示してください。

導入時の認証手段（Microsoft Authenticator、SMS、電話）も選択肢として提示し、ユーザーが使いやすい方法を選べるようにします。また、MFA の有効化後は、ログイン失敗回数やリスクイベントを Microsoft Entra ID のサインインレポートで確認し、異常があれば即座にベンダーへ報告するフローを設けます。

これにより、設定ミスやユーザーの操作ミスを早期に検知できます。

条件付きアクセスポリシーの設計

条件付きアクセスのように利用状況に応じてアクセスを制御する機能を検討する場合は、先に自社で必要な場面を説明します。会社のPC、私物端末、社外勤務、外部協力者では条件が異なります。「未管理の端末をどう扱いたいか」「社外から必要な業務は何か」を整理し、実現できる制御と必要な契約を提供側に確認してもらいましょう。

場所や製品名だけで安全・危険を決めたり、全社へ一斉に遮断設定を入れたりしません。試験対象、影響するサービス、適用前後の確認、設定を戻す担当、管理者が締め出された場合の手順を作業計画へ含めます。例外を設ける必要があれば、承認者、理由、見直し時点も記録します。

依頼内容は特定の設定値の押し付けではなく、業務要件に対する提案と、限定した範囲での検証としてまとめます。

管理者ロールと最小権限の設定

セキュリティ対策の根幹は、管理者権限を最小限に抑えることです。ベンダーに依頼する際は、現在の管理者ロールをレビューし、不要な全域管理者権限を削除する計画を提示します。具体的には、以下の手順を依頼書に記載します。

1. ロールの棚卸：全管理者の権限を一覧化し、業務に必要なロールだけを残す。
2. 最小権限ロールの作成：ユーザー管理者、セキュリティ管理者、デバイス管理者など、目的別に分割したロールを新規作成する。
3. 権限移行と検証：既存の全域管理者から新ロールへ権限を移行し、実際の操作で問題がないかテストする。

ベンダーはこのプロセスを実施した後、変更履歴と権限マトリクスを文書化して納品します。これにより、誰が何にアクセスできるかが明確になり、内部統制の強化につながります。

メールセキュリティと脅威対策の依頼内容

フィッシング防止のメール設定

メール保護は、自社の契約に含まれる機能と追加契約が必要な機能を分けて確認します。提供側には、不審な送信者、添付ファイル、リンクへの対策を現在どこまで使っているか、設定の変更で何が変わるかを説明してもらいましょう。訓練や教材の配信なども、すべてのプランに含まれると決めつけず、対象と費用を確認します。

外注の範囲には、正しい業務メールが隔離されたときの確認と救済も含めてください。誰が隔離を確認し、どの承認で利用者へ戻すか、担当者不在時にどう扱うかが実際の運用に関わります。導入前後の試験では、許可されたテスト用メールや提供元が案内する検証方法を使い、実際の攻撃メールを社内へ転送して試さないようにします。

検出件数だけで効果を判断せず、誤検知と報告・対応の手間も確認します。

SPF/DKIM/DMARC の構成確認

送信ドメインの認証設定を外注するときは、まず会社のドメインからメールを送るサービスを洗い出します。Microsoft 365だけでなく、問い合わせフォーム、請求書送信、メール配信などがあるためです。SPF、DKIM、DMARCの現在の設定と各送信元の対応状況を確認し、正規のメールが届かなくならない変更計画を提案してもらいます。

依頼書には、確認対象のドメイン、DNSの管理者、送信元一覧、検証に使う宛先、変更を戻す条件を記載します。DMARCの拒否設定などを現状確認なしに一律適用すると、正規メールの配信へ影響する場合があります。設定の強化は、提供元の最新手順と送信状況の確認に基づいて段階的に行ってください。

納品時には秘密鍵ではなく、変更した設定、確認結果、継続して確認する担当と手順を受け取ります。

外部委託先のメール検査ツール要件

メールセキュリティを外部ベンダーに委託する場合、使用する検査ツールの要件を明確にしておくことが重要です。以下の項目を依頼書に記載すると、ベンダー選定がスムーズになります。

• リアルタイムスキャン：受信メールが届く瞬間にマルウェアやフィッシングリンクを検出できること。
• サンドボックス解析：添付ファイルを安全な環境で実行し、未知の脅威を検出できる機能。
• レポート機能：検出結果を管理者向けにダッシュボードで可視化し、定期的に CSV 形式でエクスポートできること。
• プライバシー遵守：メール内容を第三者に漏洩しないよう、暗号化やデータ保持ポリシーが明示されていること。

ベンダーは上記要件を満たすツールを提示し、導入前に試用期間を設けて実際の検出率や運用負荷を評価します。その結果を踏まえて本番導入の可否を判断し、導入後は定期的なチューニングを依頼することが推奨されます。

運用・監視体制の確認と成果物

ログ取得とアラート設定の依頼項目

ログは、誰がどこへアクセスしたか、不審な操作があったかを後から確かめる材料です。サインイン、管理操作、メール送信など、必要な記録が現在の契約で取得できるかを確認します。提供側には、項目、標準の保持期間、延長や取り出しの方法、追加費用を説明してもらい、業務・契約・調査上必要な範囲と照らしてください。すべての会社に共通する保存日数を前提にはしません。

アラートは通知を設定して終わりではありません。どの事象を誰が受け取り、不在時に誰へ回し、どこからを外部へ依頼するかを決めます。試験には安全な確認方法を使い、通知から社内の判断までの流れを確認してください。納品物は設定一覧、記録の抽出方法、試験結果、対応担当表です。ログが残ることと、誰かが継続して監視・対応する契約であることも分けて確認します。

インシデント対応フローの整備

不正ログインの疑いが出たら、検知した情報、時刻、対象アカウント、業務への影響を社内の責任者へ伝える流れを決めます。提供会社へは、調査、対象アクセスの制限、認証情報の更新、復旧について、どの操作を誰の承認で行うかを説明してもらいます。初動を止めないために、事前に合意できる操作と、都度判断が必要な操作を分けることが重要です。

端末内のデータを消す操作などは、証拠や業務データを失う場合があるため、定型手順として無条件に組み込みません。保存すべき記録と対応の順番は、状況に応じて専門担当者が判断します。連絡手段が使えなくなった場合の代替連絡先、会社側の判断者、外部対応の受付条件も文書にしてください。設定変更を依頼する契約と、事故時の調査・復旧を依頼する契約が同じ範囲かも確認します。

成果物のレビューと継続的改善

外部委託の最終段階では、納品された設定やドキュメントが期待通りに機能しているかをレビューします。具体的なチェック項目は次の通りです。

• 設定項目の一覧：MFA、条件付きアクセス、メール保護、ログ保存の各設定が完了しているか。
• テスト結果レポート：テストユーザーでのログインシナリオやメール送受信テストの結果が記載されているか。
• 運用マニュアル：インシデント対応フロー、定期的なレビュー手順、ベンダーへの問い合わせ窓口が明示されているか。

レビュー後に不足や修正があれば、ベンダーに再作業を依頼します。また、定期的（例：半年ごと）に設定の見直しと脅威情報のアップデートを行う契約条項を入れておくと、長期的にセキュリティレベルを維持できます。最終的に、社内の情報システム部門とベンダーが共同で「次のステップ」を決め、必要に応じて追加の設定や教育を計画してください。