ゼロトラスト

何が問題だったのか：境界防御の限界

従来のセキュリティは「境界防御（ペリメータモデル）」でした。社内ネットワークを城壁とお堀で囲み、ファイアウォールや VPN という“関所”を1か所だけ置く。関所を通って中に入れた相手は信頼する、という考え方です。

この前提は、今のシステムでは成り立ちません。

• 一度突破されると横移動し放題：攻撃者は1台の PC をフィッシングで乗っ取り、関所を正規に通過してしまえば、あとは「信頼された内部」として社内のサーバを次々に渡り歩けます（これをラテラルムーブメント／横移動と呼びます）。お堀の内側はノーチェックだからです。
• そもそも“内と外”の境目が消えた：クラウド（SaaS / IaaS）、リモートワーク、私物端末（BYOD）が当たり前になり、データもユーザーも社外にいる。守るべき城壁の“外側”に本体が出てしまった。
• 内部犯行・認証情報の盗難：脅威は外からだけではありません。盗まれた正規アカウントや内部の悪意は、境界の内側から始まります。

境界防御とゼロトラストの違い

同じ「守る」でも、信頼の置き方が正反対です。

ゼロトラストの3原則

NIST SP 800-207 をはじめ、各社の定義に共通する核は次の3つです。これがゼロトラストの“背骨”です。

• ① 明示的に検証する（Verify explicitly）：すべてのアクセスを、入手できる情報を総動員して認証・認可する。ユーザー ID とパスワードだけでなく、多要素認証（MFA）／端末の状態／場所／時刻／普段と違う挙動かまで見て判断する。「いつもの社内 IP だから OK」のような暗黙の信頼を排除します。
• ② 最小権限（Least privilege）：与える権限は必要最小限・必要な時だけ。管理者権限を常時持たせず、必要なときだけ昇格させる（最小権限の原則そのもの）。万一アカウントが乗っ取られても、できることが小さければ被害も小さい。
• ③ 侵害を前提にする（Assume breach）：「いつか必ず破られる」前提で設計する。ネットワークを細かく区切り（マイクロセグメンテーション）、横移動を止め、すべてのアクセスを記録・監視して異常を素早く検知する。

どう適用するか：ID・端末・認可・通信

抽象論で終わらせないために、実装の柱を4つに分けて見ます。守る対象が「人のアクセス」なのか「サービス間通信」なのかで、効く道具が変わります。

1. アイデンティティ（誰か）を強くする

すべての起点は「本人確認」です。パスワードだけは脆いので MFA を必須にし、可能ならパスワード保存の弱点ごと避けられるパスキー（FIDO2 / WebAuthn）やフィッシング耐性のある方式へ寄せる。さらに SSO + IdP（ID プロバイダ）に認証を集約し、「誰が・いつ・何にアクセスしたか」を一元的に検証・記録できるようにします。

2. 端末（どの端末か）の状態を見る

正しいユーザーでも、マルウェア感染した端末からなら危険です。そこで「OS が最新か」「ディスク暗号化されているか」「EDR / ウイルス対策が動いているか」といった**端末の健全性（デバイスポスチャ）**をアクセス条件に組み込みます。条件を満たさない端末は、たとえ本人でもブロックや限定アクセスに落とす。

3. アクセスごとに認可する（継続認証）

ゼロトラストの肝は、1回ログインしたら終わりにしないことです。ポリシーエンジンがリクエストごとに「ユーザー × 端末 × リソースの機密度 × 文脈（時刻・場所・挙動）」を評価し、その都度 許可／拒否／追加認証（MFA を再要求） を決めます。これを継続認証（Continuous Authentication）／適応型アクセスと呼びます。

# 「いつもの場所・健全な端末」なら通すが、文脈が崩れたら止める／追加認証する
リクエスト: ユーザー=u123 / 端末=会社支給ノート(EDR稼働) / リソース=給与DB / 場所=社内
  → 評価: 端末OK・本人MFA済み・普段どおり          → 許可

リクエスト: ユーザー=u123 / 端末=私物スマホ(状態不明) / リソース=給与DB / 場所=海外IP
  → 評価: 端末ポスチャ不明・地理が異常・機密度=高     → 追加MFAを要求 or 拒否

ここで認証（Authentication：誰か）と認可（Authorization：何をしてよいか）を分けて考えるのが大切です。本人だと確認できても、そのリソースにその操作をしてよいかは別問題（→ 認証と認可）。ゼロトラストは両方を、アクセスのたびに突き合わせます。

4. サービス間は mTLS で相互に身元を示す

人の話だけではありません。マイクロサービスやサーバ同士の通信も「同じ社内ネットワークだから信頼」をやめます。ここで使うのが mTLS（相互 TLS）。

通常の TLS はサーバだけが証明書で身元を証明し、クライアントは名乗りません（だから誰でも接続を試せる）。mTLS はクライアント側も証明書を提示し、両者がお互いの正体を暗号的に検証します。これにより「正規の証明書を持つサービスだけが通信できる」状態を作り、なりすましたプロセスの侵入を防ぎます。

実務では、各サービスにサイドカープロキシを挟むサービスメッシュ（Istio / Linkerd 等）が、この mTLS をアプリ側のコードを変えずに自動付与してくれることが多いです。詳しい仕組みは mTLS の方式ページ を参照。

やりがちな落とし穴

考え方は綺麗でも、運用で形骸化しやすいポイントがあります。

まとめ

ゼロトラストは新しい魔法の製品ではなく、「場所で信頼しない／最小権限で渡す／侵害を前提に封じ込める」という設計の構えです。城壁で囲って中を信じる代わりに、アクセスのたびに本人・端末・権限・文脈を検証し続ける。人のアクセスは MFA と継続認証で、サービス間は mTLS で――どちらも「Never trust, always verify」の一点に貫かれています。

関連として、攻撃が始まる起点になりやすい盗まれた認証情報やセッションは Web 認証 と地続きで、ゼロトラストが繰り返し参照する“与えすぎない”発想は 最小権限の原則 そのものです。