自社で運用するゼロトラストネットワーク「Lantern DSSE」をオープンソースで公開しました

Lantern DSSE は、SSE（Secure Service Edge）を、自社で用意したサーバーの上で動かすためのソフトウェアです。社内アプリへのアクセス（ZTNA）、インターネットへのアクセスの制御（セキュア Web ゲートウェイ）、TLS を復号しての情報漏えい対策（DLP）を、1つの仕組みで扱います。Apache-2.0 で GitHub に公開しています。

この記事では、なぜ作ったのか、全体がどう組み立てられているのか、何ができるのかを紹介します。

いまの版（0.4.0）は experimental（実験的）です。production ready ではありません。インターフェースや既定値は、移行手段なしに変わることがあります。試すときは、壊れても困らないラボの端末で試してください。

なぜ作ったのか

ランサムウェアの被害は、大企業だけの問題ではない

警察庁の資料では、令和7年上半期のランサムウェアの被害報告116件のうち、77件が中小企業でした。被害にあった企業・団体へのアンケート（有効回答45件）では、感染経路のうち28件が VPN 機器でした。

VPN は、社外の端末を社内ネットワークの「内側」に入れる仕組みです。内側に入ってしまえば、その中は仕切りのない一続きのネットワークです。乗っ取られた端末からも隣の機械へ直接つながり、被害を別の機械へ広げる「横展開」ができてしまいます。1台の感染が全社の被害に変わるのは、この段階です。

横展開を抑えるには、ZTNA が効く

ZTNA（ゼロトラストネットワークアクセス）は、社内に「内側」を作らず、接続のたびに、誰がどの端末からどこへつなごうとしているかを確かめて、許可するかを決める考え方です。乗っ取られた端末からでも、許可されていない機械にはつながりません。ランサムウェアの被害が1台から全社へ広がるのを抑えるのに、とても有効だと私たちは考えています。

しかし、製品は海外にあり、価格も高い

ZTNA は、多くの場合、クラウド型の SSE の機能として提供されています。そのクラウド型の SSE は、ほとんどが海外の企業の製品で、運営も海外で行われています。経済産業省の「サイバーセキュリティ産業振興戦略」も、国内で使われるセキュリティ製品の多くを海外製が占めていることを課題に挙げています。

クラウド型では、通信の暗号はサービス事業者の設備で解かれます。どこの設備で、どんなコードが通信を読んでいるのか、利用者からは確かめられません。

価格も、欧米の水準を基にしたサブスクリプションです。払い続けられる大企業以外では、なかなか導入が進んでいないと感じています。被害の多くが中小企業で起きているのに、横展開を抑える手段が届いていません。

だから、自分で運用できる SSE を、オープンソースで作った

そこで私たちは、次の3つを満たす SSE を作ることにしました。

• 通信を復号する場所（Edge）を、運用者が自分で用意したサーバーに置ける
• 通信を復号し、判定するコードを、誰でも読める
• Apache-2.0 で公開し、ソフトウェアそのものは無償で使える

全体の構成

構成要素	動く場所	役割
Agent	端末（macOS / Windows）	OS のネットワーク層で通信を捕まえて、Edge へ送る
Edge	自社のサーバー	通信をポリシーで判定し、許可したものを転送する。設定した宛先は復号して検査する。判定は監査記録に残す
Control Plane	自社のサーバー	管理画面と管理 API。ポリシー、端末の受け入れと失効、監査を扱う。設定に署名して Edge に配る
Connector	社内ネットワーク	社内アプリと Edge をつなぐ。外向きに接続するだけで、外からの接続は受け付けない

できること

すべての接続を、ポリシーで判定する

エージェントを入れた端末の通信は、Edge を通ります。Edge は接続ごとに、ポリシーに照らして許可か拒否かを決め、その判定を監査記録に残します。

どのルールにも当たらない通信は拒否します。判定の関数は、最初に「拒否」を置いてから始まります。

decision/evaluator.go

	decisionValue := "deny"
	reason := "No active policy matched the request."
	reasonCodes := []string{"no_policy_match"}

decision/evaluator.go#L104-L106

同じ LAN の中の通信も判定する

エージェントは端末の中にいるので、同じ LAN にある隣の機械へ向かう通信も捕まえて、Edge で判定できます。横展開に使われるのは、まさにこの経路です。クラウドだけで動くサービスでは、同じ LAN の2台の間の通信はクラウドを通らないので、ここには手が届きません。

ただ、いきなり社内の通信を止めると業務が止まります。そこで社内の機械どうしの接続は、段階を踏んで強制へ進めます。

段階	どのルールにも当たらない接続
OBSERVE（観察）	記録して通す。ルールはまだ適用しない
PARTIAL ENFORCE（部分強制）	ルールを適用する。当たらないものは記録して通す
FULL ENFORCE（完全強制）	ルールを適用する。当たらないものは拒否する

新しい組織は OBSERVE から始まります。実際の通信を見ながらルールを作り、確かめてから強制へ進めます。

重要な接続では、本人確認を求める（OOB 認証）

ポリシーで指定した接続は、許可の前に本人確認を求めます。

1. 本人確認がまだの接続を、Edge は保留します。
2. エージェントが既定のブラウザを開き、確認ページに、いま接続しようとした接続先を表示します。
3. 利用者は、組織の ID プロバイダーの画面でサインインします。
4. 認証が終わると、保留していた接続がそのまま進みます。接続をやり直す必要はありません。

認証は、保留している接続とは別の経路（ブラウザ）で行うので、OOB（Out-of-Band）認証と呼んでいます。認証で得た許可は、認証のきっかけになった接続先にだけ効きます。ID プロバイダーは OIDC でつなぎ、Microsoft Entra ID、Google、Okta、一般の OIDC を登録できます。

攻撃者が端末を操作できても、パスキーやセキュリティキーなど、盗んだパスワードだけでは満たせない認証を求めれば、次の機械への接続は進みません。

社内アプリを、外向きの接続だけで公開する

社内アプリへのアクセスは、Connector を通します。Connector は社内から Edge へ、外向きに接続します。外から Connector へ入ってくる接続は受け付けません。社内アプリにインターネットからつながる口を開ける必要はないので、狙われる入口が増えません。

インターネットへのアクセスを制御する

インターネットへの通信は、Internet Access のルールで制御します。1つのルールで、次のことを決めます。

項目	内容
送信元	端末、端末のグループ、利用者、ID プロバイダーのグループ、AI エージェントなど
宛先とサービス	名前を付けた宛先とポート
アクセス	許可、拒否、本人確認を求める
TLS 復号	復号して中身を検査するか、しないか
DLP ポリシー	復号した通信に適用する DLP
リスクのしきい値	利用者や端末のリスクが一定以上のときだけ、このルールを使う

端末の DNS の問い合わせも、トンネルを通して Edge 側で解決します。

TLS を復号して、送る中身を検査する（DLP）

いまの Web の通信は、ほとんどが TLS で暗号化されています。暗号化されたままでは、何が送られているかはわかりません。そこで、運用者が「検査する」と決めた通信は、Edge で TLS を復号して、アップロードの中身を検査します。見つけられるのは、次のようなものです。

• マイナンバー、法人番号、クレジットカード番号、API キー、メールアドレス、電話番号
• 組織ごとに決めたキーワードや、文字の並びのパターン
• 顧客番号や社員番号など、あらかじめ登録しておいた値

Word や Excel などの Office ファイルや PDF は、中の文字を取り出して検査します。見つかったときの扱いは、ポリシーごとに、記録だけする、警告する、止める、本人確認を求める、の4つから選べます。同じ端末から短い時間に何度も見つかったときは、その端末のリスクを上げ、リスクに応じたルールにつなげることもできます。

復号した通信は、Edge が上流のサーバーへ接続を張り直します。標準の構成では Go の HTTP・TLS 実装を使い、上流サーバーの証明書を検証したうえで転送します。

会社のアカウントでだけ使わせる（テナント制限）

Google Workspace、Microsoft 365、ChatGPT、Claude では、会社が許可したアカウントにだけサインインさせることができます。Edge が復号した通信に「許可するアカウント」を書き添え、サービスの側がそれに従って制限します。

AI エージェントも、ポリシーの主体として扱う

ポリシーの主体は人だけではありません。AI エージェントやサービスアカウントなど、人以外の主体（NHI）についてもポリシーを書けます。

• 誰かの代理で動くエージェントの権限は、記録として残る「委任」として与え、あとから取り消せます。
• エージェントの操作に人の承認を求めるときは、エージェントの外の経路で承認します。
• エージェントの通信も、ほかの通信と同じようにポリシーで判定され、監査に残ります。

エージェントがだまされて想定外の接続をしようとしても、届く範囲はネットワークの側で絞れます。

macOS と Windows のエージェント

OS	通信を捕まえる仕組み	配布物
macOS	Network Extension の透過プロキシ（NETransparentProxyProvider）	Developer ID で署名し、notarize 済みのパッケージ
Windows	WFP と、自社製の callout ドライバ（clients/windows-wfp/driver）	ドライバは Microsoft の attestation 署名済み。Secure Boot とメモリ整合性を有効にしたまま読み込めます

エージェントは端末ごとの証明書を持ち、mTLS で Edge につなぎます。Edge が受け入れるのは、パスワードではなく、登録された端末です。管理者が端末を失効させると、すべての Edge がその端末を拒みます。

エージェントの更新も、署名して配ります。更新に署名する鍵は導入時に作られ、Edge も端末もその鍵を持ちません。端末は、固定した公開鍵で署名を確かめてから更新します。

複数の組織を、1つの配備で運用する

1つの配備の中に、複数の顧客組織を置けます。各組織は自分の認証局を持ち、組織の端末はその組織の認証局につながります。管理画面では、役割（owner、管理者、分析担当など）ごとに操作できる範囲が分かれ、ある組織の管理者が別の組織のポリシーや鍵、記録を見ることはできません。運用する事業者が、顧客の組織を代わりに管理する「委任」もあります。

Edge を並べて負荷を分け、Region に分けて置く

Edge は1台だけでなく、何台も並べて置けます。端末や Connector は、まず HAProxy につなぎます。HAProxy は、受けた接続を、後ろに並べた Edge のどれかへ振り分けます。0.4.0 では、次の2つの構成を用意しています。

構成	置き方	接続の振り分け先
1つの Region に3台	3台のマシンのそれぞれに、HAProxy、Control Plane、Edge、データベースを置く	3台すべての Edge
3つの Region	Region ごとに、HAProxy と Control Plane を置くマシン1台と、Edge 専用のマシン2台以上。最小で9台	その Region の Edge だけ

ここでいう Region は、DSSE の中で通信を処理する場所の単位です。クラウド事業者のリージョンとは別のものです。東京に2Regionと大阪に1Regionという配備でも問題ありません。

負荷の分け方：HAProxy は TLS を復号せずにそのまま通し、端末、Connector、本人確認中のブラウザからの新しい接続を、開いている接続がいちばん少ない Edge に渡します。振り分けるのは、端末と Edge の間の接続です。エージェントは Edge との間にいくつかの接続を張り、アプリの通信はそのどれかの中をまとめて通ります。いったん Edge が決まると、その接続が閉じるまで、中を通る通信は同じ Edge で処理されます。

Edge が止まったとき：止まった Edge は振り分けの対象から外れ、新しい接続は残りの Edge へ向かいます。認証の結果は Edge の間で共有されるので、ある Edge で得た許可は、同じ接続先なら他の Edge でも通ります。止まった Edge で途中だった本人確認も、別の Edge で完了できます。

状態の持ち方：設定や認証の状態を保存するデータベースは、3台に複製します。3台が投票権を持ち、決定には2票が要ります。Edge 専用のマシンは、データベースも Control Plane も持ちません。認証の許可と失効は、すべての Region の Edge に届きます。

組織ごとの Region：組織ごとに、通信を処理してよい Region を限れます。許されていない Region の Edge は、その組織の通信を、復号する前に拒みます。

Region フェイルオーバー：端末と Connector は、つないでよい Region の一覧を持っています。いまの Region の HAProxy に届かなくなると、一覧の中の別の Region につなぎ直します。移る先は、その組織に許された Region だけです。

置き場所と鍵を、自分で決める

• 認証局：端末や通信の証明書を発行する認証局は、導入のときに運用者の手元で作ります（dsse-install）。開発元から受け取るものではありません。
• 開発元のサーバーに接続しない：ライセンスを確かめるサーバーはなく、配備が開発元のサーバーへ自動で接続する仕組みもありません。開発元に何が起きても、配備はそのまま動き続けます。
• 監査記録：記録は配備の中のデータベース（ClickHouse）に保存します。外部の S3 互換ストレージへのアーカイブも選べます。

試すには

構築の手順は、このあとの記事で順に説明していきます。先に試したい方は、Deployment に、端末のエージェントや管理画面まで含めた手順があります。1台のマシンで動かすラボの構成も含まれています。署名済みの macOS・Windows のエージェントは Releases にあります。

いまの状態

2026年10月30日に 0.4.0 experimental を公開しました。3つの Region に Control Plane と Edge を分けて置く構成、すべての Edge での認証結果の共有、サーバーのコンテナイメージ5つ（linux/amd64）が加わりました。0.4.0 は、新しく導入する場合だけを対象にしています。

公開した installer とイメージで3つの Region を新しく組み、2つの組織、2つの Connector、実機の macOS と Windows で確かめました。本人確認のあと、保留した接続が再開することも確かめています。

これから

通信を復号する理由は、DLP だけではありません。将来的には、生成 AI の応答の中身を調べる機能や、どの機密データがどこへ流れているかをつかむ機能（DSPM）を組み込んでいきたいと考えています。

おわりに

Lantern DSSE は、Lantern Networks（ランタンネットワークス株式会社）が開発しています。Qiita では、このあとも、構築の手順や機能ごとの仕組みを説明する記事を増やしていきます。

Web サイトにも、仕組みの説明をまとめています。

• 仕組み
• VPN との違い
• OOB 認証
• TLS 復号が必要な理由
• AI エージェント
• データ主権

ラボで試していただけたら、どの版・どの OS で何を試し、どこで手順や動きが想定と違ったかを、Issue で教えてください。トークンや秘密鍵、個人情報は含めないでください。GitHub でスターをいただけると励みになります。

参考

• 警察庁「令和7年上半期におけるサイバー空間をめぐる脅威の情勢等について」資料編 p.59
• 「日本発のサイバーセキュリティ製品が次々に創出されるために ~ 経済産業省「サイバーセキュリティ産業振興戦略」」ScanNetSecurity（2025年3月13日）