「VPN廃止します」で始まったゼロトラスト地獄

3年前、うちの会社がゼロトラストアーキテクチャの導入を決めた時点では、正直「VPNから開放されて最高だな」くらいの認識だった。Web社員証を見せるだけでアクセスできるセキュリティ、みたいな理想的な話が先行してた。

現実はそんなに甘くなかった。

最初の半年は本当に地獄だったんだ。開発環境へのアクセスが遅くなる、デバッグが複雑になる、本番環境での認証エラーが頻発する——。チームからは「前のVPN時代の方がまし」という声も出たし、実装の途中で何度も「これホントに必要か」という議論が起きた。

ただね、3年運用してみたら、ゼロトラストって本来の価値が見えてきたんだ。最初の失敗と工夫を踏まえて、今のうちのチームがどう実装してるか、実践的なところをシェアしたい。

認証と暗号化——VPN時代との最大の違い

従来のVPN時代は「社内ネットワークに繋がったら、あとはアプリケーションレベルのセキュリティに任せよう」みたいな発想だった。そこがゼロトラストの最大の違い。すべてのアクセスに対して「本人確認」「デバイス確認」「リソースへのアクセス権確認」の3段階をやる。

うちが導入したのはこんな構成だ：

graph TD
    A["ローカルマシン<br/>Okta Agent"] -->|SSO・MFA| B["Okta"]
    B -->|デバイス認証| C["BeyondTrust<br/>暗号化トンネル"]
    C -->|IAM検証| D["AWS IAM Roles"]
    D -->|監視・ログ| E["CloudWatch Logs"]

最初は「これ4段階ある？」って思うくらい複雑に見えたけど、実は各レイヤーが独立してるから、どこかが落ちても他が機能する。これが本来のゼロトラストの強さなんだ。

最大の課題は認証遅延だった。Oktaを経由するから、新しいリソースにアクセスする度に2〜3秒の遅延が発生する。開発環境で頻繁にログインし直すので、最初はみんな「遅い遅い」って文句言ってたんだ。

解決策はキャッシュとセッション延長。Okta Agentのローカルキャッシュを12時間に設定して、1日の中では再認証を避けるようにした。MFAのトースト確認もスマホじゃなくYubiKeyに統一して、確認時間を1秒に短縮。細かいことだけど、こういう工夫の積み重ねでユーザー体験は劇的に改善するんだ。

# Okta Agent設定例（実装中）
okta_agent:
  cache_ttl: 43200  # 12時間
  mfa_timeout: 30   # 30秒
  hardkey: true     # YubiKey必須
  offline_mode: true  # ネット切れても1時間は動作

暗号化の側面では、BeyondTrustはトラフィック全体をAES-256で暗号化してるので、オンプレミスのDBアクセスも、AWSのプライベートリソースアクセスも、全部暗号化された状態で通る。正直ここは本当に安心できる部分だ。

デバイス信頼スコア——「どのマシンからアクセスしてるのか」の自動判定

ゼロトラストの「信頼できるのは何か」という問いに対して、最初は「ユーザーの身分確認」だけで考えてた。でもそれだけだと不十分なんだ。

悪意のあるアクターが従業員のログイン情報を盗むというシナリオは今は珍しくない。だからゼロトラストは「ユーザー+デバイス+ネットワーク環境」の3つを同時に見る必要がある。

うちが実装したのはデバイス信頼スコア。Okta Adaptive ThreatやBeyondTrustのデバイスプロフィール機能で、こんな項目をスコアリングしてる：

項目	重み	判定内容
OS更新状況	30%	30日以内が必須
MDM登録状況	25%	IntuneまたはJamfで管理中
ファイアウォール有効	20%	OS標準FW有効
ウイルス対策ソフト	15%	定義ファイル24時間以内
VPN接続	10%	BeyondTrust接続中

スコアが80点以上なら通常アクセス、60〜80点なら追加認証（YubiKey確認）、60点未満は絶対に本番DBへのアクセス禁止。スコアが低いときはどうするのかって感じだけど、本番環境は一切触らせない厳格なルールにしてる。

この仕組みで気づいたのが、自分たちで気づかなかったセキュリティ穴を発見するというメリットだ。ある日、営業さんのノートPCがスコア50点のまま1ヶ月運用されてることに気づいた。話を聞いたら、Windows Updateを当ててなかったんだ。

従来のセキュリティ対策なら「定期的にセキュリティ研修をしましょう」とか「ポリシー違反だから即座に改善」みたいな上からの指示になるんだけど、ゼロトラストは違う。自動的に制限が入るから、本人も気づきやすいんだ。うちのチームは「スコアが上がるまで本番へのアクセス一時停止」というルールを明確にしたら、それ以降は自分たちで環境を保つようになった。

監視とログ——「誰が何を見てるのか」を逐一記録

ゼロトラストで最も重い課題がログの量だ。従来のVPN時代は「VPN接続」と「VPN切断」の2つのイベントだけだった。それがゼロトラストになると、すべてのアクセス試行、認証の成功/失敗、デバイス信頼スコアの変化、リソースアクセスの開始/終了——全部ログに入るんだ。

うちの現在のログ量を見てみると：

xychart-beta
    title ゼロトラスト運用中のログ量（日単位）
    x-axis [認証ログ, 接続ログ, AWS CloudTrail, セキュリティイベント]
    y-axis "件数" 0 --> 3500000
    line [300, 150, 50, 20]

合計すると520万件/日になる。これを全部CloudWatch Logsに放り込んでたら、月額費用が80万円超になった。失敗だ。

今の対策はこうやってる：

1. ホット/ウォームストレージの分離

• CloudWatch Logs：1週間分（最近のアクセスだけ）
• S3 Glacier Deep Archive：1年分（監査用）
• ローカルバッファ：24時間分（Elasticsearch）

2. フィルタリング

• 成功ログ（スコア80点以上）：50%削減
• 自動スケーリング時のアクセス：ノイズ除外
• ヘルスチェック系リクエスト：集約ログ化

3. 異常検知の自動化

• Splunkで機械学習ベースの異常検知
• 通常と違うアクセスパターン（深夜の大量ダウンロード等）は即アラート
• False Positiveを減らすため、チーム別のベースラインを学習

# 異常検知の簡易版（Splunk SPL的な概念）
index=zero_trust sourcetype=auth 
| stats count as access_count by user, resource, hour 
| where access_count > (average * 3)  # 平均の3倍以上
| alert

ここが地味だけど本当に重要な部分。セキュリティを強化しても、異常を検知できなければ意味がない。うちは1年間、Splunkの機械学習モデルを学習させて、今はFalse Positiveが週1〜2件程度に落ち着いてる。

ログ設計ってのはインシデント対応の速度を大きく左右する。ゼロトラストでは「何が起きたのか」を数秒で判断できることが求められるんだ。

段階的な移行戦略——全部を一度にはやるな

ここが3年の経験で最も学んだことだ。

ゼロトラスト「導入します」って言って、1ヶ月で全部切り替えるのは絶対にやめた方がいい。実際、うちが失敗したパターンがこれなんだ：

失敗版（初年度前半）

0日目：VPN廃止、ゼロトラスト一括導入
      ↓ 本番DB接続失敗、復旧に4時間
      ↓ 営業チームがVPN復活を強く要求
      ↓ 設定ミスで開発チームがロックアウト
      ↓ 大炎上

成功版（今のやり方）

フェーズ1（1-2ヶ月）：開発環境のみゼロトラスト化。VPNは併行動作。問題をカジュアルに見つける段階。

フェーズ2（3-5ヶ月）：ステージング環境をゼロトラスト化。デバイス信頼スコアの正確な基準を決定。チームのフィードバックを大量に吸収する。

フェーズ3（6-8ヶ月）：本番環境への段階的な移行。まず読み取り専用リソースから。本番DBは最後に。

フェーズ4（9-12ヶ月）：VPN完全廃止。ゼロトラスト monitoring を最適化。チーム研修と運用ルール固定化。

この遅さが実は重要なんだ。最初は「なぜこんな遅いのか」って思ったけど、結果として：

• セキュリティインシデント：ゼロ件（フェーズ3で1件の不正アクセス試行を検知・即座に対応）
• ユーザー満足度：85%（最初は40%だった）
• 運用コスト：月120万円（うち監視/ログ80万、ツール40万）

これって段階的だからこそ実現できたと思う。焦って全部入れたら、インシデントも増えてたはずだ。

マルチクラウド時代のゼロトラスト

うちはAWSとGCP両方を使ってるんだけど、ゼロトラストってクラウド依存性が低いのが地味な強さだ。

graph TB
    User["ユーザー<br/>Okta認証"]
    
    subgraph AWS["AWS"]
        IAM["IAM Roles"]
        EC2["EC2/RDS/S3"]
        IAM --> EC2
    end
    
    subgraph GCP["GCP"]
        IAP["Identity-Aware Proxy"]
        GCP_RES["Compute Engine"]
        IAP --> GCP_RES
    end
    
    subgraph OnPrem["オンプレミス"]
        DB["Private DB"]
    end
    
    BT["BeyondTrust<br/>統一トンネル"]
    
    User --> BT
    BT --> IAM
    BT --> IAP
    BT --> DB

これが理想的なマルチクラウド戦略だけど、ゼロトラストはマルチクラウド運用を強制的に統一する効果がある。各クラウドが独自のセキュリティを持つんじゃなくて、すべて同じ認証・暗号化・監視の仕組みを通すから、結果として一貫性が出るんだ。

正直まだ悩んでる部分

3年運用してても、完璧ではないんだ。

パフォーマンス vs セキュリティのバランス

認証が強いほど遅くなる。特にデータサイエンティストチームが機械学習パイプラインで「数千のGPUインスタンスへの並行アクセス」をやるとき、ゼロトラストの認証がボトルネックになるんだ。今は「バッチジョブはサービスアカウント認証」「人的アクセスはMFA必須」で分け方を工夫してるけど、根本的な解決ではない。

デバイス信頼スコアの過信

Malwareがユーザーの意思に関わらず動く場合、デバイス信頼スコアはあんまり役に立たない。この課題には「振る舞い検知」（Behavior-based detection）が必要だけど、これはまだ準備中だ。

組織の成長とポリシー変更

チームが増えると、「誰がどのリソースにアクセスしていいのか」の定義が複雑になる。今は手作業で権限を管理してるけど、100人超えたら破綻するはず。IDP（Identity Provider）のRole-Based Access Control（RBAC）を整備する予定だ。

2026年のゼロトラストのトレンド

最近見えてる動きを整理してみたんだ：

AIベース的な異常検知が一般的に

OpenAI APIを使った異常検知サービスが増えてる。自組織のデータで微調整すれば精度が一気に上がるんだ。

Hardware Security Moduleの活用拡大

YubiKeyみたいな物理キーが本当に普及してきた。個人的には「パスキー」がVPN時代を完全に終わらせる可能性もあると思ってる。

ソフトウェアサプライチェーンセキュリティとの統合

SBOM（Software Bill of Materials）との連携が増えてる。「このコンテナイメージから脆弱性があります」→「そのイメージをビルドした開発者のデバイスは信頼できますか」という判定が自動化される感じだ。

うちも最後の「サプライチェーン検証」には本気で取り組まなきゃいけない。結局、ゼロトラストって「信頼の仕組み全体」の構築なんだから。

まとめ

ゼロトラストアーキテクチャは「銀の弾」じゃない。むしろ、セキュリティの複雑さをユーザーに感じさせるトレードオフがある。だけど3年運用してわかったのは、このトレードオフが組織全体のセキュリティ文化を変えるということなんだ。

重要なポイント：

段階的な移行が絶対——全部を一度には切り替えない。開発→ステージング→本番の順序で進めることが、結果として最速のゴール到達になる。

認証・暗号化・監視の3本柱——どれか1つが弱いと全体が崩れる。OktaやBeyondTrustみたいなツール選定で8割は決まる。

ログとモニタリングにコスト——セキュリティを強化しても、異常検知ができなければ意味がない。ここに月100万円超は見積もっておくべき。

デバイス信頼スコアは「自動化ガバナンス」の入口——定期的なWindows Update、MDM管理なども自動的に強制される。地味だけど、これが実は組織全体の技術負債を減らすんだ。

マルチクラウドとの相性が良い——各クラウドの独自セキュリティに頼るんじゃなくて、統一された仕組みで管理できる。

うちはまだ「完璧なゼロトラスト」には程遠いけど、少なくともVPN時代よりは「本当に必要な権限だけを、その時点で検証する」という哲学が定着した。それがセキュリティ侵害を数件検知・対応できた実績にもなってる。

もし今ゼロトラスト導入を検討してるなら、焦らず、小さく始めることを強くお勧めする。3年は覚悟した方がいい。