デプロイ前置きチェック（Node バージョンと権限モデル）
OpenClaw CLI は Node の下限・推奨に敏感です。ジョブや plist の先頭で node -v と which openclaw を必ずログに残し、fnm／nvm でメジャーを固定してください。リモート Mac では「誰のユーザで動くか」がセキュリティ境界になります。ゲートウェイを専用ローカルユーザー（例：_openclaw 相当の非ログインユーザ）で動かし、~/Library/LaunchAgents ではなく必要なら /Library/LaunchDaemons でシステム起動時に上げる構成も検討しますが、その場合は書き込み先をそのユーザのホーム配下に閉じることで権限昇格リスクを下げます。
# ランタイムとバイナリの実体確認（再現性とサプライチェーンの第一歩） node -v which node which openclaw openclaw --version # リッスン確認：意図しない 0.0.0.0 が無いか lsof -iTCP -sTCP:LISTEN -n -P | egrep 'node|openclaw|LISTEN'
macOS の「フルディスクアクセス」や「開発者ツール」ポップアップが出る場合、自動化ユーザーに過剰権限を与えず、必要最小の TCC プロファイルだけを許可する方針に寄せてください。
ゲートウェイトークンとアクセス制御の設定手順
バインド：既定は 127.0.0.1。外向き公開が必要でも 0.0.0.0 裸は避け、手前に SSH ローカルフォワード またはリバースプロキシで TLS 終端と IP 制限を挟みます。
トークン：openssl rand -hex 32 相当の長さを下限にし、環境変数（例：OPENCLAW_GATEWAY_TOKEN）で渡す。リポジトリの openclaw.json にはプレースホルダのみ書き、実値はデプロイ時注入。
クライアント：CI から叩く場合は Authorization: Bearer … またはドキュメント指定ヘッダを固定し、マスク漏れを防ぐためログレベルを一段下げたうえでレスポンス本文を出さない。
ローテーション：月次またはインシデント時にトークンを二系統（新旧）並走→切替→失効の三段で回します。
# トークン生成例（シェル履歴に残さないこと） openssl rand -base64 48 | tr -d '\n' | pbcopy # launchd EnvironmentVariables に貼り付け、plist は chmod 600 # ローカル疎通（ヘッダ名は利用中の OpenClaw 版に合わせて置換） curl -sS -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \ http://127.0.0.1:<PORT>/health
openclaw.json 側では、ゲートウェイの listen アドレス・認証モード・許可オリジン（利用バージョンが対応している場合）を宣言し、Git に秘密を載せないことを pre-commit で機械的に弾くと再現性が上がります。
外向きドメイン許可リストとプロキシ戦略（出站ポリシー）
エージェント型ランタイムの事故は「想定外 URL への二次リクエスト」に集約されがちです。組織の外向き（出站）ファイアウォールまたはホストベース制御と表を突合し、443 の許可先を列挙します。最低限よく必要になるのは次のカテゴリです（正式ホスト名は利用中プロバイダに置換）。
| カテゴリ | 例（プレースホルダ） | メモ |
|---|---|---|
| モデル／推論 API | api.*.com | レート制限と課金キーのスコープを最小化 |
| パッケージ／スキル取得 | npm／ClawHub／Git ホスト | ミラー URL に変えたら allowlist も同期 |
| 時刻・証明書 | NTP、OCSP／CRL | TLS 失敗の隠れ原因になりやすい |
| メタデータ悪用対策 | 169.254.169.254 等 | 明示的に拒否ルールへ |
# プロキシ配下での典型（社内直結を NO_PROXY に列挙）
export HTTPS_PROXY=http://proxy.internal:8080
export NO_PROXY=localhost,127.0.0.1,.internal.corp,git.corp.example
# 出站の手動検証（段階的）
curl -sS -o /dev/null -w '%{http_code}\n' https://api.example.com/v1/models
nc -vz proxy.internal 8080
リモート Mac が固定出口 IPを持つレンタル環境であれば、API 側の IP 許可リストと組み合わせやすく、トークン漏洩時のダメージも限定しやすくなります。
ログ監査とアラート閾値
ゲートウェイの stdout／ファイルを logrotate 相当（macOS なら newsyslog または外部エージェント）でローテートし、JSON 一行ログ化できるなら集約基盤へ送ります。初期閾値の目安は次のとおりです（ベースライン取得後に調整）。
- 5 分窓で HTTP 401／403 が直近 24h 中央値の 3 倍以上
- 同一ソース IP からの連続失敗 20 回／10 分（ブルートフォース兆候）
- プロセスが 短期に 3 回以上異常終了（OOM／未捕捉例外のサイン）
# 例：ゲートウェイログから認証失敗を抽出（パスは環境に合わせる） grep -E '401|403|Unauthorized|invalid token' /var/log/openclaw/gateway.log | tail -n 200 # launchd の終了コード確認 launchctl print gui/$(id -u)/com.example.openclaw.gateway | head -n 80
よくあるエラー切り分け（ポート・TLS・権限）
| 症状／メッセージ | 優先確認 | 対処コマンド／設定 |
|---|---|---|
EADDRINUSE | 二重起動・ゾンビ | lsof -i :<PORT> → 片方を停止、plist の ThrottleInterval 調整 |
certificate verify failed | プロキシ MITM・時刻・中間証明書 | openssl s_client -connect host:443 -servername host -showcerts、NTP 同期確認 |
EACCES／ログ書き込み不可 | ディレクトリ所有者 | ログパスを実行ユーザ配下へ、chown と chmod 750 |
| 外から届かない | 意図した閉じ方か | まず 127.0.0.1 上で curl 成功を確認のうえ SSH -L で転送 |
公開前セキュリティチェック表
- 無認証の
0.0.0.0公開が残っていない - トークンがリポジトリ・バックアップ・スクリーンショットに無い
- 外向き allowlist と
NO_PROXYが表と一致 - 401 急増・再起動ループのアラートが有効
- 依存とスキルの更新経路が監査ログに残る
セキュリティ FAQ（要約）
構造化データ（FAQPage）と同内容の要約です。詳細は各 H2 を参照してください。
- なぜ裸公開が危険か：スキャン＋短い秘密でエージェント API が悪用される事例が 2025〜2026 年報告されている。
- トークン保管：launchd 環境変数＋ファイル権限、CI はマスク。
- 外向き通信（出站）：モデル／Git／レジストリ／OCSP を列挙し、メタデータ IP は拒否。
- TLS：
openssl s_clientと時刻・プロキシを先に疑う。
まとめ・選型と購入の導線
本番露出面は「公開範囲 × 秘密の置き場所 × 出站の広さ × ログの可観測性」の掛け算で決まります。OpenClaw ゲートウェイはリモート Mac 上でこの四つを同時に満たすと、2025〜2026 年型のスキャン・トークン流出・横展開リスクを現実的に下げられます。関連手順は MCP プリフライト、Docker デプロイ、Kilo ゲートウェイ構成 と併読してください。
自前 Mac の調達・常時電源・出口 IP の安定に時間を割きたくない場合は、料金ページでスペックと期間を比較し、購入からプランを確定するのが早いです。ホームの製品概要と、運用質問は ヘルプセンターを参照してください。
選型の軸は「CI 同時実行数」「外向き API の数」「ログ保管期間」の三点です。要件がはっきりしないうちは小さく始め、allowlist とトークンローテーションだけでも運用を固めてからスケールするのが安全です。