Secure Score 90点でも事故が起きる理由―「設定は正しいのに、なぜ守れなかったのか」への答え ―
- 山崎行政書士事務所
- 2025年12月28日
- 読了時間: 3分
Microsoft 365 を導入し、Secure Score が 90点を超えている。
それでもアカウント侵害や情報漏えいが起きる──これは珍しい話ではありません。
本記事では、Secure Score が高くても事故が起きる構造的理由を、技術 × 統制 × クラウド法務の観点から解き明かします。
Secure Score は「安全度」ではない
まず最初に、Secure Score の本質を整理します。
Secure Score とは、
Microsoft が提示する推奨設定の達成度
静的な構成評価
「設定されているかどうか」の点数
であり、運用中の判断・承認・例外処理は評価対象外です。
なぜ 90 点でも事故が起きるのか
事故の多くはSecure Score が見ていない場所で起きます。
理由① Secure Score は「判断」を採点しない
Secure Score は、
MFA が有効か
条件付きアクセスがあるか
は見ますが、
誰が OAuth を承認できるか
なぜその例外が許可されたか
は一切見ません。
つまり、
ユーザーが正規画面で OAuth を承認してしまう
この瞬間は満点でも防げないのです。
理由② 例外設定は“見えない負債”になる
実務では必ず発生します。
特定部門だけ CA 除外
一時対応の恒久化
ベンダー要請による緩和
これらはSecure Score 上は減点されないことが多く、
現場では例外が常態化
管理側は把握していない
という 統制の断絶を生みます。
理由③ OAuth と「同意」はスコア外
OAuth はMicrosoft 365 の中核機能ですが、
誰が
どの権限を
どの判断で承認したか
という 責任構造はSecure Score では可視化されません。
その結果、
技術的には「推奨設定」
統制的には「無管理」
という状態が生まれます。
理由④ ログはあっても「証拠」になっていない
Microsoft Entra IDMicrosoft Sentinel
多くの組織でログは存在します。
しかし、
誰が見ているのか
何を異常とするのか
事故後に説明できるのか
が整理されていません。
ログがある ≠ 説明できる
ここに大きな落とし穴があります。
Secure Score が高い組織ほど危ない瞬間
皮肉ですが、Secure Score が高い組織ほど起きやすい事故があります。
「設定はできている」
「Microsoft 推奨は満たしている」
という 安心感が、
承認フローの放置
統制文書の未整備
教育の省略
を招きます。
クラウド法務の視点：本当のリスクはここ
ここで重要になるのが山崎行政書士事務所のクラウド法務の視点です。
山崎行政書士事務所
問題は事故そのものではありません。
なぜその設定だったのか
なぜ承認できたのか
誰が管理責任を持つのか
これを第三者に説明できないことが最大のリスクです。
Secure Score を「事故耐性」に変える方法
① 設定の理由を文書化する
CA の除外理由
OAuth 承認ポリシー
例外の期限と責任者
② 判断ポイントを技術で潰す
User consent の制御
Device Code Flow の制限
承認は Admin のみ
③ ログを「説明用」に設計する
監視目的の明確化
保存期間と閲覧権限
事故時の提出形式
まとめ
Secure Score は 必要条件
しかし 十分条件ではない
本当の安全性は設定 × 統制 × 説明責任で決まる
クラウド時代の事故は、
「なぜそれを許していたのか」
と問われます。
その問いに構成・ログ・ルールで答えられるかそれが本当のセキュリティです。
参照リンク集
Microsoft Secure Score
Microsoft Entra ID
Microsoft Conditional Access
OAuth 2.0 Authorization Framework
Microsoft Sentinel
Microsoft Defender for Cloud Apps
Proofpoint Threat Insight
コメント