Microsoft が Microsoft 365 ベースライン セキュリティ モード（BSM）の設定ガイダンスを更新した今、特に中小規模の Microsoft 365 テナントは一度見直す価値があります。結論から言うと、BSM は「推奨設定を一括で押し付ける機能」ではなく、Microsoft 365 管理センターから設定ごとに評価し、影響レポートやシミュレーションを見ながら、既定で安全な状態に近づけるための運用基盤です。以前は PowerShell 前提だった一部設定も管理センターから扱えるため、専任のセキュリティ担当者がいない組織ほど恩恵を受けやすくなっています。(Microsoft Learn)
ただし、EWS の無効化、レガシ認証の遮断、SharePoint のカスタム スクリプト制限、Microsoft Publisher のブロックは、昔から動いている業務フローほどぶつかりやすい論点です。この記事では、Microsoft 365 ベースライン セキュリティ モードの更新ガイダンスを踏まえて、どこが実務的に重要で、何から見直すべきかを整理します。(Microsoft Learn)
Microsoft がベースライン セキュリティ モード設定の更新で強調したこと
今回のガイダンスで大きいのは、設定を個別に管理できることと、影響レポートを先に見てから段階適用することが明確に打ち出されている点です。Microsoft は、各設定について影響レポートを実行し、影響がゼロなら有効化し、重要な依存関係があるなら恒久適用の前に対処するよう案内しています。設定は独立して管理できるため、必要なら数日単位で戻して依存関係を見極める運用も取りやすくなっています。さらに Microsoft Security Blog では、ギャップの特定、What If 分析によるシミュレーション、ダッシュボードとテレメトリによる可視化、そしておおむね 6〜12 か月ごとの大きな更新サイクルが示されています。つまり BSM は、一度オンにして終わりの設定集ではなく、継続的に見直す前提の運用モデルです。(Microsoft Learn)
Microsoft 自身も、BSM を「ガイダンスから強制へ移す」仕組みとして位置付けています。公式の Inside Track ブログでは、BSM は planet-scale の運用経験と過去のセキュリティ インシデント分析を基に設計され、理論上の端のリスクよりも、実際によくある誤設定を減らすことに重きを置いていると説明されています。中小規模テナントにとって価値が高いのは、まさにこの点です。難解な理想論ではなく、現場で起きやすい事故を減らすための「最低基準」が整備されているからです。(Microsoft)
なぜ中小規模の Microsoft 365 テナントほど再評価すべきなのか
BSM は、Microsoft 365 アプリ、SharePoint と OneDrive、Microsoft Teams、Exchange Online、Microsoft Entra ID プラットフォームを対象にし、Microsoft 365 管理センターから扱えます。しかも Microsoft は、ベースライン セキュリティ モード設定をすべての Microsoft 365 サブスクリプションとプランで構成できると案内しています。以前は PowerShell でしか触れなかった設定も管理センターで評価しやすくなったため、「人手が少ない」「担当が兼任」「複数サービスをまたぐ設定変更に慣れていない」という組織ほど再評価する意味があります。(Microsoft Learn)
もう一つの理由は、Microsoft 365 のリスクが ID だけで完結しないからです。古いファイル形式、SharePoint の旧式な認証、EWS 依存の連携、Teams Rooms のリソース アカウントなど、日常運用の「古いまま動いているもの」が攻撃面になります。BSM はこれらを横断して最低限の安全ラインを引くため、Security Defaults だけでは足りないけれど、最初から複雑な Conditional Access を全部自前設計するのも重い、という中小規模テナントにちょうどはまりやすい立ち位置です。(Microsoft Learn)
Microsoft 365 ベースライン セキュリティ モードで見直せる主な領域
| 領域 | 代表的な見直し項目 | 実務で詰まりやすい点 |
|---|---|---|
| 認証とアプリ | 管理者へのフィッシング耐性認証、レガシ認証のブロック、アプリへの新規パスワード資格情報追加の禁止、ユーザー同意の制限 | 管理者の認証方法、古いメールクライアント、自己承認の SaaS 連携 |
| SharePoint / OneDrive | 旧式ブラウザー認証・旧式クライアント認証の遮断、新規カスタム スクリプトの禁止、SharePoint Store 制限 | 旧来のポータル、クラシック ページ、カスタム コード依存 |
| Exchange / 連携 | EWS の組織全体無効化 | Power Query、Power BI / Fabric、クロステナント共有、ハイブリッド構成 |
| Microsoft 365 アプリ / ファイル | 古いファイル形式の Protected View、ActiveX / OLE / DDE のブロック、Publisher のブロック | 互換性重視で残った古い文書運用 |
| Teams Rooms | リソース アカウントのファイルアクセス制限、準拠済み管理デバイスのみサインイン許可、未管理端末からのサインイン制限 | 会議室デバイスや共有端末の運用 |
表の内容は、Microsoft Learn の BSM 設定ガイドと関連ドキュメントをもとに整理しています。(Microsoft Learn)
設定画面が見つからない、または一部項目だけ変更できない場合は、まずロールを疑うのが近道です。Microsoft は、ワークロード別管理者は自分の領域だけを管理できると案内しており、BSM は RBAC に対応しています。たとえば Office Apps administrator、SharePoint administrator、Exchange Administrator、Teams administrator などのロールが関連します。アクセス経路は、Microsoft 365 管理センター > Settings > Org Settings > Security and Privacy > Baseline Security Mode です。(Microsoft Learn)
まず候補にしやすい設定と、慎重に扱う設定
先に検討しやすい設定
管理者向けのフィッシング耐性認証は、優先度が高い設定の一つです。Microsoft は、特権管理者は攻撃者の主要な標的であり、フィッシング耐性のある多要素認証を要求することが侵害リスク低減に有効だと説明しています。実務では、FIDO2 セキュリティ キー、Windows Hello for Business、証明書ベース認証など、管理者が使う認証方法の準備ができているなら、かなり前向きに検討しやすい項目です。(Microsoft Learn)
Teams Rooms や会議室端末を使っていないテナントでは、ルーム デバイス関連設定は影響レポートがゼロになりやすく、先に進めやすい候補です。同様に、Microsoft Publisher をすでに使っていない組織なら、Publisher ブロックも比較的判断しやすい設定です。BSM 側でも Publisher は攻撃面が大きいアプリとして扱われており、Microsoft サポートも 2026 年 10 月以降は Publisher が Microsoft 365 に含まれなくなると案内しています。(Microsoft Learn)
慎重に扱う設定
逆に、レガシ認証の遮断、EWS の無効化、SharePoint のカスタム スクリプト制限は、影響レポートを見ずに一気に有効化しないほうが安全です。これらはセキュリティ効果が大きい一方で、古いクライアント、分析連携、ハイブリッド構成、クラシック ページなど、長く放置されていた依存を表面化させやすいからです。特に「今も動いているから大丈夫」と思われている資産ほど、BSM 導入時の見落としになりやすいポイントです。(Microsoft Learn)
失敗が多い3つのポイント
EWS 無効化は「古い連携」を一気にあぶり出す
EWS の組織全体無効化は、攻撃面を減らすうえで有効ですが、同時に運用影響も大きい設定です。Microsoft は、EWS を無効化すると一部の Outlook / Web add-in ビルドへの影響があり得るほか、Exchange connector を使う Excel for Windows / web、Power BI Desktop、Power BI / Fabric Dataflows、Power Platform Dataflows、Dynamics 365 Customer Insights などが動かなくなるケースを明示しています。さらに、クロステナントの予定表共有・Free/Busy・MailTips、ハイブリッド Exchange、Dynamics on-premises 連携にも注意が必要です。(Microsoft Learn)
EWS を止める前に、少なくとも次は棚卸ししておくと失敗しにくくなります。
- Excel や Power BI / Fabric で Exchange connector を使っていないか
- 他社テナントとの予定表共有や Free/Busy 参照を運用していないか
- ハイブリッド Exchange や Dynamics on-premises の同期が残っていないか
- Office add-in や Teams パネル端末が古いビルドのままではないか
この確認を飛ばすと、セキュリティ設定の導入後ではなく、業務部門からの「急に見えない」「同期できない」で初めて問題が表面化しがちです。(Microsoft Learn)
レガシ認証の遮断は、複合機と古いメール経路の棚卸しが先
Microsoft は、BSM のレガシ認証ブロックで想定している対象として、Office 2010 のような古いクライアントや、IMAP / SMTP / POP3 などの古いメール プロトコルを挙げています。さらに Microsoft の分析では、パスワード スプレー攻撃の 99% 超がこうしたレガシ認証プロトコルを使うとされており、ブロックの効果は非常に大きい一方、古い業務機器に残った認証経路を見逃すと障害になりやすい設定でもあります。(Microsoft Learn)
実務では、複合機のメール送信、古いモバイル メール アプリ、POP / IMAP 前提の共有メールボックス運用、長年メンテされていないスクリプトやアプリ接続を先に洗い出すのが定石です。レガシ認証の遮断を「本人が Outlook を使えているか」だけで判断すると、裏側の業務フローを見落としやすくなります。(Microsoft Learn)
SharePoint のカスタム スクリプトと Publisher は「昔から使える」が落とし穴
SharePoint では、新規カスタム スクリプトの許可を止める設定が BSM に含まれています。Microsoft は、カスタム スクリプトを許すとガバナンスの強制やコードの能力制御が難しくなるため、代替として SharePoint Framework を使うよう案内しています。もし一部のクラシック ページだけを残したいなら、SharePoint Online PowerShell の Set-SPOSite にある DisableClassicPageBaselineSecurityMode パラメーターのようなサイト単位の調整手段もあります。テナント全体で適用を止める前に、「本当に例外が必要なのはどのサイトか」を切り分けるほうが現実的です。(Microsoft Learn)
Publisher も同じで、使っていないつもりでも、総務や営業が古い .pub をテンプレートとして残しているケースがあります。Microsoft サポートによると、Publisher は 2026 年 10 月にサポートが終了し、その後 Microsoft 365 には含まれなくなります。Microsoft 365 サブスクライバーは Publisher ファイルを開いたり編集したりできなくなるため、ブロック設定を入れる前に .pub 資産を棚卸しし、閲覧専用は PDF 化、編集継続が必要なものは Word / PowerPoint への移行を進めるほうが安全です。(Microsoft Learn)
Security Defaults や独自 Conditional Access とどう使い分けるか
| 項目 | セキュリティの既定値群 | ベースライン セキュリティ モード | 独自 Conditional Access / 個別設定 |
|---|---|---|---|
| 主な対象 | ID 保護が中心 | Microsoft 365 全体の最低限の安全基準 | 組織要件に合わせた詳細制御 |
| 適用方法 | 基本はオン / オフ | 設定ごとに個別管理 | 管理者が設計して実装 |
| カスタマイズ性 | ほぼなし | 中程度 | 高い |
| 向いている組織 | まず最短で ID 保護を入れたい | Microsoft 365 全体を既定で安全な状態に近づけたい | 例外条件や制御条件が多い |
この使い分けは、Security Defaults が「カスタマイズなしのオン / オフ」で、Conditional Access がフル カスタマイズ可能、BSM がその中間で Microsoft 365 全体の設定を個別に見直せる、という位置付けで考えると理解しやすくなります。Microsoft の公式ドキュメントでも、Security Defaults は多くの組織が必要とするカスタマイズに対応しておらず、BSM は Microsoft 365 ワークロード全体にわたる推奨設定を束ねるものとして説明されています。(Microsoft Learn)
なお、BSM の中でも「管理者へのフィッシング耐性認証要求」と「レガシ認証のブロック」は Conditional Access ポリシーとして表示されます。Created by 列には Baseline security mode と表示され、これらのポリシーは Microsoft ではなく管理者が作成する扱いです。ロックアウト事故を避けるため、運用前に break-glass / 緊急アクセス アカウントの除外方針を決めておくと安全です。(Microsoft Learn)
失敗しにくい導入手順
- 権限と緊急アクセス アカウントを先に整える
BSM は RBAC 前提です。作業者のロール不足で調査が止まるケースと、管理者ロックアウトのケースを最初に潰します。(Microsoft Learn) - 依存関係を 4 つだけ先に棚卸しする
まず見るべきは、レガシ認証、EWS 連携、SharePoint カスタム スクリプト、Publisher /.pub資産です。ここを飛ばすと、BSM の効果より先に運用障害が表面化しやすくなります。(Microsoft Learn) - 影響レポートと What If 分析を設定単位で回す
Microsoft の推奨どおり、ゼロ影響の設定から有効化し、依存関係が見つかった設定は別トラックで対処します。(Microsoft Learn) - ゼロ影響の設定だけ先に有効化し、一定期間は問い合わせを観察する
いきなり全部やるのではなく、問い合わせ傾向とサインインの変化を確認してから次の設定に進むほうが、ヘルプデスク負荷を抑えやすくなります。(Microsoft) - 高影響設定はパイロット適用し、例外を最小化する
EWS、レガシ認証、カスタム スクリプトなどは「恒久的に例外を増やす」のではなく、どの資産を置き換えれば例外を閉じられるかまで決めてから進めると、BSM 本来の効果が出やすくなります。大きな更新は 6〜12 か月程度の周期で入るため、四半期ごとの見直しを習慣化すると追従しやすくなります。(Microsoft)
2025 年 11 月から 2026 年 2 月上旬にかけて BSM 画面にアクセスしていたテナントでは、関連する Microsoft Entra ID の Conditional Access ポリシー草稿が 2 つ、無効状態で作成されていることがあります。Microsoft はこれをセキュリティ インシデントではなく、テナントのセキュリティに影響しないと説明しているため、過去に試しただけのテナントでも一度確認しておくと安心です。(Microsoft Learn)
まとめ
Microsoft 365 ベースライン セキュリティ モードの更新ガイダンスで重要なのは、「推奨設定の一覧が増えた」ことよりも、管理センターから個別に評価し、影響を見ながら既定で安全な状態へ段階的に寄せられるようになったことです。中小規模テナントほど、この進め方は実務に合います。最初の一歩としては、Microsoft 365 管理センターで BSM を開き、まずはレガシ認証、EWS、SharePoint カスタム スクリプト、Publisher の 4 点に絞って影響レポートを確認してください。そこが見えれば、「今すぐ有効化できる設定」と「先に置き換えが必要な設定」がかなり明確になります。(Microsoft Learn)
コメント