Microsoft Secure Scoreは、Microsoft Defenderポータルで組織のセキュリティ体制を数値化し、次に何を直せばよいかを示す管理者向けの指標です。単に点数を上げるための画面ではなく、Microsoft 365のID、アプリ、デバイス、データにまたがる設定不備を見つけ、優先順位を付けて改善するための実務ツールと考えると分かりやすいです。Microsoftの公式情報では、Secure Scoreは組織のセキュリティ体制を測定するもので、推奨アクションの実施状況がスコアに反映されます。(Microsoft Learn)
今回、Microsoft Defender XDRにおけるMicrosoft Secure Scoreで管理者が特に確認すべきなのは、総合点だけで判断しないこと、ID・アプリ・デバイス別の内訳を見ること、Unified RBACによるアクセス権限の影響を確認すること、そして推奨アクションを業務影響込みで優先順位付けすることです。特にDefender XDRの更新では、Secure Scoreのカテゴリ計算が見直され、一部のクラウドアプリ関連の推奨事項がID関連として扱われるようになっています。総合Secure Scoreは変わらなくても、IDスコアやアプリスコアの内訳が変わる可能性があるため、月次レポートやKPIでカテゴリ別スコアを使っている組織は確認が必要です。(Microsoft Learn)
Microsoft Secure Scoreとは何か
Microsoft Secure Scoreは、Microsoft Defenderポータルから確認できるセキュリティ体制の評価指標です。管理者は、現在のスコア、推奨アクション、スコアの推移、類似組織との比較などを見ながら、どの設定を改善すべきかを判断できます。公式ドキュメントでは、Secure Scoreは現在のセキュリティ体制の報告、改善のための可視化とガイダンス、ベンチマーク比較やKPI設定に役立つものと説明されています。(Microsoft Learn)
重要なのは、Microsoft Secure Scoreが「満点を取れば安全」という性質のものではない点です。Secure Scoreは、侵害される確率を絶対的に示すものではなく、Microsoft環境でセキュリティ制御をどの程度利用しているかを表す数値です。Microsoftも、Secure Scoreをセキュリティ侵害に対する保証として解釈すべきではないと説明しています。(Microsoft Learn)
そのため、実務では次のように使うのが現実的です。
| 使い方 | 目的 | 判断のポイント |
|---|---|---|
| 現在のスコアを確認する | 自社のセキュリティ体制を把握する | 総合点だけでなくカテゴリ別に見る |
| 推奨アクションを見る | 改善すべき設定を洗い出す | 点数、難易度、ユーザー影響を比較する |
| 履歴を追う | 改善活動の効果を確認する | 月次・四半期単位で傾向を見る |
| ベンチマークと比較する | 目標設定に使う | 業種や規模が近い組織との比較を参考にする |
| 代替策を記録する | Microsoft以外の対策を反映する | 実装済みの別製品や運用ルールを証跡付きで管理する |
Microsoft Defenderのセキュリティ更新で確認すべき変更点
Microsoft Defender XDRの更新情報では、Secure Scoreのカテゴリ計算に変更が入り、一部のCloud apps関連の推奨事項がIdentityカテゴリに分類されるようになりました。Microsoftの説明では、これは組織IDをより正確に保護するための変更で、総合Secure Scoreは変わらない一方、個別のIDスコアやアプリスコアは変わる可能性があります。(Microsoft Learn)
この変更は、すぐにセキュリティ設定を壊すようなものではありません。ただし、次のような運用をしている組織では影響が出やすくなります。
| 影響を受けやすい運用 | 起こり得る変化 | 管理者の対応 |
|---|---|---|
| 月次レポートでカテゴリ別スコアを報告している | IDスコアやアプリスコアが前月比で変動して見える | 総合点とカテゴリ内訳を分けて説明する |
| KPIに「アプリカテゴリの改善率」を使っている | 分類変更により改善・悪化の見え方が変わる | KPI定義に「カテゴリ計算変更の影響」を注記する |
| SOCや情シスで担当カテゴリを分けている | アプリ担当からID担当へ対応範囲が移る可能性がある | 推奨アクションの所有者を再確認する |
| Power BIなどでSecure Scoreを可視化している | グラフ上のカテゴリ推移が不連続に見える | 更新日を境に注釈を入れる |
特に注意したいのは、総合スコアが変わっていないから対応不要と判断しないことです。IDカテゴリに移った推奨事項は、条件付きアクセス、多要素認証、特権アカウント、SaaSアプリ連携など、侵害時の影響が大きい領域に関係する場合があります。カテゴリの見え方が変わったタイミングで、推奨アクションの内容と担当チームを見直すのが安全です。
Secure Scoreに含まれる主な対象範囲
Microsoft Secure Scoreは、Microsoft Defender単体の点数ではありません。Microsoft 365やMicrosoft Defender関連サービスを横断して、複数の製品に関する推奨事項を表示します。公式ドキュメントでは、Microsoft Entra ID、Microsoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Defender for Office、Exchange Online、SharePoint Online、Microsoft Teams、Microsoft Defender for Cloud Appsなどが対象として挙げられています。(Microsoft Learn)
管理者が見るべき範囲は、主に次の4つです。
ID
Microsoft Entra ID、管理者ロール、多要素認証、レガシ認証、条件付きアクセスなどに関係します。攻撃者は認証情報を狙うため、ID領域の推奨事項は優先度が高くなりやすいです。
たとえば、管理者ロールにMFAを要求する、すべてのユーザーがMFAを完了できるようにする、レガシ認証をブロックする、といった設定はSecure Score上でも重要な改善対象になります。Microsoft Secure Scoreでは、Microsoft Entra IDのセキュリティ既定値をオンにすると、MFAやレガシ認証ブロックに関する推奨アクションでポイントが付与されると説明されています。(Microsoft Learn)
デバイス
Microsoft Defender for EndpointやMicrosoft Defender Vulnerability Managementと関係する領域です。デバイスのMicrosoft Secure Scoreでは、アプリケーション、OS、ネットワーク、アカウント、セキュリティコントロールなどの構成状態が評価されます。(Microsoft Learn)
デバイス領域では、脆弱な設定、未管理デバイス、パッチ管理、暗号化、マルウェア対策の状態などがスコア低下につながります。公式ドキュメントでは、IntuneやAzure ADなどの管理ソリューションに登録されていないアンマネージドデバイスもスコアにカウントされ、重要なセキュリティ評価で非準拠として扱われる場合があると説明されています。(Microsoft Learn)
アプリ
Exchange Online、SharePoint Online、Teams、Defender for Cloud Apps、SaaSアプリ連携などが関係します。メール転送、外部共有、OAuthアプリ、クラウドアプリの設定不備は、情報漏えいの入口になりやすい領域です。
今回のカテゴリ計算変更により、一部のクラウドアプリ関連推奨事項がIDカテゴリへ移る可能性があるため、アプリ担当チームだけで閉じず、ID管理チームと一緒に確認する必要があります。
データ
Microsoft Purview Information Protectionなど、情報保護やDLPに関係する領域です。ラベル、監査ログ、DLPポリシー、外部共有制御などは、すぐに攻撃を止める設定ではないものの、侵害後の被害範囲を抑えるうえで重要です。
スコアの仕組みと誤解しやすいポイント
Microsoft Secure Scoreでは、推奨されるセキュリティ機能の構成、セキュリティ関連タスクの実行、Microsoft以外のアプリケーションや代替の軽減策による対応などでポイントを取得します。推奨アクションによっては完全に完了した場合のみポイントが付与され、ユーザーやデバイスの一部だけが対応済みの場合は部分点になることがあります。(Microsoft Learn)
代表的な誤解は次の3つです。
| 誤解 | 実際の考え方 |
|---|---|
| スコアが高ければ侵害されない | Secure Scoreは保証ではなく、セキュリティ制御の利用状況を示す指標 |
| すべての推奨事項を実施すべき | 業務影響や環境条件に合わないものはリスク受容や代替策で管理する |
| 総合点だけ見れば十分 | ID、デバイス、アプリ、データのどこに弱点があるかを見る必要がある |
特に大切なのは、点数のために設定を変えないことです。たとえば、外部共有を厳しく制限すればスコアは上がるかもしれませんが、取引先との共同作業が止まるなら、業務部門との調整が必要です。逆に、業務影響が小さいにもかかわらずリスク低減効果が大きい設定は、早めに実施すべきです。
管理者が最初に確認すべき設定
Microsoft Secure Scoreを運用に組み込む場合、最初に見るべき場所は「スコアそのもの」ではなく、推奨アクションの中身と権限設計です。
現在のスコアとカテゴリ内訳を確認する
Microsoft Secure Scoreは、DefenderポータルのSecure Score画面から確認できます。公式ドキュメントでは、概要ページでグループ間のポイント配分、使用可能なポイント、総合スコア、履歴傾向、優先順位付けされた推奨アクションを確認できると説明されています。(Microsoft Learn)
確認時は、次の順番で見ると判断しやすくなります。
| 確認順 | 見る項目 | 判断基準 |
|---|---|---|
| 1 | 総合スコア | 急激な低下がないか |
| 2 | カテゴリ別スコア | ID・デバイス・アプリ・データのどこが弱いか |
| 3 | 推奨アクション | 残りポイントが大きく、実装しやすいものは何か |
| 4 | ユーザー影響 | 有効化でログイン、共有、メール運用に影響しないか |
| 5 | 所有者 | 誰が設定変更・承認・検証を行うか |
推奨アクションの状態を整理する
Secure Scoreの推奨アクションには、対応予定、計画済み、受け入れられるリスク、サードパーティで解決、代替の軽減策で解決、完了などの状態があります。公式ドキュメントでは、推奨アクションの状態を選択し、メモを記録できることが説明されています。(Microsoft Learn)
実務では、以下のように使い分けると管理しやすくなります。
| 状態 | 使う場面 | メモに残すべき内容 |
|---|---|---|
| 対処する | 必要性は認識しているが未着手 | 対応予定時期、担当部署 |
| 計画済み | 実施日や手順が決まっている | 変更日、検証方法、ロールバック手順 |
| 受け入れられるリスク | 業務上すぐに実施できない | リスク受容の理由、承認者、見直し日 |
| サードパーティを通じて解決 | 他社製品で同等対策済み | 製品名、ポリシー名、証跡の場所 |
| 代替の軽減策で解決 | 内部運用や別設定で補完済み | 代替策の内容、監査方法 |
| 完了 | Microsoft側で完了確認済み | 変更内容、実施日 |
状態を付けるだけで終わらせず、必ずメモに判断理由を残すことが重要です。半年後に担当者が変わったとき、「なぜこの推奨事項を受け入れリスクにしたのか」が分からないと、監査やインシデント対応で説明できなくなります。
Unified RBACの権限を確認する
Secure Scoreのアクセス管理では、Microsoft Defender XDR Unified RBACの影響を確認する必要があります。公式ドキュメントでは、Secure Score向けの権限はDefender XDR Unified RBACの「Security posture」カテゴリにあり、読み取り専用の「Exposure Management (read)」と、推奨事項を管理できる「Exposure Management (manage)」が説明されています。Secure Scoreデータにアクセスするには、カスタムロールをMicrosoft Security Exposure Managementデータソースに割り当てる必要があります。(Microsoft Learn)
ここで注意すべきなのは、従来のMicrosoft Entraグローバルロールも引き続きSecure Scoreへのアクセスに使われる点です。Security Administrator、Exchange Administrator、SharePoint Administratorなどは読み取り・書き込み権限を持ち、Security ReaderやGlobal Readerなどは読み取り専用になります。(Microsoft Learn)
運用上は、次の見直しをおすすめします。
| 確認項目 | 推奨対応 |
|---|---|
| Secure Scoreを閲覧するだけのユーザー | Exposure Management (read) または読み取り専用ロールに限定する |
| 推奨事項の状態やメモを変更するユーザー | Exposure Management (manage) を必要最小限に付与する |
| 既存の高権限Entraロールを持つユーザー | 本当に必要か棚卸しする |
| 内部ダッシュボードでGraph APIを使っている場合 | Unified RBACだけに移行できると決めつけない |
特に開発者やデータ分析担当がSecure ScoreをPower BIや内部ポータルに取り込んでいる場合は注意が必要です。公式ドキュメントでは、Unified RBACモデルは現在Microsoft Defenderポータルでのみサポートされ、Graph APIを使う場合は引き続きMicrosoft Entraロールを使う必要があると説明されています。(Microsoft Learn)
開発者・運用担当が確認すべき移行と展開の注意点
Microsoft Secure Scoreは管理者向けの画面ですが、実際の展開では開発者、ID管理担当、端末管理担当、SOC、ヘルプデスクが関わります。設定変更を急ぐ前に、次の点を確認しておくと失敗を防げます。
自動化やレポートの前提を見直す
Secure Scoreのカテゴリ計算が変わると、内部レポートで「アプリのスコアが下がった」「IDのスコアが急に変わった」ように見える場合があります。総合点が変わらない変更でも、カテゴリ別KPIや担当部門別KPIには影響します。
Power BI、Excel、社内ダッシュボード、監査レポートでSecure Scoreを使っている場合は、次の3点を確認してください。
- カテゴリ名を固定値として処理していないか
- 前月比・前年比の差分に注釈を入れられるか
- 推奨アクションのカテゴリ変更を異常値として扱っていないか
特に、カテゴリ別スコアを経営層向けに報告している場合は、「改善・悪化」ではなく「Microsoft側の分類変更による見え方の変化」を説明できるようにしておく必要があります。
変更は小さく試してから展開する
Secure Scoreの推奨アクションには、ユーザー体験に影響するものがあります。MFA、レガシ認証ブロック、外部共有制限、メールポリシー、端末設定などは、設定後に問い合わせが増えることがあります。
展開時は、いきなり全社適用せず、次の順番で進めると安全です。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | 推奨アクションを分類する | 点数が高いものだけを優先してしまう |
| 2 | 影響範囲を確認する | 対象ユーザー、端末、アプリを見落とす |
| 3 | パイロット対象を決める | 情シスだけで試し、現場業務を検証しない |
| 4 | ロールバック手順を用意する | 障害時に元に戻せない |
| 5 | ユーザー通知を行う | MFAや共有制限の変更を事前周知しない |
| 6 | 反映後のスコアとログを確認する | スコア反映の遅延を障害と誤解する |
公式ドキュメントでは、推奨アクションの変更がSecure Scoreに反映されるまで24〜48時間かかることがあると説明されています。設定直後にスコアが変わらなくても、まずは構成状態と対象範囲を確認し、反映待ちか設定ミスかを切り分けるのが現実的です。(Microsoft Learn)
デバイスの例外処理に注意する
デバイス領域では、Defender Vulnerability Management側の例外設定がSecure Scoreにどう反映されるかを理解しておく必要があります。公式ドキュメントでは、Defender Vulnerability Managementのセキュリティ推奨事項でグローバル例外を作成した場合、Microsoft Secure Scoreの推奨アクション状態が例外理由で更新され、反映に最大2時間かかる場合があると説明されています。一方、デバイスグループごとの例外ではSecure Scoreは更新されず、推奨アクションは「対処する」のままになります。(Microsoft Learn)
これは運用上かなり重要です。たとえば、特定の部門だけ業務アプリの都合で設定を例外にした場合、デバイスグループ単位の例外ではSecure Score上の見え方が変わらない可能性があります。監査資料では、Secure Scoreの表示だけでなく、例外設定の種類、対象範囲、承認者、見直し日を別途記録しておくべきです。
優先順位の付け方：点数より「リスク低減効果」で判断する
Secure Scoreの推奨アクションは、残りポイント、実装の難しさ、ユーザーへの影響、複雑さなどを基に順位付けされます。公式ドキュメントでも、推奨アクションのランキングは、残りポイント数、実装の難しさ、ユーザー影響、複雑さに基づくと説明されています。(Microsoft Learn)
ただし、現場では点数だけで決めると失敗します。優先順位は次の順で考えると実用的です。
| 優先度 | 対応すべき推奨アクション | 例 |
|---|---|---|
| 高 | 侵害リスクが高く、業務影響が限定的 | 管理者MFA、レガシ認証ブロック、危険な転送設定の制限 |
| 高 | 既に代替策があり、状態反映だけで整理できる | 他社EDRやCASBでカバー済みの項目 |
| 中 | 効果は大きいが調整が必要 | 外部共有制限、条件付きアクセス強化 |
| 中 | 対象範囲を分けて段階展開できる | 端末構成、暗号化、ブラウザ制御 |
| 低 | 業務影響が大きく、代替策も未整理 | 全社一律の厳格制限、例外が多い設定 |
最初に狙うべきなのは、低コストでリスク低減効果が高い項目です。たとえば、管理者アカウントのMFA強制、使っていないレガシ認証の無効化、不要な外部共有設定の整理は、多くの組織で優先度が高くなります。
一方で、エンドユーザーの操作や取引先との連携に影響する項目は、セキュリティ部門だけで決めず、業務部門と影響確認を行うべきです。
Microsoft Secure Score運用のチェックリスト
Microsoft Secure Scoreを初めて本格運用する場合は、次のチェックリストを使うと抜け漏れを防げます。
| チェック項目 | 確認内容 |
|---|---|
| 現在の総合スコアを記録したか | 変更前の基準値を残す |
| カテゴリ別スコアを確認したか | ID、デバイス、アプリ、データの偏りを見る |
| カテゴリ計算変更の影響を確認したか | ID・アプリの内訳変動をレポートで説明できるようにする |
| 推奨アクションの所有者を決めたか | ID、端末、メール、情報保護など担当を分ける |
| Unified RBACの権限を確認したか | 閲覧者と管理者を分離する |
| Entraグローバルロールを棚卸ししたか | 不要な高権限を削減する |
| Graph API利用の有無を確認したか | 内部レポートや自動化が動くか確認する |
| 代替策・リスク受容を記録したか | 監査時に説明できる証跡を残す |
| 変更後の反映時間を考慮したか | 24〜48時間の反映遅延を想定する |
| 月次レビューの場を決めたか | 一度きりで終わらせず継続改善にする |
このチェックリストで特に重要なのは、権限と所有者です。Secure Scoreの画面を見られる人が多すぎると、推奨アクションの状態やメモが統制されにくくなります。逆に、見られる人が少なすぎると、端末管理やアプリ管理の担当者が必要な情報にアクセスできず、改善が進みません。
よくある失敗と回避策
スコア上昇を目的化してしまう
Secure Scoreは便利な指標ですが、点数を上げること自体が目的になると、現場に合わない設定変更が増えます。セキュリティは使いやすさとのバランスが必要で、すべての推奨事項が自社環境に適しているとは限らないとMicrosoftも説明しています。(Microsoft Learn)
回避策は、推奨アクションごとに「リスク低減効果」「業務影響」「実装難易度」「代替策の有無」を評価することです。
反映遅延を設定ミスと誤解する
推奨アクションを実施しても、すぐにスコアが変わらないことがあります。Secure Scoreはリアルタイム更新に加えて日次同期も行い、推奨アクションによっては反映に時間がかかります。(Microsoft Learn)
回避策は、設定変更時刻、対象ユーザー、対象デバイス、確認したログを残し、翌日以降に再確認する運用にすることです。
代替策の証跡を残していない
サードパーティ製品や内部運用で対策済みの場合、Secure Score上で代替の軽減策として扱える場合があります。ただし、Microsoftはその実装の完全性までは把握できないと説明しています。(Microsoft Learn)
回避策は、製品名、ポリシー名、対象範囲、管理画面のスクリーンショット、承認者、見直し日を残すことです。監査やインシデント対応では、「Secure Score上で解決済みにした」だけでは説明として弱くなります。
RBAC移行で見える範囲が変わる
Unified RBACを使うと、Secure Scoreのアクセスを細かく制御できます。一方で、Microsoft Entraグローバルロールも引き続きアクセスに影響します。カスタムロールを作っただけで最小権限化が完了したと考えるのは危険です。
回避策は、Secure Scoreにアクセスできるユーザーを実際に一覧化し、EntraロールとDefender XDR Unified RBACの両方から確認することです。
管理者が次に取るべき行動
Microsoft Secure Scoreを実務で活用するなら、まずはMicrosoft Defenderポータルで現在の総合スコアとカテゴリ別スコアを確認し、ID・デバイス・アプリ・データのどこに弱点があるかを把握してください。次に、推奨アクションを点数順だけでなく、リスク低減効果、業務影響、実装難易度、所有者の観点で並べ替えます。
今回のMicrosoft Defender XDRに関する確認ポイントは、Secure Scoreの総合点ではなく、カテゴリ別の見え方、アクセス権限、推奨アクションの状態管理です。総合点が変わっていなくても、IDとアプリの内訳、Unified RBACの権限、Graph APIを使ったレポート、デバイス例外の扱いは必ず見直しましょう。
最初の一歩としては、次の3つで十分です。
- Microsoft DefenderポータルでSecure Scoreの総合点とカテゴリ別スコアを記録する
- 上位10件の推奨アクションについて、担当者・業務影響・対応方針を決める
- Secure Scoreを閲覧・管理できるユーザーを棚卸しし、最小権限に近づける
この3点を実施すれば、Microsoft Secure Scoreを単なる点数確認ではなく、継続的なセキュリティ改善の管理基盤として使えるようになります。
コメント