セキュリティ設計

設計判断: 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）、データ漏洩

example.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

example.com {
    basicauth {
        deployer $HASHED_PASSWORD
    }
}

設計判断:

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

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

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

設計判断:

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

アーキテクチャ図

環境別セキュリティ比較

VPSとローカルPCでは、脅威モデルが異なるため異なるセキュリティ構成を採用しています。

脅威モデルの違い

ローカルPCのセキュリティ構成

ローカルPCはインターネットに公開されていないため、4層防御のうちレイヤー1〜3は不要です。

ローカルネットワーク / Tailscale VPN
    |
    v
[SSH] 鍵認証（パスワード認証無効）
    |
    v
[ネットワーク分離] 127.0.0.1 バインド
    |
    v
[OpenClaw Gateway] Token認証

使用技術スタック