脅威モデルと原則
脅威は「不正ログイン」「ログ／バックアップ漏えい」「1 ノードからの横展開」「端末に残った .env」が典型です。原則：リポに秘密を置かない／役割ごとに鍵を分ける／マウント範囲を最小化／ローテーションは手順書＋演習で実施。
よくある誤り
- 「とりあえず管理者用トークンを全エージェントに」→ 1 台侵害でクラスター全体が終了。
- ログに環境変数ダンプを有効のまま → シークレットが永続化ストレージに残る。
ディレクトリと環境変数のレイアウト
操作手順：① /var/lib/openclaw/secrets/<node-id>/ をノード専用にし所有者をサービスユーザーに。② 秘密はファイル化し 600。③ 環境変数はパス参照（例：*_FILE）。④ launchd／systemd の Unit のみに載せ、.zshrc に書かない。Ansible 等はテンプレとパスだけ配布し、中身はマネージャー／SOPS／手動で投入。
よくある誤り
- リポジトリ内の
.env.productionを全ノードに rsync → 履歴とバックアップに残りやすい。 - 共有 NFS に全秘密を一括マウント → 侵害時の爆心地になる。
ノード間で異なるクレデンシャル範囲
MeshMac 多ノードでは API Key を役割ごとに物理分離します。表を台帳の雛形にしてください。
| ノード役割 | 載せる秘密の例 | 載せないもの |
|---|---|---|
| ビルドワーカー | CI 読み取りトークン、社内レジストリ認証 | 本番クラウドのフル権限、Webhook 署名マスター |
| Webhook／ゲートウェイ | 受信 HMAC 秘密、レート制限用サルト | 長期 SSH 鍵、データベース管理者パスワード |
| 状態／キュー集中 | キュー DB 接続（最小権限ユーザー） | 他ノードのビルド用トークン |
台帳に沿って必要ファイルだけ配置し、YAML は全台一括配布せずノード変数で秘密パスだけ差し替えます。
よくある誤り
- 「設定を揃える」＝「秘密も同一」だと誤解 → 揃えるのはバージョンと構造だけ。
- 通知用とビルド用で同一ベアラトークン → 通知経路が破られるとビルドまで連鎖。
ローテーションと緊急失効
計画：新旧キーを 24～72h 並行有効 → ノードをローリングで差し替え＆デーモン再起動 → 旧キー失効 → 台帳に日付記録。緊急：高権限キーからコンソール失効 → launchctl／systemctl でプロセス掃除 → ログ等の漏えい経路を塞ぐ。
よくある誤り
- ファイルだけ差し替えてデーモン未再起動 → プロセスが古いキーを保持し続ける。
- ローテーションを「年1回の大工事」にし、演習なし → 本番で手順が破綻。
監査とトラブルシュート FAQ
監査：ログはキー ID・ノード ID・成否・相関 ID のみ。台帳変更は Git／チケットで追跡。四半期に find で不要ファイルを棚卸し。
FAQ
- 401 が一部ノードだけ → そのノードの秘密ファイルの更新漏れか、パーミッションでデーモンが読めていない。
- ローテーション直後だけ不安定 → オーバーラップ期間を短くしすぎたか、下流キャッシュが古いキーを保持。
- 最小権限で足りない → 台帳の「必要スコープ」を見直し、別キーで分割する（権限を広げる前の最終手段）。
まとめ
OpenClaw と MeshMac 多ノードでは、設定の統一とシークレット管理の分離を同時に満たすことが重要です。最小権限でマウントし、キーローテーションと緊急失効を手順化すれば、自動化チームでも再現性の高いセキュリティ運用になります。実ノードは MeshMac ホームからログイン不要で料金確認・申込へ進められます。