セキュリティ設計ポートフォリオ

OpenClaw Stack のセキュリティ設計における技術的判断と実装内容をまとめたポートフォリオ文書。 Defense in Depth（多層防御）の実践例として参照可能。

プロジェクト概要

項目 内容
プロジェクト名 OpenClaw Stack
概要 AIエージェントプラットフォーム（OpenClaw）をVPS上で安全にホストするインフラ構成
要件 外部からのAIエージェントへの不正アクセスを防止しつつ、正規ユーザーはどこからでも利用可能
脅威モデル ポートスキャン、通信傍受、URL漏洩、認証突破、デバイス乗っ取り

設計判断: Defense in Depth（多層防御）

AIエージェントはユーザーの権限で動作するため、乗っ取られると重大な被害が発生する：

  • 勝手なメール送信・SNS投稿
  • ファイルの読み取り・削除
  • 外部APIの不正呼び出し（決済を含む）
  • 機密情報の漏洩

単一のセキュリティ対策では不十分であり、各層が独立して機能する多重防御を採用した。

実装した4層防御

レイヤー1: ネットワーク層（UFW ファイアウォール）

脅威: ポートスキャンによるサービス発見、直接攻撃

実装:

# UFW ルール
ufw default deny incoming
ufw allow 80/tcp      # HTTP（Caddy用）
ufw allow 443/tcp     # HTTPS（Caddy用）
ufw limit 22/tcp      # SSH（レート制限付き）
ufw deny 18789        # Gateway ポート（明示的拒否）

設計判断:

  • Gateway（18789）をループバック（127.0.0.1）のみにバインド
  • 外部からの直接アクセスをネットワーク層で遮断
  • Dockerのポートマッピングも 127.0.0.1:18789:18789 で内部のみ

レイヤー2: トランスポート層（TLS/HTTPS暗号化）

脅威: 通信傍受、中間者攻撃（MITM）、データ漏洩

実装:

fopenclaw.com {
    encode gzip
    # CaddyがLet's Encryptから自動で証明書を取得・更新
    # 明示的なTLS設定不要（Auto HTTPS）
}

設計判断:

  • リバースプロキシにCaddyを採用（Auto HTTPSで運用コストゼロ）
  • Let’s Encryptによる無料証明書を自動取得・自動更新
  • HTTP→HTTPSリダイレクトもCaddyが自動処理

レイヤー3: アプリケーション層（HTTP BasicAuth）

脅威: URL漏洩による不正アクセス

実装:

# パスワードハッシュの生成
echo "$PASSWORD" | docker run -i --rm caddy:2 hash-password

fopenclaw.com {
    basicauth {
        deployer $HASHED_PASSWORD
    }
}

設計判断:

  • アプリケーションレベルでのアクセス制御
  • CaddyのBasicAuth機能を使用（追加ミドルウェア不要）
  • パスワードはbcryptハッシュで保存

レイヤー4: サービス層（Gateway Token + デバイスペアリング）

脅威: 認証突破後の不正操作、端末の乗っ取り

実装:

{
  "gateway": {
    "auth": {
      "mode": "token",
      "token": "${GATEWAY_TOKEN}"
    }
  },
  "plugins": {
    "device-pair": {
      "config": {
        "publicUrl": "https://fopenclaw.com"
      }
    }
  }
}

設計判断:

  • トークンベース認証（環境変数で管理、Gitには含めない）
  • デバイスペアリングで許可された端末のみ接続可能
  • トークンの定期ローテーションを推奨

アーキテクチャ図 

インターネット
    |
    v
[UFW] ポート80/443のみ許可（レイヤー1）
    |
    v
[Caddy] TLS終端 + Auto HTTPS（レイヤー2）
    |
    v
[Caddy] BasicAuth認証（レイヤー3）
    |
    v
[Docker Network] openclaw-net (172.30.0.0/24)
    |
    v
[OpenClaw Gateway] Token + デバイスペアリング（レイヤー4）
    |
    v
[LLM API] openai/gpt-5.1-codex

環境別セキュリティ比較

本プロジェクトでは、脅威モデルの違いからVPSとローカルPCで異なるセキュリティ構成を採用している。

比較表

セキュリティ層 VPS（フクロウ） ローカルPC（よつば）
UFW ファイアウォール あり（80/443のみ公開） 不要（ローカルネットのみ）
TLS/HTTPS あり（Caddy Auto HTTPS） 不要（Caddyなし、ローカル通信のみ）
HTTP BasicAuth あり（Caddy経由） 不要（Caddyなし）
Gateway Token あり あり
デバイスペアリング あり 設定可能（未使用）

脅威モデルの違い

項目 VPS（フクロウ） ローカルPC（よつば）
公開状態 インターネット全体に公開 ローカルネットワーク内のみ
IPアドレス グローバルIP（誰でもアクセス可能） プライベートIP（192.168.1.x）
攻撃対象範囲 全世界からの攻撃が届く 同じネットワーク内の人のみ
想定攻撃者 不特定多数の外部攻撃者 同一ネットワーク内の侵入者

ローカルPC（よつば）のセキュリティ構成

ローカルPCはインターネットに公開されていないため、4層防御のうちレイヤー1〜3は不要。 代わりに以下の構成で保護している：

ローカルネットワーク / Tailscale VPN
    |
    v
[SSH] 鍵認証（パスワード認証無効）
    |
    v
[ネットワーク分離] 127.0.0.1 バインド（外部から直接アクセス不可）
    |
    v
[OpenClaw Gateway] Token認証
セキュリティ手段 内容
ネットワーク分離 プライベートIP（192.168.1.x）＋127.0.0.1バインド。ルーター外からは到達不能
SSH鍵認証 パスワード認証を無効化、公開鍵認証のみ許可
Tailscale VPN 外出先からのアクセスは暗号化トンネル経由のみ。Tailscale IPでのみ接続可能
Gateway Token OpenClaw独自のトークン認証。環境変数で管理

設計判断の根拠

「脅威モデルに合わせて適切な対策を選ぶ」 という方針。

VPSはインターネットに面しているため、多層防御で外部からの攻撃を各層で段階的に阻止する必要がある。一方、ローカルPCは物理的に隔離されており、攻撃者が到達する前提が異なる。同じ4層を適用するのは過剰であり、運用コスト（証明書管理・パスワード管理）が増えるだけ。

代わりにローカルPCでは、ネットワーク分離（そもそも到達させない） を主軸とし、到達された場合の最終防衛線としてGateway Tokenを配置している。

運用上の考慮事項

項目 対応
証明書更新 Caddyが自動更新（手動対応不要）
パスワード変更 Caddyのhash-passwordで再生成 → Caddyfile更新 → reload
トークンローテーション .envのGATEWAY_TOKEN変更 → コンテナ再起動
ログ監視 Caddyアクセスログ + healthcheck.shで定期確認
インシデント対応 トークン無効化 → コンテナ停止 → 原因調査 → 再構築

使用技術スタック

技術 用途 選定理由
UFW ホストファイアウォール Ubuntu標準、シンプルなルール定義
Caddy リバースプロキシ + TLS終端 Auto HTTPS（Let’s Encrypt自動管理）、設定ファイルが最小
Docker Compose コンテナオーケストレーション ネットワーク分離、ポートマッピング制御
OpenClaw AIエージェントプラットフォーム Token認証 + デバイスペアリング機能が内蔵

参考文献

作成日: 2026-04-17 更新日: 2026-04-17（環境別セキュリティ比較セクション追加）

This site uses Just the Docs, a documentation theme for Jekyll.