ゼロトラストに完成はない｜侵入ゼロより検知と復旧を測る理由

「ゼロトラストって、結局どの製品を入れたら完了なんだろう」。そう感じていませんか。社内で言葉はよく聞くのに、自分の仕事とどうつながるのかが見えにくい人は多いはずです。

この記事では、ゼロトラストの考え方と、運用・監視の担当が日々の作業で守るべき土台がわかります。結論から言うと、ゼロトラストは完成させるものではなく、検知と復旧の速さを測りながら回し続けるものです。

ゼロトラストとは?「場所で信頼しない」という設計原則

ゼロトラストは、製品の名前ではなく「暗黙に信頼しない」という設計の考え方です。

米国のNIST(国立標準技術研究所)が2020年に出した文書「SP 800-207」では、守りの重点をネットワークの境界から、利用者や資産そのものへ移す考え方として説明されています。社内ネットワークにいるから安全、会社の端末だから安全といった、場所や持ち主だけを理由に信頼を与えない点が前提です。

たとえるなら、オートロックのマンションと、部屋ごとに鍵がある建物の違いです。オートロックだけだと、一度入られたら全部屋を回られてしまいます。ゼロトラストは、部屋に入るたびに「誰が、どの権限で」を確かめる作りに近いものです。

つまりゼロトラストは、一度入れたら終わる装置ではなく、毎回の確認を積み重ねる原則だと押さえておきましょう。

ゼロトラストがきついと言われる本当の理由

きついのはゼロトラストの原則ではなく、「完成」をゴールにした運用のほうだ、という指摘があります。

株式会社クラウドネイティブのブログに2026年8月6日に載った社長の記事は、社員が書いた「ゼロトラストがキツい」という記事への回答として書かれたものです。記事は、ゼロトラストを導入プロジェクトとして扱い「完成した」と宣言すると、名前が変わっただけの境界防御に戻ってしまうと述べています。原則には終わりがないのに、終わりを作ろうとするから無理が出る、という整理です。

一方で、記事は「人間のSOC(監視チーム)が確認のループを回せる」という前提は本当に崩れたと認めています。根拠として挙げているのは、CrowdStrike社の2026年版レポートの数字です。金銭目的の攻撃者が侵入してから別の機器へ広がり始めるまでの時間(ブレイクアウトタイム)は、2025年の平均で29分、最速で27秒でした。人がアラートを見てから重大度を判断し、封じ込めを決めるのでは、間に合わない場面があるということです。

だからこそ、確認の仕組みを機械の速さに近づけつつ、人は「何を守るか」を決める側に回る必要があります。原則は残し、回し方を変えるという考え方です。

ゼロトラストで削れない4つの土台

同じ記事は、予算を配り直すときでも削らないものとして、次の4つを挙げています(記事では「削れない3点」とIDの統制)。

• フィッシング耐性のある認証(パスキーなど、だまされても使い回せないログイン方法)
• egress制御(社内やサーバーから外へ出ていく通信の制限)
• データを書き換えられない形で残すことと、監査ログ
• ID(アカウント)の統制

理由は、これらは復旧では取り返せない領域だからです。記事は「漏えいしたデータは復旧できない」と書いています。

あわせて記事は、自社の答えとして「侵入ゼロ」をKPI(目標の指標)にするのをやめ、検知までの時間と復旧演習の成功率を指標に置くと述べています。侵入されない会社ではなく、侵入されても止まらない、止まっても測れる時間で再起動できる会社を目指す、という考え方です。なお記事は、これを自社の規模とリスクの取り方に合わせた答えだと断っています。

さらに、AIエージェントやサービス用アカウントのような「人ではないID」にも身元を与え、権限を絞り、行動を記録する必要があるとしています。人のアカウントだけを管理していても、土台は半分しか固まりません。

ゼロトラストを運用で効かせる例:緊急用アカウントの点検

運用担当が身近に関われるのは、ルールの「例外」をきちんと管理することです。わかりやすい例が、Microsoft Entra ID(マイクロソフトのID管理サービス)の緊急アクセス用アカウントです。

Qiitaに2026年10月10日に投稿されたMicrosoft セキュリティの実践記事でも、条件付きアクセス(ログインの条件を細かく決める仕組み)などでアクセス制御を強めていく一方で、緊急用アカウントを用意しておくよう勧めています。設定ミスや障害で、ふだんの管理者アカウントでサインインできなくなる事態に備えるためです。

マイクロソフトの公式ドキュメントでは、緊急用アカウントについて次のような点が示されています。

• 少なくとも2つ用意し、オンプレミスと同期・連携しないクラウド専用のアカウントにする
• ふだんの管理者アカウントとは違う、パスキー(FIDO2)や証明書ベース認証などフィッシングに強い方法でログインさせる
• サインインと監査ログをすべて監視し、使われたらアラートが出るようにする
• 少なくとも90日ごとに、アカウントが機能するか確かめる

ここで大事なのは、「使えないと困るが、使われたら必ず気づく」状態を保つことです。例外を作るなら、その例外を見張る仕組みとセットにする。これがゼロトラストを運用に落とすときの基本形です。

筆者の考察:運用1〜3年目がゼロトラストで見るべきところ

1〜3年目の運用担当なら、新しい製品を覚えるより、すでにある環境で「例外」と「記録」を確かめるほうが効くと考えます。

ゼロトラストの議論は経営や設計の話に見えますが、土台が崩れるのは日々の運用の小さなすき間からです。筆者の見立てで、確かめる項目を表にしました。公式の手順ではないので、目安として使ってください。

土台	現場で確かめること
認証	管理者アカウントがSMSやパスワードだけで入れる状態になっていないか
ID統制	退職者や使っていないサービス用アカウントが残っていないか
例外管理	緊急用アカウントのログインに、通知が飛ぶ設定になっているか
記録	監査ログが何日分残り、書き換えられない場所にあるか
復旧	復旧手順を最後に試したのがいつか、答えられるか

答えられない項目があれば、それ自体が先輩に聞くきっかけになります。「ゼロトラストの完成度」を聞かれても答えにくいですが、「この例外を誰が見ているか」なら1年目でも確かめられます。

フィッシングに強い認証の仕組みは、パスキーはなぜ「盗まれても意味がない」のかで詳しく説明しています。復旧を前提にした備えは、ランサムウェアはバックアップも狙うもあわせて読んでみてください。クラウドでどこまでを自分たちが守るのかは、クラウドのデータは誰が守る?で整理しています。

まとめ:ゼロトラストは完成ではなく検知と復旧で測る

• ゼロトラストは製品ではなく、場所や所属だけで信頼しないという設計原則で、完成はない
• 認証・外向き通信・ログ・IDの4つの土台は、復旧では取り返せないので削らない
• 例外(緊急用アカウントなど)は、見張る仕組みと定期的な確認をセットで持つ

まずは担当環境の緊急用アカウントが何個あり、使われたら誰に通知が届くのかを確かめてみましょう。

参考リンク

• SP 800-207 Zero Trust Architecture(NIST)
• 緊急アクセス用管理者アカウントを管理する – Microsoft Entra ID(Microsoft Learn)
• 【アンサー】ゼロトラストはキツくない。「ゼロトラストの完成」を目指す運用がキツい(CloudNative BLOGs) ― 2026年8月6日
• Microsoft セキュリティ、これをやってください!～ 実践ベストプラクティス(Qiita) ― 2026年10月10日
• 2026 CrowdStrike Global Threat Report(CrowdStrike・プレスリリース) ― 2026年2月24日