OpenClaw API Key 設定の落とし穴（実務安全管理編）
OpenClaw は強力な AI スキルを動かすために、OpenAI や Gemini、GitHub などの API キーを使用します。管理を誤ると「高額請求」や「データ漏洩」に直結します。本ガイドでは、実務で必須の安全管理術を解説します。
1. 権限の最小化原則（Least Privilege）
API キーを発行する際、安易に「Full Access（全権限）」を与えてはいけません。
サービス別推奨権限表
| サービス | 推奨スコープ / 権限 | 理由 |
|---|---|---|
| GitHub | repo (Read/Write), workflow |
ソースコードの読み書きに限定 |
| Google Cloud | Gmail.send, Calendar.read |
必要なアプリの権限のみを個別に許可 |
| AWS / Azure | 特定の S3 バケットのみの読み書き | インフラ全体の操作を禁止 |
2. 設定時の致命的な失敗例
- GitHub へ
.envをコミットする: ツールが自動でスキャンしており、数秒でキーが盗まれます。 - チャット欄にキーを貼り付ける: ログに残るため、後の共有で漏洩するリスクがあります。
- 有効期限を設定しない: 万が一漏洩した際、被害が永続します。
3. 安全な設定手順
方法 A: 環境変数を使用する（推奨）
設定ファイルに直接書き込まず、OS の環境変数から読み込ませます。
# ~/.zshenv 等に記述
export OPENAI_API_KEY="sk-..."
方法 B: OpenClaw Config の暗号化
openclaw config set を使用し、ツール側の管理機能を利用します。平文でメモ帳などに残さないでください。
4. 漏洩が疑われる時の対応フロー (IR)
- キーの即時失効: 各サービスの管理画面から該当のキーを「Revoke（削除）」します。
- 利用履歴の確認: 不正な API 呼び出しや高額な請求が発生していないか確認。
- 新キーの発行と環境変数の更新: セキュリティ設定を見直した上で、新しいキーを再設定。
5. KPI（安全指標）
- キー更新頻度: 90日ごとにローテーションされているか。
- 権限不備の数: 定期監査で Full Access のキーがゼロであること。