はじめに
近年、多くの企業で Zero Trust Architecture（ゼロトラスト）の導入が進んでいます。
「社内ネットワークは安全」という前提が崩れ、クラウド利用・リモートワーク・SaaS の普及により、境界防御モデルは限界を迎えました。
しかし、Zero Trust を導入しようとすると、多くの組織が Active Directory + Kerberos といった従来型の認証基盤で壁にぶつかります。
本記事では、
• Zero Trust の基本原則
• Kerberos を中心とした従来認証モデルの特徴
• なぜ Zero Trust と相性が悪いのか
• 実運用で直面した課題
• どう移行・共存すべきか
を実体験ベースで深掘りして解説します。

Zero Trust とは何か（おさらい）
Zero Trust の基本原則は非常にシンプルです。
Never Trust, Always Verify（決して信頼せず、常に検証する）
従来の境界防御モデル
[ Internet ] ── FW/VPN ── [ 社内ネットワーク（信頼） ]
• 社内に入ったら基本的にフリーパス
• 認証は「最初の一回」だけ
• IP・ネットワーク位置が信頼の軸

Zero Trust モデル
[ User / Device ]
↓
[ Identity 確認 ]
↓
[ Device 状態 / Context ]
↓
[ Policy Evaluation ]
↓
[ Access to App ]
✅ ユーザー
✅ デバイス
✅ コンテキスト（場所・時間・リスク）
✅ アプリ単位
すべてを毎回評価するのが Zero Trust です。

Kerberos 認証の仕組み（簡単に）
Kerberos は Active Directory 環境で使われるチケットベース認証です。
Kerberos の基本フロー

ユーザーがログオン
KDC（DC）から TGT を取得
サービスアクセス時にサービスチケットを取得
チケットを提示してアクセス
Kerberos の前提条件
• クライアントと DC が直接通信できる
• DNS が正しい
• 時刻同期が必須（5分以内）
• 内部ネットワークでの利用前提

なぜ Kerberos は Zero Trust と相性が悪いのか
① ネットワーク信頼前提の設計
Kerberos は基本的に、
• イントラネット内
• 常時 DC に到達可能
• 内部 DNS が正しい
という前提で設計されています。
❌ Zero Trust では
• ネットワークは信頼しない
• 社内・社外という概念がない
• アプリは個別に公開される
👉 前提条件が真逆

② アプリ単位の認証制御が難しい
Kerberos は「ドメインに参加しているか」が重要で、
• ユーザー単位 ✅
• マシン単位 ✅
• アプリ単位 ❌
Zero Trust が求める
• 「このユーザーが」
• 「このデバイスで」
• 「このアプリにだけ」
という細かい制御が苦手です。

③ クラウド・SaaS との相性問題
Kerberos は以下と相性が悪いです。
• SaaS（M365, Salesforce, ServiceNow）
• インターネット経由アクセス
• モバイル端末
• BYOD
結果として：
• Azure AD / Entra ID との二重認証
• NTLM フォールバック
• 複雑なフェデレーション構成
が発生します。

④ 障害・トラブルシュートが難しい
Kerberos 関連の障害は、非常に切り分けが難しいです。
よくある原因：
• 時刻ずれ
• SPN ミス
• DNS レコード不整合
• クロスフォレスト設定
• ネットワーク遮断
Zero Trust 環境では通信経路が増え、問題はさらに複雑化します。

実際の Zero Trust 導入で遭遇した課題
ケース①：内部Webアプリへのアクセス断
• Zero Trust プロキシ経由で公開
• Kerberos 認証を利用
• 結果：401 / 認証ループ発生
原因：
• クライアントが DC に直接接続できない
• KDC との通信が Zero Trust 経路外

ケース②：VPN が消せない問題
Zero Trust を入れても、
• Kerberos
• LDAP
• NTLM
依存のアプリが残り、
👉 VPN の完全廃止ができない
という事例は非常に多いです。

ケース③：セキュリティ例外の増殖
本来 Zero Trust では避けたい、
• IP ホワイトリスト
• サービスアカウント除外
• 検査バイパス
が Kerberos 対応のために増えてしまいます。

Zero Trust 時代に求められる認証モデル
推奨される方向性
項目推奨
認証 SAML / OAuth2 / OpenID Connect
IdP Entra ID, Okta, Ping
認可 Claims / Conditional Access
デバイス証明書 / MDM / posture
アプリ App 単位公開

Kerberos はどうすべきか？
✅ 即座に捨てる必要はない
❌ Zero Trust の中心に置くべきではない
現実的な選択：
• レガシーアプリは Kerberos 継続
• 新規アプリはモダン認証
• 段階的にプロキシ or App Connector 化

移行戦略（おすすめ）
ステップ1：可視化
• Kerberos / NTLM 利用アプリ棚卸し
• ユーザー・通信依存関係整理
ステップ2：外部化
• 認証を IdP に集約
• アプリ側では認証しない
ステップ3：プロトコル変換
• Kerberos ⇨ SAML/OIDC
• Reverse Proxy / ZTNA 活用
ステップ4：Kerberos 依存の縮小
• レガシーアプリ更改
• SaaS 移行

まとめ
• Zero Trust はネットワーク信頼を前提としない
• Kerberos はネットワーク信頼前提で作られている
• 両者は設計思想が根本的に異なる
• 現実的には「段階移行・共存」が最適解
• 認証は Identity First に再設計する必要がある

おわりに
Zero Trust はツール導入ではなく、思想と設計の転換です。
Kerberos 自体が悪いわけではありませんが、
Zero Trust の中核に据えるには限界があるというのが現実です。
これから Zero Trust を検討する方の参考になれば幸いです。