openclaw-secure-linux-cloud

概要

クラウドサーバー上の OpenClaw に対する「デプロイ第一、公開は後から」という保守的なパターンに使用します。

デフォルトではプライベートなコントロールプレーンを採用します：

• Linux ホストを何も公開する前にまずハードニングします。
• ゲートウェイを 127.0.0.1 にバインドしたままにします。
• SSH トンネルを通してはじめて Control UI に到達します。
• トークン認証、ペアリング、サンドボックス機能を有効なままにします。
• 狭いツールプロファイルから始め、明確な必要性がある場合にのみ拡張します。

このスキルはセキュアな Linux クラウドホスティング用です。ユーザーがローカルマシン上の OpenClaw をもっともすばやくインストールしたいだけであれば、このフローを強制するのではなく、公式の OpenClaw オンボーディングドキュメントを優先してください。

コマンドマトリックス、ベースライン設定の形状、チェックリスト、アクセスパスの比較が必要な場合は、references/REFERENCE.md を開いてください。

使用時期

ユーザーが以下のいずれかを言及する場合は、このスキルを使用します：

• クラウドサーバー、VM、またはその他の Linux ホスト上の OpenClaw
• セキュアなセルフホスティング、ハードニング、または「プライベートに実行する」
• Podman、ループバックバインディング、SSH トンネル、またはリモート Control UI アクセス
• OpenClaw に対する Tailscale と逆プロキシの比較
• ペアリング、サンドボックス機能、トークン認証、またはロックダウンされたツール権限
• 既存の OpenClaw ホストが過度に公開されていないかの確認

このスキルを使用しないでください：

• OpenClaw コンポーネントがない汎用 Linux ハードニング
• リモートアクセスが無関係なローカル単一マシンのオンボーディング
• リモートホストハードニングの質問がない純粋なローカルオンボーディング
• ユーザーが明示的にこの Linux ファーストパターンを適用させたいもの以外の非 Linux ホスティング

ワークフロー

1. リクエストを分類する

詳細なガイダンスを提供する前に、タスクを以下のいずれかのカテゴリに分けます：

1. フレッシュデプロイ：ユーザーが Linux クラウドホスト上にセキュアに OpenClaw を新規構築したい。
2. ハードニングレビュー：ユーザーが既に OpenClaw を実行しており、公開範囲を削減したり危険なデフォルトを監査したい。
3. アクセスモデルの決定：ユーザーが SSH トンネル、Tailscale、または逆プロキシのいずれかを選択している。

2. セキュアなベースラインから開始する

ユーザーが明確に別のものを要求しない限り、以下のベースラインを推奨します：

• Linux ホストをまずハードニングする：アップデート、SSH キー、SSH ロックダウン、およびディストロに合わせたデフォルト拒否インバウンドファイアウォール。
• ルート所有の長寿命プロセスではなく、ルートレス Podman の下で OpenClaw を実行します。
• ゲートウェイをループバックのみに保つ。
• Control UI をプライベートに保ち、SSH トンネルを通してアクセスします。
• トークン認証を要求する。
• インバウンドメッセージングチャネル用にペアリングを有効に保つ。
• 最小限のツールセットで始め、デフォルトではセッションをサンドボックス化します。

これらを明白な危険信号として扱ってください：

• ゲートウェイを 0.0.0.0 にバインドする
• ポート 18789 をパブリックインターネットに公開する
• デフォルトで広いランタイム、ファイルシステム、自動化、またはブラウザアクセスをオンにする
• ~/.openclaw を他のローカルユーザーから読み取れるままにする

3. ローカルアクションとサーバーアクションを分離する

常に以下を区別します：

• ローカルマシンアクション：SSH キー生成、トンネルセットアップ、ブラウザアクセス
• サーバーアクション：Linux ハードニング、Podman インストールパス、OpenClaw サービスセットアップ、設定権限、サービス再起動

2 つの実行コンテキストを混同しないでください。ユーザーは、どのコマンドがラップトップで実行され、どのコマンドが Linux ホストで実行されるかを判断できる必要があります。

4. ブロッキングファクトのみを質問する

セキュアパスを変える、以下のような欠けている事実に対してのみ停止します：

• パッケージマネージャーまたはファイアウォールコマンドが重要な場合の Linux ディストロとホストアクセスの詳細
• OpenClaw がすでにインストールされているかどうか
• ユーザーが本当にリモートプライベートアクセスの繰り返しまたはパブリックアクセスを必要としているかどうか
• 既存のデプロイメントがすでにインターネットから到達可能かどうか

詳細がセキュリティ上重要でなければ、合理的でセキュアな仮定をして、それを述べてください。

5. アクセスエスカレーションラダーを使用する

この順序でリモートアクセスを推奨します：

1. SSH トンネル：初期デプロイと個人使用のデフォルト
2. Tailscale：ユーザーが信頼できるデバイス間でリモートプライベートアクセスを繰り返し必要とする次のステップ
3. 逆プロキシ：ユーザーがパブリック公開を明示的に必要とし、追加のハードニング負担を受け入れるときのみ

ユーザーが Tailscale または逆プロキシを求める場合でも、ループバックバインディングとプライベートファースト モデルがベースラインのままである理由を説明します。

出力の期待値

フレッシュデプロイの場合は、以下を提供します：

• 簡潔なアーキテクチャサマリー
• ローカル対サーバーステップ
• 保守的な設定ベースライン
• プレローンチチェックリスト
• 「何を公開しないか」に関する簡潔な警告

ハードニングレビューの場合は、以下を提供します：

• 現在のセットアップの可能性のあるリスク
• 優先順位付けされた修復シーケンス
• 他に何かを行う前に修正すべき即座の公開懸念事項

アクセスパス決定の場合は、以下を提供します：

• 推奨事項
• それが最も低リスクのフィットである理由
• ユーザーがより広い公開モデルを選択する場合に必要な追加のセーフガード

よくある間違い

• OpenClaw を初日から通常のパブリック Web アプリケーションとして扱う
• 認証がネットワーク境界を置き換えると仮定する
• ユーザーがそれを必要とするクリアなワークフローを持つ前に、より多くのツール パワーをオンにする
• 初期セットアップ中に時間を節約するためだけにペアリングを無効にする
• 設定またはサンドボックス設定を変更した後のフォローアップ監査をスキップする

リファレンス使用方法

以下が必要な場合は、references/REFERENCE.md を使用します：

• クロスディストロハードニングフロー および Debian/Ubuntu サンプルコマンド
• Podman ベースの OpenClaw セットアップアウトライン
• ベースライン設定スケルトン
• プレローンチチェックリスト
• 日常的な監査コマンド
• SSH トンネル対 Tailscale 対逆プロキシの比較