仕組み

構成要素は4つ、規則は1つ —— 許可ルールに一致した通信だけがトンネルされます。それ以外は、1バイトも複写せずに閉じられます。

構成要素	動く場所	役割
Agent	端末（macOS / Windows）	OS のネットワーク層で通信を捕捉して Edge へステアし、フロー単位の許可・拒否をローカルでも強制する
Edge	あなたのインフラ	すべての通信をポリシーで判定し、許可したものを転送し、設定された箇所では復号・検査し、復号したものを張り直し、判定を監査に残す
Control Plane	Edge の隣	Admin API、ポリシーエンジン、識別情報と NHI の登録、監査、OIDC —— 設定・受け入れ・失効を書く場所
Connector	あなたの私設ネットワークの中	Edge と社内アプリの間をつなぐアウトバウンド専用の橋。そして、そのアプリへの唯一の入口

1つのリクエストに何が起きるか

通信が到着  →  Edge が識別情報・端末・ポスチャ・ポリシーを評価

  許可ルールに一致  →  Connector へトンネル  →  ローカルで接続  →  応答
  何にも一致しない  →  閉じる。1バイトも複写しない

  いずれの場合も    →  判定を監査に記録

よく聞かれる2点なので、はっきり書いておきます。

デフォルト拒否はモードではなく、既定です。 「ルールが無いこと」が「許可」を意味する設定は存在しません。
社内アプリがインバウンドで露出することはありません。 Connector は Edge に対して外向きに接続します。内向きに接続してくるものはありません。アプリにはインターネットに面した listener がそもそも無く、攻撃対象になりません。

自分で運用するものは、本当に ZTNA なのか

はっきり答える価値のある問いです。「ZTNA」は「大手ベンダのクラウド」の同義語として使われることが多く、その用法だと事業者が自分で運用するものは定義上すべて失格になります —— そしてその語は、セキュリティの性質ではなく事業モデルの説明になってしまいます。

ZTNA は信頼のモデルです。トポロジではなく、ベンダでもありません。 ネットワーク上の位置で信頼しない。すべてのアクセスを、識別情報・端末・ポスチャ・ポリシーに照らして検証する。デフォルト拒否。1つの制御点で強制する。配備がその性質を判定の経路に持っているか、持っていないか、それだけです —— そしてここでは、誰がホストしているかから推測するのではなく、その判定の経路を読むことができます。

規模と地理は、それとは別の問いで、こちらにも実際の答えがあります。マルチリージョンは可用性とデータ所在を実現し、このリリースに含まれます。ただしそれがゼロトラストを成立させているわけではありません —— 単一ノードでもその性質は成立し、これらの検証を欠いた世界規模のクラウドでは成立しません。

Agent が端末上になければならない理由

Agent は macOS の Network Extension、あるいは Windows の WFP エージェントと自社製 callout ドライバとして動き、OS のネットワーク層で通信を捕捉します —— 誰かが設定し忘れうるプロキシ設定ではありません。mTLS のデバイス識別情報を持つので、Edge が受け入れるのは資格情報ではなく端末です。ポスチャ、リスク状態、失効は継続的で、端末は動作中に受け入れ・降格・遮断され得ます。

同一 LAN の仲介が可能なのも、これがあるからです。クラウドだけのサービスは、隣り合って置かれた 2台の間の通信を原理的に見ることができません。

どこを復号し、どこを意図的に復号しないか

傍受は限定的で、全面ではありません。「すべて復号します」は、この製品の説明として不正確であるだけでなく、SSE を運用した経験のある相手には危険信号として読まれます。

復号する	バイパスする
自社の社内アプリ —— 両端とも自分のもの	認可済みの主要 SaaS。バイパスはベンダー自身の推奨であり、証明書ピンニングもあって傍受は割に合わない
未知・危険・未分類の宛先 —— 脅威と DLP の価値が集中している場所	代わりにテナント制限ヘッダ、条件付きアクセス、CASB API で統制する

証明書がピンニングされたホストは、バイパスを提案するだけで、自動バイパスは決してしません。決めるのは運用者で、その決定は目に見えます。

Edge が、復号したものをどう張り直すか

Edge が通信を復号したら、上流への接続は Edge 自身が張り直すことになります。そしてその接続は、張った側のスタックの指紋を持ちます。今日のウェブのかなりの部分は bot 対策の背後にあるので、ふつうの Go クライアントで張り直すプロキシは、ブラウザなら普通に開けるサイトでチャレンジを受けます。 Edge の egress エンジンは代わりに、実際の Chrome のネットワークスタックで張り直します。

これは Edge 自身の egress 経路であって、Edge の隣に立つ構成要素ではありません。 担うのは転送だけで、ポリシーを持たず、判定もしません。渡ってくるのは Edge が既に決め終えたリクエストです。既定では別サービスとして動き Edge が HTTP で呼びますが、embedbroker タグでビルドすると Edge のプロセス内で動きます。どちらも同じコードで、 両者の指紋が一致することをテストが検証しているので、離れていくことがありません。

後から気づかれるより先に言っておくべき帰結が2つあります。既定の形では、全面復号の配備は 単一の静的バイナリではなく2プロセスです（エンジンが cgo でネイティブライブラリを結合するため）。そして黙ってフォールバックしません —— Go による模倣は bot 対策が既に弾いている指紋なので、そこへ退避すると「broker が落ちている」という1つの読める失敗が、宛先ごとにばらけた不可解な故障に化けます。Edge は通信を失敗させ、自らを unready と報告します。

識別情報 —— 人間以外のものも含めて

ポリシーは識別情報に対して書きます。そしてここでの識別情報には、AI エージェント、NHI、MCP、 Tool 実行の委任が含まれます —— 後付けではなく、最初から設計対象でした。委任されたアクセス権は明示的で、永続化され、失効可能です。社内システム間の East-West アクセスには、帯域外での step-up 承認があります。