ちらりんブログ会員特典に Simple ZTA を追加します（β 版）

はじめに

ちらりんブログの月額 980 円スタンダードプラン会員向けに、自作の ZTA (Zero Trust Access) サービス Simple ZTA を β 版として追加します。追加料金は発生しません。既存会員はそのまま申請できます。

ざっくり言うと、ブラウザから自宅サーバーに SSH / RDP / Telnet で接続できるサービスです。個人が会員特典として出すには少し大きすぎる仕組みですが、あえて β という形で公開して、反応を見ながら育てていくつもりです。

この記事では、何を作ったのか・どういう構成で動いているのか・なぜ会員特典にしたのか・そして β 版として出す以上は触れざるを得ない制限事項と法令対応の現状について、できるだけ率直に書きます。

何を作ったのか

Simple ZTA は、自宅や職場に置いたサーバーへのアクセスを「ブラウザ + 認証 + ログ」で完結させるゼロトラスト型のリモートアクセス基盤です。

できること

• ブラウザから自宅サーバーへ SSH ターミナル接続（xterm.js の画面がそのまま開く）
• ブラウザから RDP 接続（Guacamole 経由で Windows 画面がそのまま開く）
• ブラウザから Telnet 接続（ネットワーク機器向け）
• ネイティブクライアント (szta-client) 経由で PuTTY / TeraTerm / mstsc といった既存ツールも利用可
• 全セッションの 録画（SSH は asciinema 形式、RDP は動画）
• コマンドログ（SSH / Telnet）と 監査ログ（ログイン、セッション作成、管理操作）
• TOTP による 2 段階認証、認証情報の AES-256-GCM 暗号化保管 (Vault)

既存の「SSH ポートをインターネットに開けてうっかり踏まれる」や「VPN を張って自宅 LAN 全体に穴をあける」といった運用を、ホスト単位のポリシー制御 + 監査ログ に置き換えるのが目的です。

似たサービス

方向性として近いものを挙げると、次のあたりです。

• Cloudflare Access / Cloudflare Tunnel: エッジで認証してバックエンドに通す
• Tailscale / Twingate / NetBird: Mesh VPN + ID 連携
• Teleport: OSS のアクセスプロキシ（企業向け）

これらはどれも完成度が高く、私も普段から使っています。Simple ZTA はそれらを置き換える目的で作ったものではありません。

あえて違いを挙げるなら次のような性格を持たせました。

• 個人運営。バックにベンチャーキャピタルも営業部門もいません
• 録画・コマンドログ・監査ログを標準装備。オプションや上位プランに隠していません
• 自宅サーバー 1 台に 1 agent という「個人の homelab」想定のスコープ
• β 版として小さく運用し、規模が大きくなったら届出を出して正規化する前提

「OSS を組み合わせれば似たものは作れる」と感じる方もいると思いますが、その通りです。実際、私自身もそうやって作りました。この β 版は、できあがった仕組みを会員特典として共有する試みだと捉えていただくのが正確です。

なぜ作ったのか

会員特典として出した話の前に、そもそも「なぜ ZTA のような仕組みを自分で作ろうと思ったのか」のほうを書いておきます。ここが記事の中で一番伝えたい部分です。

リモートアクセスと言えば VPN、だが VPN 装置は今いちばん狙われている

自宅や職場のサーバーに外から入る、と言われれば多くの人は VPN を思い浮かべると思います。私自身、長らく VPN を使ってきましたし、今でもバックアップ経路としては手元に置いています。

ただ、一次情報を追うと、VPN 装置が「置いておくだけで安全な境界」ではなくなっているのが明確に見えてきます。

IPA が 2026 年 1 月に公開した 情報セキュリティ10大脅威 2026 の組織編では、「ランサム攻撃による被害」が 11 年連続で 1 位 に入りました。同じランキングでは「システムの脆弱性を悪用した攻撃」が 4 位（6 年連続）、「リモートワーク等の環境や仕組みを狙った攻撃」が 8 位（6 年連続）にランクインしています。攻撃者が脆弱性とリモートアクセス経路を狙い続けている、という構図が毎年固定化しています。

具体的にどこが狙われているか、という話は警察庁の統計が詳しいです。警察庁が発表しているランサムウェア被害報告のうち、感染経路の 8 割以上が VPN 機器またはリモートデスクトップ経由 で占められているという集計が毎年公表されています（Security NEXT による集計の要約 / 令和 5 年データで VPN 機器等 63.4% + RDP 18.3% = 81.7%）。最新の 令和 7 年上半期の警察庁レポート でも同様の傾向が続いており、侵入口としての VPN 機器の重みは下がっていません。

IPA 自身も 2025 年 10 月末に VPN 機器等に対する ORB 化を伴うネットワーク貫通型攻撃に関する注意喚起 を出しています。NetScaler、Ivanti Connect Secure、FortiOS / FortiProxy といった代表的な製品の深刻な脆弱性が立て続けに報告され、パッチ未適用の機器が乗っ取られて他組織への攻撃中継点（ORB）に転用される事例まで確認されている、という内容です。

VPN というプロトコル自体が悪いわけではありません。問題は、VPN 装置（アプライアンス）が境界に露出した状態で運用されていて、パッチ適用が攻撃者の動きに追いつかないと、境界そのものが侵入口になる、という構造にあります。境界を一度突破されると、そこから LAN 全体に横展開されやすい、という次の話も避けて通れません。

国内でも実際に起きている

この構造の話は抽象論ではなく、ここ 1〜2 年の国内事例でそのまま現れています。象徴的な 3 件を挙げます。

アサヒグループホールディングス（2025 年 9 月）

ビール市場のおよそ 4 割を握る同社は、9 月 29 日にランサムウェア攻撃を受け、出荷停止を含む広範な業務停止に追い込まれました。同社が 11 月に行った記者会見およびその後の報道によれば、攻撃者（Russian-linked の Qilin と報じられています）は 公開されていた VPN 機器の脆弱性 を悪用して初期アクセスを取り、データセンター内のサーバー群と端末を暗号化。同社は後に内部 VPN の廃止とネットワーク再設計を対策として発表しています（日経 xTECH の解説記事 / トレンドマイクロの考察）。約 192 万人分の個人情報が漏洩した可能性がある、とも発表されています。ブランド認知度が高い企業で、一般消費者にまで影響が伝わった象徴的なケースです。

日本医科大学武蔵小杉病院（2026 年 2 月）

2 月 9 日未明、ナースコール系サーバー 3 台がランサムウェアに感染。調査の結果、侵入経路は 医療機器保守用に設置されていた VPN 機器 で、該当機器はパスワードが弱く、かつ既知の脆弱性が未修正の状態だったことが同院の第 2 報で公表されています（同院公式リリース第 2 報）。患者約 1 万人分の個人情報漏洩が確認され、攻撃者は 13 万件超の窃取を主張、身代金要求額は巨額に上ったと報じられています（日経 xTECH）。「VPN 装置を設置したまま保守が追いつかない」という、規模を問わず起きうる構図です。

関西総合システム（2025 年 11 月〜12 月）

情報処理・システム開発を行う同社も、2025 年 12 月にランサムウェア感染を公表。その後の第二報で、11 月 14 日から 12 月 26 日にかけて VPN 機器経由の不正アクセス の痕跡があったこと、侵入はアカウント情報（ID / パスワード）の悪用による可能性が高いことを明らかにしています。犯行グループは Brain Cipher を名乗っています（報道のまとめ）。脆弱性だけでなく、VPN 機器のアカウント管理不備 も侵入口になりうる、という事例です。

古い事例を 1 件補足しておくと、2022 年 10 月の 大阪急性期・総合医療センター も外せません。給食委託事業者の VPN 装置（CVE-2018-13379 の脆弱性を悪用された Fortinet 製品）経由で侵入され、そこから RDP で病院本体に横展開、電子カルテシステムが 2 ヶ月以上停止し、診療制限による逸失利益は数十億円規模と試算されています（調査報告書概要 PDF / piyolog のタイムライン）。委託先の VPN が自社のリスクになる、というサプライチェーンと境界の交差点を示すケースとして、今でも参照価値があります。

これらは規模も業種もバラバラですが、共通しているのは「境界に置かれた VPN 装置が入口になり、内側に横展開された」という一点です。他人事として片付けられる話ではない、という感覚は多くの読者と共有できると思います。

必要なのは「境界を張る」から「ホスト単位で認可・監査」への移行

この構造への答えとして、世の中ではいわゆる ゼロトラスト / ZTNA（Zero Trust Network Access）の考え方がだいぶ広まっています。一言で言えば、「境界の内か外かで信用を分けるのをやめて、接続のたびにユーザーとデバイスを認証・認可し、ホスト単位でアクセスを許可し、全部ログに残す」という発想です。

この思想を実装した SaaS として、すでに Cloudflare Access、Tailscale、Twingate、NetBird、Teleport といった優れたプロダクトが世に出ています。私自身これらを業務や個人用途で使っていて、完成度の高さは知っています。ここに個人が新しいプロダクトで挑む、という話ではありません。

では何をしたかったかというと、この思想を自分の手元で小さく実装し、会員が触れる形にしたかった、ということに尽きます。自宅の homelab 規模、1 会員 1 Agent という小さなスコープで、「ブラウザで入って、認証して、ホスト単位で許可して、全部録画・ログ保存する」という一連の動作を自分のコードで回す。そしてその体験を、設計思想の話に終わらせず、会員が自分のサーバーで確かめられる形にする。Simple ZTA はそういう位置づけの自作ソフトウェアです。

だから私は、VPN の代替として「完成した商用サービスを紹介する記事」ではなく、自分で書いた ZTA を会員と一緒に触る β という形を選びました。

なぜ会員特典にしたのか

ちらりんブログは有料コンテンツの設計思想として、以前書いた記事で次の区分を採用しています。

• 無料: 設計思想・考え方・教訓
• 有料: 本番設定ファイル・再現手順・監視ダッシュボード

会員特典として「会員 Grafana」を提供し、実稼働している Proxmox / Docker の監視データを 見る 体験を用意してきました。今回追加する Simple ZTA は、その延長にある 触る 体験です。

読む → 見る → 作る → 確かめる、というサイクルを想定したときに、「確かめる」を会員が自分の環境で体験できる場が欲しかった、というのが素直な動機です。自分が作ったものを見せるだけではなく、会員自身がブラウザから自分のサーバーに入って、ログが残り、録画が残る、という体験を触って確認してほしい、という狙いがあります。

また、単体販売ではなく 追加料金 0 円の実験的付録 として出す判断をしたのは、次の理由からです。

1. 単体プロダクトとして売るには、サポート体制や SLA が追いつかない
2. 既存の会員向け特典にぶら下げる形であれば、スタンダードプランの価値を高める方向に作用する
3. フィードバックの密度が重要なフェーズなので、不特定多数ではなく会員コミュニティから反応を集めたい

商用化するかどうかは、この β を動かしながら決めます。結果として Phase B（有償オプション）に切り出す可能性もあるし、会員特典の中で完結させる可能性もあります。

技術構成

作りはシンプルです。Portal / Agent / Web UI の 3 コンポーネントで、間を gRPC と WebSocket でつなぐ構造です。

全体図

※ szta ポータルのガイドページで公開している図をそのまま掲載しています。図はポータルガイドの現行版のままであり、実装の変遷（mTLS → JWT + h2c）は本節の後述「なぜ mTLS ではなく JWT なのか」を参照してください。

構成要素としては、この図に加えて Portal 側に次のコンポーネントがぶら下がっています。

• PostgreSQL（ユーザー / agent / セッション / audit_logs）
• guacd（RDP の画面描画）
• Vault（AES-256-GCM で credentials 暗号化）

ポイントは Agent が自宅サーバー側から Portal に outbound で張りに来る という点です。会員の自宅にインバウンドの穴を開ける必要がありません。Cloudflare Tunnel 経由で gRPC ストリームを張り、Portal 側はそのストリームに乗せてセッションデータを流します。

採用技術

セッションの流れ

1. 会員がブラウザで Portal にログイン（PIN + TOTP、または OIDC/Entra ID）
2. 自分の Agent を一覧から選んで SSH / RDP / Telnet のボタンを押す
3. Portal がセッションを作成し、対応する WebSocket エンドポイントを開く
4. Agent が gRPC ストリーム経由でセッション要求を受け取り、ローカルで SSH / RDP / Telnet のプロキシを起動
5. ブラウザ ↔ Portal ↔ Agent ↔ 自宅サーバー の双方向ストリームが確立
6. 入出力は PTY プロキシでストリームし、同時に録画ファイル (.cast / .mp4) とコマンドログ (.jsonl) に書き出す
7. 切断時に audit_logs に session.end を書き込み

SSH については Agent 自身の権限で PTY を直接 spawn する PTY モード もサポートしており、追加のユーザー鍵配置なしに使える構成を用意しています（後述のとおり制限付きです）。

なぜ mTLS ではなく JWT なのか

当初は gRPC の mTLS で Agent を認証していました。しかし、外部の会員端末に証明書を配って回るのは運用負荷が高く、Cloudflare Tunnel の Free プランでは mTLS ポリシーが使えません。

最終的に採用したのは、Register 時に Portal が発行する JWT (access=1 時間 / refresh=30 日) を Agent が持ち回り、h2c の gRPC ストリームに乗せる方式です。Cloudflare Tunnel は --protocol http2 を明示指定しないと QUIC が優先されて gRPC trailer が落ちるので、そこだけは落とし穴として明示しておきます。

この移行話は別記事にする予定の素材があります。ここでは「結論として JWT + h2c + Cloudflare Tunnel で動いている」とだけ書いておきます。

Agent のアンインストール

「入れたら使える・消したら消える」を満たすために、Portal 側で Agent を削除したときに 端末側で自己アンインストールスクリプトが走る 仕組みを組んでいます。

• Linux: systemd-run --no-block --collect で独立した transient unit に切り出して実行（setsid + nohup は親 cgroup に巻き込まれて失敗するため不採用）
• Windows: PowerShell で親プロセスの exit を待ってから sc delete

オフラインの Agent に対しては「保留削除」としてマークし、次回接続時に自動で uninstall を発火させます。キャンセルと強制削除もサポート済みです。

会員から見た使い方

招待と初期セットアップ

1. 会員ポータルから β 版の参加を申請（手動承認）
2. 承認メールに含まれるワンタイムリンクから初期パスワードと TOTP を設定
3. 自宅サーバーで表示された curl コマンドをコピー＆ペーストで実行
4. Agent がインストールされ、Portal に登録される（所要 1〜2 分）
5. Portal に戻ってホストが一覧に出ていることを確認

できる接続

1 会員 1 Agent / 1 ユーザーアカウント という制限を β 期間中はかけます。複数ホストやチームでの利用は、フィードバックを見てから Phase B で検討します。

ネイティブクライアント (szta-client)

ブラウザ内のターミナルで足りない場合は、Windows / Linux 用の szta-client バイナリを配布しています。ローカルポートを listen して Portal 経由のトンネルを張るので、既存の PuTTY / TeraTerm / mstsc がそのまま使えます。

制限事項 — 誠実に明示しておきます

β 版として出す以上、できることよりも できないこと・現状の制約 を先に書いておくべきだと考えています。

SLA なし・ベストエフォート

稼働率・応答時間・復旧時間の保証はありません。メンテナンスやセキュリティ対応で停止することがあります。業務クリティカルな経路での利用は想定していません。

代替経路を必ず確保してください。Simple ZTA が止まっても接続先サーバーを操作できる手段（物理コンソール、IPMI、別経路 VPN 等）を用意した上で使うことを前提にしています。

規模拡大時に電気通信事業届出を出す予定

Portal が複数会員の通信を中継する構造は、電気通信事業法上の「他人の通信の媒介」に該当する可能性があります。類似の SaaS（Cloudflare Access、Tailscale 等）は日本で届出事業者になっているので、同じ構造の Simple ZTA も、規模拡大時には届出を出す必要があると考えています。

現時点の整理は次のとおりです。

• 法令調査エージェントによる一次整理は実施済み（電気通信事業法 / 個情法 / 特商法 / 消契法 / GDPR / 不正アクセス禁止法の 6 分野）
• 総務省への事前照会と弁護士レビューは 未実施
• β 運用で得られた実態を踏まえて事前照会を行う予定

これは「届出なしで商用規模に拡大する」という意味ではありません。β としての小規模運用と、商用化前提の拡大は段階を分ける、という設計です。弁護士レビュー無しでの本格展開は推奨されないという一次整理も出ており、そこを踏まえた上での β 版公開です。

突然サービス終了の可能性

利用特約（ドラフト）に明記していますが、セキュリティ上の重大な問題・法令の変更・運営継続が困難な事情がある場合は、告知期間を短縮して終了することがあります。

通常のメンテ停止や機能変更については、原則として 30 日以上の告知期間を設けるよう努めます。

賠償上限

万一の場合の賠償額は 金 1,000 円またはスタンダードプラン月額相当額 (税込 980 円) のいずれか高い額 を上限としています。「一切の責任を負わない」という条項は消費者契約法 8 条で無効化されてかえって賠償範囲が広がるため、具体的な上限額を書く方針にしました。

β 版として出す以上、ここは曖昧にできない部分です。

インパーソネーション機能の存在

管理運用の都合上、運営者（私）が会員のセッション録画・コマンドログ・監査ログを閲覧できる「管理者閲覧機能」が実装されています。使用目的は以下に限定しています。

• セキュリティ事象の調査
• 不正利用の有無の確認
• 会員からのサポート要請への対応
• 法令に基づく開示請求への対応

当該機能の使用自体も audit_logs に記録されます。録画には第三者の個人情報が混入し得るため、接続先機器に格納される情報の適法性は会員自身の責任でご確認ください。録画・ログは 7 日間で自動削除されます。

まだ実装していないもの

• SAML 連携（OIDC/Entra ID は実装済み）
• OIDC の auto-provision（現状は pre-provisioned only）
• 承認ワークフロー
• 1 会員あたり 2 台目以降の Agent
• マルチモニター対応 / プリンタ・ドライブリダイレクト（RDP）
• 帯域に応じた画質自動調整

優先度は会員フィードバックで決めるつもりです。

β としてどう運用していくか

私の側で想定している運用ルールは次の 3 点です。

1. 招待は手動承認。一度に大量に受け入れず、状況を見ながら少人数ずつ増やす
2. 障害・停止は会員ポータルで告知。ブログ記事にも事後レポートを書く
3. フィードバックを記事化する。β 期間中に出た議論や改善は、そのままブログの材料にさせてもらう（機微情報は当然マスキングします）

会員コミュニティ側でもお願いしたいことがあります。

• 自分が所有・管理権限を持つサーバーにのみ接続してください（第三者所有の機器には無許諾接続しないこと）
• 本機能が停止した場合の代替経路を確保してください
• 触っていて挙動が怪しかったらフィードバックをください

特に最後の 1 行が重要で、β 版のうちに出てくるバグや設計ミスを早めに拾いたい、というのが公開の主目的の一つです。

申請方法

会員ポータルの「会員特典」ページに Simple ZTA β の案内を追加しています。参加希望の方は、そこから申請フォームを送信してください。手動承認のため、返信まで数日いただくことがあります。

まだ会員でない方は、会員プラン のスタンダードプラン以上をご検討ください。Simple ZTA は追加料金 0 円の実験的付録なので、スタンダードプラン月額 980 円だけで利用対象になります。

おわりに

個人が自宅で ZTA を作って、それを会員特典として公開する、という前例のない試みです。正直なところ、運用していく中で予想しなかった問題が出てくるはずで、それを β の期間中に拾って修正していくのが目的そのものでもあります。

「読む」ブログから「見る」会員 Grafana へ、そして「触る」Simple ZTA へ。段階的に体験を足していく中で、会員の皆さんと一緒に作っていくような形にしたいと考えています。

フィードバックはブログのお問い合わせ、または会員ポータル経由でお待ちしています。

関連リンク

• Simple ZTA 利用特約（ドラフト）
• 会員プラン
• 技術ブログの有料化：無料記事と有料コンテンツの線引きをどう設計したか

自宅サーバ運用の全体像は 自宅サーバ運用の完全ガイド — Proxmox + Cloudflare Tunnel + Docker で個人ブログを公開し続ける にまとめています。Proxmox クラスタ・公開経路・Docker 本番化・障害対応までを 1 ページで通読できる Pillar ガイドです。