仕組み
構成要素は4つ、規則は1つです。許可ルールに一致した通信だけがトンネルされ、 それ以外は1バイトも複写せずに閉じられます。
| 構成要素 | 動く場所 | 役割 |
|---|---|---|
| Agent | 端末（macOS / Windows） | OS のネットワーク層で通信を捕捉して Edge へステアし、フロー単位の許可・拒否をローカルでも強制する |
| Edge | 自社のインフラ | すべての通信をポリシーで判定し、許可したものを転送し、設定された箇所では復号・検査し、復号したものを張り直し、判定を監査に残す |
| Control Plane | Edge の隣 | Admin API、ポリシーエンジン、識別情報と NHI の登録、監査、OIDC。設定・受け入れ・失効を書く場所 |
| Connector | 自社の私設ネットワークの中 | Edge と社内アプリをつなぐアウトバウンド専用の橋。そのアプリへの唯一の入口でもある |
1つのリクエストに何が起きるか
よく聞かれる2点なので、はっきり書いておきます。
- デフォルト拒否はモードではなく、既定です。 ルールが無いことが許可を意味する設定は存在しません。
- 社内アプリがインバウンドで露出することはありません。 Connector は Edge に対して外向きに接続します。内向きに接続してくるものはありません。 アプリにはインターネットに面した listener がそもそも無いので、攻撃対象になりません。
自分で運用するものは、本当に ZTNA なのか
はっきり答える価値のある問いです。「ZTNA」は大手ベンダのクラウドの同義語として 使われることが多く、その用法だと、事業者が自分で運用するものは定義上すべて失格になります。 そうなるとその語はセキュリティの性質ではなく、事業モデルの説明になってしまいます。
ZTNA は信頼のモデルです。トポロジでもベンダでもありません。 ネットワーク上の位置で信頼しない。すべてのアクセスを、識別情報・端末・ポスチャ・ポリシーに照らして 検証する。デフォルト拒否。1つの制御点で強制する。配備がその性質を判定の経路に持っているか、 持っていないか、それだけです。そして Lantern DSSE では、誰がホストしているかから推測するのではなく、 判定の経路そのものを読めます。
規模と地理は別の問いで、こちらにも実際の答えがあります。マルチリージョンは可用性とデータ所在を実現し、 このリリースに含まれます。ただしそれがゼロトラストを成立させているわけでは ありません。単一ノードでもその性質は成立しますし、これらの検証を欠いた世界規模のクラウドでは 成立しません。
Agent が端末上になければならない理由
Agent は macOS の Network Extension、あるいは Windows の WFP エージェントと自社製 callout ドライバとして 動き、OS のネットワーク層で通信を捕捉します。誰かが設定し忘れうるプロキシ設定ではありません。 mTLS のデバイス識別情報を持つので、Edge が受け入れるのは資格情報ではなく端末です。 ポスチャ、リスク状態、失効は継続的に見ているため、端末は動作中に受け入れ・降格・遮断され得ます。
同じ LAN の仲介ができるのも、端末側にいるからです。クラウドだけのサービスは、隣り合って置かれた 2台の間の通信を原理的に見られません。
どこを復号し、どこを意図的に復号しないか
復号する宛先と、復号せずに転送する宛先は、傍受の設定で決まります。 認可済みの SaaS であることだけを理由に、検査対象から外れるわけではありません。 現在のラボでは、AI サービスへの通信も DLP 検査の対象にしています。
復号した通信には、内容の検査と DLP ルールを適用できます。 復号から除外した通信では、暗号化された内容を DLP で検査できません。 そのため、除外は運用者が必要とする検査範囲を踏まえて設定します。
証明書がピンニングされたホストは、バイパスを提案するだけで、自動でバイパスすることはありません。 決めるのは運用者で、その決定は目に見えます。
Edge は、復号したものをどう張り直すか
Edge が通信を復号したら、上流への接続は Edge 自身が張り直します。 標準構成では、この接続に Go の HTTP・TLS 実装を使います。 ポリシーの適用、DLP 検査、上流サーバーの証明書検証を維持したまま転送します。
現在の3リージョンのラボはこの構成で稼働しており、Experimental リリースにも採用します。 この配備で Web 閲覧の動作を確認しています。上流接続の TLS・HTTP の指紋は Go のもので、 Chrome と同じ指紋を示す構成ではありません。 すべてのサイトの bot 対策との互換性を保証するものではありません。
ソースには、選択肢として curl-impersonate の実装も含まれます。 BoringSSL にリンクした libcurl に、ブラウザに合わせた TLS・HTTP/2 設定を持たせたものです。 cgo で Edge に組み込む構成と、別の egress サービスとして動かす構成があります。 利用には追加のビルド・設定が必要で、標準ビルドとインストーラでは有効になりません。 いずれの実装も、内部でブラウザを動かすものではありません。
egress の実装は、配備時に明示的に選びます。curl-impersonate を選んだ場合、エンジンの障害時に Go へ自動で切り替わることはありません。標準の Go 経路は、それ自体が選択された構成です。 どちらの構成でも、検査や証明書検証の自動バイパスを認めるものではありません。
識別情報。人間以外のものも含めて
ポリシーは識別情報に対して書きます。ここでの識別情報には、AI エージェント、NHI、MCP、Tool 実行の委任が 含まれます。後付けではなく、最初から設計対象でした。委任されたアクセス権は明示的で、永続化され、 失効できます。社内システム間の East-West アクセスには、帯域外での step-up 承認があります。