エンタープライズ アプリケーション向けのゼロトラスト アーキテクチャ

境界線は死んでいる。従業員がコーヒー ショップで働き、企業データが 3 つの異なるクラウド プロバイダーに存在し、サプライ チェーン パートナーがネットワークに VPN アクセスできる世界では、ファイアウォール内にあるものはすべて信頼できるという考えは、危険なほど時代遅れです。ゼロトラスト アーキテクチャは、この前提を、決して信頼せず、常に検証するというシンプルで妥協のない原則に置き換えます。

Forrester Research は 2010 年に「ゼロ トラスト」という用語を作りましたが、企業が実際の導入に向かうまでに、パンデミックによるリモート ワークの急増と、SolarWinds のサプライ チェーンへの壊滅的な攻撃が必要でした。 Gartner の報告によると、2025 年までに組織の 60% が何らかの形式のゼロトラストを採用しましたが、すべてのワークロードにわたって包括的な実装を達成した組織は 10% 未満でした。

重要なポイント

• ゼロトラストは、送信元ネットワークや事前の認証に関係なく、すべてのアクセス要求を検証することで暗黙的な信頼を排除します。
• マイクロセグメンテーションにより、フラット ネットワーク アーキテクチャと比較して横方向の移動リスクが 85% 削減されます。
• ID 認識プロキシは、エンタープライズ アプリケーションの主要なリモート アクセス メカニズムとして VPN に代わるものです
• 18 ～ 24 か月にわたる段階的な実装ロードマップにより、各段階で目に見えるセキュリティの改善が実現します

---

ゼロトラスト原則

ゼロトラストは購入する製品ではありません。これは、企業全体のあらゆる設計上の決定を導く 5 つの基本原則に基づいて構築されたアーキテクチャ哲学です。

ゼロトラストの 5 つの柱

決して信頼せず、常に検証してください。 すべてのアクセス要求は、発信元に関係なく認証され、承認される必要があります。企業オフィスからのリクエストは、公衆 WiFi ネットワークからのリクエストと同様に精査されて処理されます。以前の認証は将来のアクセスを保証しません。

侵害を想定します。 攻撃者がすでにネットワーク内にいるかのようにシステムを設計します。この前提により、セグメンテーション、監視、および最小権限の決定が推進されます。セグメントが侵害された場合は、爆発範囲を制限する必要があります。

明示的に検証します。 認証と認可の決定では、ユーザー ID、デバイスの健全性、場所、時刻、リソースの感度、行動分析など、利用可能なすべてのシグナルが使用されます。単一の要素 (有効なセッション トークンなど) だけでは決して十分ではありません。

最小特権アクセス ユーザー、アプリケーション、およびサービスは、その機能を実行するために必要な最小限のアクセス権を受け取ります。アクセスのスコープは、リソース、アクション、および時間によって決まります。永続的な特権は廃止され、ジャストインタイムのアクセス許可が優先されます。

継続的な検証。 認証はログイン時に 1 回限りのイベントではありません。セッションは継続的に評価され、リスク信号が変化した場合（デバイスの姿勢の低下、不可能な移動の検出、異常な動作の観察）、アクセスはリアルタイムで取り消されます。

従来のセキュリティとゼロトラスト

従来の境界セキュリティとゼロトラストの根本的な対比は次のとおりです。

---

マイクロセグメンテーション

マイクロセグメンテーションは、ゼロトラストのネットワーク実装です。マイクロセグメンテーションは、任意のシステムが他のシステムと通信できるフラット ネットワークの代わりに、明示的な通信ポリシーを強制する分離ゾーンを作成します。

マイクロセグメンテーションの仕組み

従来のネットワーク セグメンテーションでは、ネットワークをいくつかの大きなゾーン (DMZ、本番、開発、管理) に分割します。マイクロセグメンテーションでは、個々のワークロードやアプリケーション層と同じくらい粒度の高いセグメントを作成することで、これをさらに進めます。

例: マイクロセグメンテーションを使用しない ERP 導入

侵害された Web サーバーは、同じ VLAN 上のデータベース サーバー、ファイル サーバー、プリント サーバー、およびその他すべてのシステムに到達する可能性があります。攻撃者が顧客ポータルの XSS 脆弱性を悪用すると、財務記録を含むデータベースにアクセスする可能性があります。

例: マイクロセグメンテーションを使用した同じ ERP 導入

Web サーバーは、ポート 8069 でのみアプリケーション サーバーと通信できます。アプリケーション サーバーは、ポート 5432 でのみデータベース サーバーと通信できます。データベース サーバーは、アウトバウンド接続を開始できません。侵害された Web サーバーには、データベースへのパスも他のアプリケーション層へのパスもありません。

実装アプローチ

ビジネス プラットフォームのマイクロセグメンテーション

Odoo ERP、Shopify コネクタ、AI を活用したサービスを実行している組織の場合、マイクロセグメンテーションにより次の分離境界を作成する必要があります。

• ERP アプリケーション層 --- 他のすべてのワークロードから分離され、ID 認識プロキシ経由でのみアクセス可能
• データベース層 --- 特定のポート上の ERP アプリケーション層からのみアクセス可能
• 統合層 --- ERP 層とデータベース層の両方から分離されたマーケットプレイス コネクタと API ゲートウェイ
• AI/ML ワークロード --- モデル API 呼び出しの特定の出力ルールで分離
• 開発/ステージング --- 本番環境から完全に分離されており、その間にネットワーク パスはありません

---

ID 認識プロキシ

ID 認識プロキシ (IAP) は、ゼロトラスト アーキテクチャのアクセス ゲートウェイです。これらは、宛先アプリケーションに転送する前にすべてのリクエストを認証および承認することで、従来の VPN を置き換えます。

ID 認識プロキシの仕組み

ユーザーがエンタープライズ アプリケーションにアクセスしようとすると、次のようになります。

1. リクエストはアプリケーションに直接送信されるのではなく、アイデンティティ認識プロキシに送信されます。
2. プロキシは有効なセッションを確認し、セッションが存在しない場合は ID プロバイダーにリダイレクトします。
3. ID プロバイダーはユーザー (パスワード + MFA) を認証し、ID クレームを返します。
4. プロキシは、ID クレーム、デバイスの状態、およびコンテキストに対して認可ポリシーを評価します。
5. 許可されている場合、プロキシはリクエストをアプリケーションに転送します。そうでない場合、リクエストは拒否されます

アプリケーション自体には公開エンドポイントがありません。プロキシ経由でのみ到達可能です。これにより、アプリケーションへの直接アクセスに依存する攻撃のカテゴリー全体が排除されます。

ID 認識プロキシ ソリューション

• Google BeyondCorp Enterprise (IAP) --- Google Cloud と統合され、あらゆる Web アプリケーションをサポート
• Cloudflare Access --- あらゆるインフラストラクチャで動作し、優れたグローバル パフォーマンスを実現
• Azure AD アプリケーション プロキシ --- Microsoft エコシステムの緊密な統合
• Pomerium --- オープンソース、セルフホスト、プロトコルに依存しない
• Authentik --- アプリケーション プロキシが組み込まれたオープンソースのアイデンティティ プロバイダー (ECOSIRE プラットフォームで使用)

IAP と VPN

VPN はネットワーク レベルのアクセスを許可します。接続すると、ユーザー (または VPN 資格情報を盗んだ攻撃者) は、ネットワーク上のすべてのシステムにアクセスできます。 ID 認識プロキシは、アプリケーション レベルのアクセスを許可します。各アプリケーションには独自の認可ポリシーがあり、ネットワーク アクセスは決して許可されません。

API セキュリティ の場合、IAP はデバイスの状態とコンテキスト信号を承認の決定に追加することで OAuth2/OIDC を補完します。

---

デバイスの姿勢チェック

ゼロトラストは、ユーザーを超えてデバイスまで検証を拡張します。侵害されたデバイス上の有効なユーザー資格情報は依然としてセキュリティ リスクです。デバイスの状態チェックでは、アクセスを許可する前にエンドポイントの健全性とコンプライアンスを評価します。

デバイスの状態チェックで評価される内容

• オペレーティング システムのバージョン --- OS には許容可能な最小バージョンにパッチが適用されていますか?
• ディスク暗号化 --- デバイスのストレージは暗号化されていますか (BitLocker、FileVault、LUKS)。
• ファイアウォールのステータス --- ホストのファイアウォールは有効になっており、適切に構成されていますか?
• EDR/ウイルス対策ステータス --- エンドポイント検出および応答ソフトウェアは現在のシグネチャで実行されていますか?
• 画面ロック --- 自動画面ロックは許容可能なタイムアウトで構成されていますか?
• ジェイルブレイク/ルート検出 --- デバイスのセキュリティ モデルは侵害されていますか?
• 証明書の存在 --- デバイスには有効なエンタープライズ証明書がありますか?

継続的なデバイス評価

認証時の初期姿勢チェックは必要ですが、それだけでは十分ではありません。デバイスの状態はセッション中に変化する可能性があります。ユーザーがファイアウォールを無効にしたり、EDR エージェントがクラッシュしたり、デバイスの OS バージョンの新しい脆弱性が明らかになったりする可能性があります。

継続的なデバイス評価では、一定の間隔 (通常は 5 ～ 15 分ごと) で姿勢を再評価し、デバイスがコンプライアンスから外れると、リアルタイムでアクセスを取り消すことができます。これは、継続的検証のゼロトラスト原則と一致しています。

---

実装ロードマップ

企業全体にゼロトラストを導入するには、複数のフェーズが必要です。すべてを同時に実装しようとすると、プロジェクトの失敗、ユーザーの不満、移行中のセキュリティ上のギャップが生じます。次のロードマップは、18 ～ 24 か月間の体系的な進行を示しています。

フェーズ 1: 基礎 (1 ～ 3 か月目)

目的: ID インフラストラクチャと可視性を確立します。

• ID プロバイダー (Authentik、Okta、Azure AD) のデプロイまたは統合
• すべてのアプリケーションにわたってすべてのユーザーに MFA を適用します (Odoo の IAM ベスト プラクティス を参照)
• すべてのアプリケーション、データ ストア、ネットワーク フローのインベントリを作成する
• ネットワーク監視を展開してベースライン トラフィック パターンを確立する
• 初期の [セキュリティ ポリシーとガバナンス フレームワーク] を定義する(/blog/cybersecurity-business-platforms-erp-ecommerce)

フェーズ 2: アクセスの最新化 (4 ～ 8 か月目)

目的: 境界ベースのアクセスを ID 認識型のアクセスに置き換えます。

• 最も優先度の高いアプリケーション (ERP、金融システム) に ID 認識プロキシを導入する
• 管理対象デバイスのデバイス状態チェックを実装する
• データベース層から始まる本番ワークロードのマイクロセグメンテーションを開始します
• リモート ワーカー向けに VPN からアプリケーションごとのアクセスに移行する
• 管理者アカウントの特権アクセス管理 (PAM) を実装する

フェーズ 3: セグメンテーションとモニタリング (9 ～ 14 か月目)

目的: 包括的なマイクロセグメンテーションと行動監視を実現します。

• すべての実稼働ワークロードにわたる完全なマイクロセグメンテーション
• 異常検出のために UEBA (ユーザーおよびエンティティの行動分析) を導入する
• 特権操作のためのジャストインタイム (JIT) アクセスの実装
• デバイスの状態チェックを管理対象外/BYOD デバイスに拡張
• [クラウドセキュリティ体制管理]の統合(/blog/cloud-security-posture-aws-azure-gcp)

フェーズ 4: 継続的検証 (15 ～ 18 か月目)

目的: 継続的でコンテキストを認識したアクセス決定を実現します。

• リアルタイムのリスクスコアリングによる継続的認証の実装
• 高リスク信号に対する自動応答ハンドブックを導入する
• ゼロトラストを API 間通信に拡張 (相互 TLS、サービス メッシュ)
• データレベルのアクセス制御の実装 (フィールドレベルの暗号化、動的マスキング)
• レッドチーム演習を実施してゼロトラスト制御を検証する

フェーズ 5: 最適化 (19 ～ 24 か月目)

目的: 改良、自動化、測定します。

• 行動ベースラインに基づく AI 主導の適応型アクセス ポリシー
• 自動化されたコンプライアンス証拠の収集とレポート
• インシデントデータとレッドチームの調査結果に基づく継続的な改善
• ゼロトラスト原則を [サードパーティおよびベンダーのアクセス] に拡張します(/blog/third-party-risk-vendor-security)
• エグゼクティブレポート用にゼロトラスト成熟度スコアカードを公開

---

よくあるゼロトラストの落とし穴

ゼロトラストを製品購入として扱う 単一のベンダーが完全なゼロトラストを提供することはありません。これは、連携して動作する多くのコントロールで構成されるアーキテクチャです。

ユーザー エクスペリエンスの無視。 過剰な認証プロンプトとアクセスの摩擦により、ユーザーはセキュリティを損なう回避策を見つける必要があります。スマートなリスクベースの認証により、セキュリティと使いやすさのバランスが取れます。

レガシー アプリケーションの無視。 ビジネス クリティカルなアプリケーションの多くは、最新の認証をネイティブにサポートできません。レガシー システムのリバース プロキシ、認証ゲートウェイ、および資格情報の保管を計画します。

ネットワーク可視化フェーズをスキップします。 既存のトラフィック パターンを理解せずにマイクロセグメンテーションを行うと、アプリケーションが破損します。セグメンテーション ポリシーを適用する前に、徹底的なトラフィック マッピングに投資してください。

東西 API トラフィックのことは忘れてください。 ユーザー アクセスに対するゼロトラストは、戦いの半分に過ぎません。プラットフォーム内のサービス間通信も、相互 TLS、サービス トークン、またはサービス メッシュ ポリシーを使用して認証および許可される必要があります。

---

よくある質問

ゼロトラスト アーキテクチャの実装にはどれくらいの時間がかかりますか?

中規模企業の場合、包括的なゼロトラストの実装には通常 18 ～ 24 か月かかります。ただし、段階的なアプローチにより、各段階でセキュリティが向上します。 MFA の強制 (フェーズ 1) は数週間で完了し、資格情報攻撃の 99.9% を即座にブロックします。重要なのは、高価値、高リスクの資産から始めて、段階的に拡大することです。

ゼロトラストはファイアウォールや VPN に代わるものですか?

ゼロトラストはファイアウォールを排除するものではありませんが、その役割は変わります。ファイアウォールは、ネットワーク境界における広範なトラフィックのフィルタリングには依然として役立ちますが、もはや主要なアクセス制御メカニズムではありません。 VPN は、アプリケーション アクセス用の ID 認識プロキシに置き換えられます。一部の組織では、最新の認証をサポートできないレガシー アプリケーションのために VPN を一時的に維持しています。

ゼロトラストは中小企業にとって現実的ですか?

絶対に。クラウドベースの ID プロバイダー (Authentik、Google Workspace、Microsoft 365) とマネージド セキュリティ サービスにより、あらゆる規模の組織がゼロトラストにアクセスできるようになります。 SMB は、あらゆる場所での MFA、重要なアプリケーションの ID 認識プロキシ、アプリケーション層間の基本的なマイクロセグメンテーションという 3 つの制御に焦点を当てることで、ゼロ トラストの大きな利点を実現できます。

ゼロトラストはアプリケーションのパフォーマンスにどのような影響を与えますか?

ID 認識プロキシでは、認証および認可チェックのリクエストごとに 1 ～ 5 ミリ秒の遅延が追加されます。ほとんどのビジネス アプリケーションでは、これは感知できません。マイクロセグメンテーションは、ハイパーバイザーまたはクラウド プロバイダー レベルで実装された場合、パフォーマンスへの影響はほぼゼロです。セキュリティ上のメリットに比べれば、パフォーマンスのコストは無視できます。

---

次は何ですか

ゼロトラスト アーキテクチャは、現代の企業にとってオプションではありません。分散した労働力、クラウド ネイティブ アプリケーション、洗練された攻撃者という今日の現実に適合するセキュリティ アーキテクチャです。 ID の統合と MFA から始めて、ID を認識したアクセスとマイクロセグメンテーションを経て、継続的な検証に向けて構築します。

ECOSIRE は、あらゆるプラットフォーム展開にわたってゼロトラスト原則を実装します。当社の OpenClaw AI セキュリティ強化 には、アイデンティティを認識したアクセス制御とマイクロセグメンテーションが含まれており、一方、当社の Odoo ERP 実装 には、基礎からロールベースのアクセスと SSO 統合が構築されています。 お問い合わせ して、ゼロトラストへの取り組みについてご相談ください。

---

ECOSIRE によって発行 --- Odoo ERP、Shopify eCommerce、OpenClaw AI にわたる AI を活用したソリューションで企業のスケールアップを支援します。