BetterLink Logo 比隣
言語を切り替える
中文 English 日本語
テーマを切り替える

OpenClawセキュリティ設定完全ガイド：Dockerサンドボックスから権限管理まで、5層の防御策

深夜3時、ある開発者がRedditに助けを求める投稿をしました。彼はMacBookにOpenClawをインストールし、デフォルト設定で2週間ほど快適に使っていました。ある日、OpenClawに「最近のプロジェクトファイルを整理して」と頼んだところ、AIはついでに~/.ssh/と~/.aws/ディレクトリを読み取り、返信の中で「親切にも」彼の秘密鍵の内容を表示してしまったのです。

さらに致命的だったのは、この会話ログが職場のグループチャットに同期されていたことでした。

正直なところ、この事例を初めて見たとき、背筋が凍る思いでした。OpenClawは超強力なAIアシスタントであり、シェルコマンドの実行、ファイルの読み書き、ブラウザの制御が可能です。しかしそれは同時に、設定を誤れば、家の鍵を持った見知らぬ人のような存在になることを意味します。

「自分だけで使うから大丈夫だろう」と思っていませんか？

ああ、問題はそこにあるのです。OpenClawのリスクは外部からの攻撃だけではありません。プロンプトインジェクション（チャット中に誰かがこっそり悪意ある指令を紛れ込ませる）、設定ミス（うっかりAPIポートを公開してしまう）、さらにはAI自身の「過剰な熱意」（ファイルをクリーンアップしてと頼んだら、重要データを削除してしまうなど）もあります。

これらは正しい設定を行えば防げたはずのものです。

この記事では、OpenClawに「セキュリティの檻」をかける方法を手取り足取り教えます。Dockerサンドボックス隔離からきめ細かな権限管理まで、5層の防御でこの「猛獣」を安心して使えるようにします。先に言っておきますが、設定は少し面倒に見えるかもしれません。しかし、データ漏洩やデータベース削除のリスクに比べれば、この程度の手間は取るに足りません。

なぜセキュリティ設定が必要なのか？

OpenClawの権限はどれほど強力か？

まず、身の引き締まるような事実をお話ししましょう。OpenClawはただチャットができるだけのAIアシスタントではありません。それができることは、基本的にあなたがターミナルでできるすべてのことと同じです。

  • 任意のシェルコマンド実行：rm -rf /？ 技術的には可能です。
  • 全ファイルシステムの読み書き：SSHキー、AWS認証情報、データベースのパスワードなど、ディスク上にあれば触れることができます。
  • ネットワークリソースへのアクセス：APIの呼び出し、ファイルのダウンロード、さらにはイントラネットのポートスキャンまで。
  • ブラウザ制御：Playwrightを通じてブラウザを操作でき、ログイン状態のWebサイトも含まれます。
  • 環境変数の読み取り：process.env内の機密情報が丸見えになります。

言い換えれば、OpenClawにデフォルトの権限を与えることは、「頭はいいがあまりよく知らないアシスタント」に家のマスターキーを渡すようなものです。

デフォルト設定はどれほど危険か？

多くの人が手軽さを求めて npm install -g openclaw でインストールし、そのまま openclaw run していることを知っています。しかし、デフォルト状態で何が起こるか知っていますか？

100%
ファイルシステムアクセス権限

v2026.1.29 以前：

  • アクセス制御を auth: none に設定できました。つまり、URLを知った人は誰でもあなたのOpenClawを制御できました。
  • サンドボックス隔離なし。AIは全ファイルシステムを読み書き可能。
  • 危険な exec や browser を含むすべてのツールがデフォルトで有効。
  • 高権限（rootの場合さえある）で実行される可能性。

"v2026.1.29でauth: noneオプションが強制的に削除され、トークンまたはパスワード認証が必須になりました"

v2026.1.29 以降は少しマシになりました：公式が auth: none オプションを強制削除し、トークンまたはパスワード認証が必須になりました。しかし、サンドボックス、ツール権限、ファイルシステムアクセスなどの問題は依然として存在し、手動で設定する必要があります。

正直なところ、デフォルト設定は家のドアを開け放って寝るようなもので、さらにドアの前に「ご自由にお入りください」という看板を立てているようなものです。

セキュリティ設定の3つの目標

これほど多くの設定をするのは、一体何のためでしょうか？核心は3点です：

1. 最小権限の原則：OpenClawに本当に必要な権限だけを与え、それ以外は一切与えないこと。コードを書かせるならworkspaceの読み書き権限を与えれば十分です。ブラウザ操作が不要なら、browserツールは無効化すべきです。

2. 多層防御：すべての希望を一つの防衛線に託さないこと。Docker隔離、非特権ユーザー、アクセス制御、ツールホワイトリスト、ネットワーク分離——5層の防御があれば、いずれか一層が突破されても、他の層がカバーできます。

3. 制御可能な爆発半径：最悪の事態（プロンプトインジェクション成功、トークン漏洩、あるいはAI自体のバグ）が発生したと仮定して、被害をどこまで抑えられるか？ もしOpenClawが隔離されたworkspaceディレクトリしかアクセスできなければ、漏洩するのはそのディレクトリの内容だけで、/homeディレクトリ全体ではありません。

要するに、セキュリティ設定は攻撃を防ぐため（それは不可能です）ではなく、攻撃のコストを十分に高くし、被害を十分に小さくするためにあるのです。

5層のセキュリティ設定

さて、前置きはこれくらいにして実践に入りましょう。下層から上層への順序で、5層の防御設定を解説します。各層で「なぜそうするのか」と「設定成功の検証方法」をお伝えします。

第1層：Dockerサンドボックス隔離（必須レベル）

なぜDockerを使うのか？

多くの人がDockerを単なるデプロイの手軽さのためだと思っています。違います。OpenClawのような高権限アプリケーションにとって、Dockerの最大の価値は隔離です：

  • ファイルシステム隔離：AIはコンテナ内のファイルしか見えません。ホストマシンの ~/.ssh には触れられません。
  • ネットワーク隔離：コンテナの外部ネットワークアクセスを切断したり、特定のドメインのみ許可したりできます。
  • リソース制限：AIが無限ループを実行してCPUを焼き尽くすのを防ぎます。
  • 迅速な復元：問題が起きた？ docker rm でコンテナを消して、数秒でクリーンな環境を再構築できます。

「ローカルの開発マシンで動かすだけなのに、そんなに面倒なことが必要なの？」と聞かれることがあります。

必要です。ローカルこそ危険なのです——あなたの開発マシンにはGitHubトークン、データベースパスワード、各種APIキーがあり、これらはすべてプロンプトインジェクション攻撃の標的です。

設定手順

1. 安全なDockerfileの作成

FROM openclaw/gateway:latest

# 非特権ユーザーを作成
RUN adduser --disabled-password --gecos '' clawuser

# 非特権ユーザーに切り替え
USER clawuser

# 作業ディレクトリを設定
WORKDIR /home/clawuser/openclaw

ここでのポイントは USER clawuser です。デフォルトのDockerコンテナはrootで実行され、これはコンテナ内のOpenClawがroot権限を持つことを意味します。専用ユーザーを作成すれば、仮に誰かがコンテナを突破しても、それはただの clawuser 権限に過ぎません。

2. Docker Composeで安全パラメータを設定

ここが核心部分です。一行ずつ解説します：

version: '3.8'
services:
  openclaw-gateway:
    build: .
    container_name: openclaw-safe

    # セキュリティ設定
    security_opt:
      - no-new-privileges:true  # コンテナ内プロセスの権限昇格を防止
    cap_drop:
      - ALL  # すべてのLinux capabilitiesを削除
    cap_add:
      - NET_BIND_SERVICE  # ポートバインド能力のみ追加

    # ルートファイルシステムの読み取り専用化
    read_only: true

    # 一時ディレクトリ（書き込み可能）
    tmpfs:
      - /tmp
      - /home/clawuser/openclaw/temp

    # リソース制限
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G
        reservations:
          cpus: '1.0'
          memory: 2G

    # ネットワーク分離
    networks:
      - openclaw-isolated

    # ボリュームマウント（最小権限）
    volumes:
      # 作業ディレクトリ（読み書き）
      - ./workspace:/home/clawuser/workspace
      # 設定ファイル（読み取り専用）
      - ./config:/home/clawuser/openclaw/config:ro
      # ログディレクトリ（書き込み専用）
      - ./logs:/home/clawuser/openclaw/logs

networks:
  openclaw-isolated:
    driver: bridge
    internal: true  # 外部ネットワークへのアクセスを禁止

なぜこのように設定するのか？

  • no-new-privileges:true：sudo や setuid による権限昇格を防ぎます。攻撃者がコンテナ内で脆弱性を見つけても、より高い権限を得ることはできません。
  • cap_drop: ALL：Linuxのcapabilitiesはきめ細かな権限制御です。すべて削除してから必要なものだけ（ポートバインドなど）を追加することで、攻撃面を最小化します。
  • read_only: true：ルートファイルシステムを読み取り専用にします。攻撃者が侵入しても、バックドアの設置やシステムファイルの改ざんができません。書き込みが必要な場所（/tmpなど）は tmpfs でマウントします。
  • internal: true：コンテナは外部ネットワークにアクセスできません。OpenClawがネット接続を必要としない場合（ローカルファイル処理のみなど）、この設定でデータ漏洩を防げます。

3. OpenClawのsandboxモードを有効化

config/config.yaml にて：

sandbox:
  mode: "non-main"  # すべてのグループチャットは隔離コンテナ内で実行
  docker:
    enabled: true
    network: "none"  # サンドボックスコンテナのネットワークアクセスを無効化

これはOpenClaw自体のサンドボックス機能です。mode: "non-main" は、メインのチャットウィンドウ以外のすべての対話が独立したDockerコンテナ内で実行されることを意味します。これにより、ある対話がプロンプトインジェクション攻撃を受けても、その小さなサンドボックス内で暴れることしかできません。

検証方法

設定してすぐに使い始める前に、まず検証しましょう：

# コンテナが非rootユーザーで実行されているか確認
docker exec openclaw-safe whoami
# 返り値：clawuser

# ファイルシステムが読み取り専用か確認
docker exec openclaw-safe touch /test.txt
# 返り値：Read-only file system

# ネットワーク分離の確認
docker exec openclaw-safe ping 8.8.8.8
# 返り値：Network is unreachable

これら3つのテストすべてにパスしたら、おめでとうございます。第1層の防御は完了です。

第2層：非特権ユーザーでの実行（必須レベル）

Dockerコンテナ内では非rootを使っていますが、コンテナを起動するのは誰でしょうか？ホストマシン上でrootで docker-compose up を実行していると、攻撃者がコンテナから脱出した場合、やはりroot権限を取られてしまいます。

解決策：専用の低権限ユーザーを作成する

ホストマシン上での設定：

# 専用ユーザーグループとユーザーの作成
sudo groupadd -r openclaw
sudo useradd -r -g openclaw -d /opt/openclaw -s /bin/bash clawuser

# ディレクトリ構造の作成
sudo mkdir -p /opt/openclaw/{workspace,config,logs,temp}

# ディレクトリ権限の設定
sudo chown -R clawuser:openclaw /opt/openclaw
sudo chmod 700 /opt/openclaw/config  # 設定ファイルディレクトリ（所有者のみ読み書き可）
sudo chmod 755 /opt/openclaw/workspace  # 作業ディレクトリ
sudo chmod 750 /opt/openclaw/logs  # ログディレクトリ

# ユーザー権限の制限
sudo usermod -L clawuser  # パスワードログインをロック、su切り替えのみ

なぜ chmod 700 なのか？

chmod 700 は、ファイルの所有者（clawuser）だけが読み書き実行でき、他の人は見ることもできないという意味です。設定ファイルにはトークンやパスワードが含まれている可能性があるため、厳重に守る必要があります。

認証情報ファイルの権限（超重要！）

OpenClawでWhatsAppなどのサービスに接続する場合、認証情報ファイルの権限には特に注意が必要です：

# 認証情報ファイルは600（所有者のみ読み書き可）でなければなりません
chmod 600 ~/.openclaw/credentials/whatsapp/*/creds.json
chmod 700 ~/.openclaw

認証情報ファイルを644（全員読み取り可）に設定してしまい、同じサーバーの他のユーザーに盗み見られたケースを見たことがあります。このような初歩的なミスは絶対に避けてください。

検証

# OpenClawプロセスのユーザーを確認
ps aux | grep openclaw
# rootではなくclawuserと表示されるべき

# ファイル権限を確認
ls -la /opt/openclaw/config
# drwx------ clawuser openclaw となるべき

なぜこの層が重要なのか？

最悪の事態を想定しましょう：攻撃者がDockerコンテナを突破し、OpenClawのサンドボックスを突破し、任意のコードを実行しました——それでも彼が持っているのは clawuser 権限だけです：

  • 他のユーザーのファイルにはアクセスできない
  • システムレベルのソフトウェアはインストールできない（sudo権限がない）
  • /etc 下のシステム設定は変更できない
  • /root ディレクトリは読めない

これが多層防御の意義です。一層が突破されても、次の層があなたを守り続けます。

第3層：アクセス制御と身元認証（必須レベル）

前2層は「OpenClawに何ができるか」を解決しましたが、この層は「誰がOpenClawを使えるか」を解決します。

v2026.1.29 重大変更

以前のOpenClawは auth: none（全く認証しない）を許可しており、これはまさに災難でした。幸い公式がついに目を覚まし、v2026.1.29でこのオプションを強制削除しました。現在はトークンまたはパスワード認証の設定が必須です。

Gatewayトークン認証の設定

トークン認証はパスワードのどこが良いのでしょうか？異なる人/アプリに異なるトークンを割り当て、各トークンに異なる権限を設定できる点です。あるトークンが漏洩したら？それだけを取り消せばよく、他のトークンには影響しません。

config/config.yaml にて：

gateway:
  # トークン認証を強制
  auth: token

  # トークン設定
  tokens:
    - name: "admin-token"
      value: "${OPENCLAW_ADMIN_TOKEN}"  # 環境変数から読み取り、ハードコード禁止！
      permissions:
        - "admin"  # 全権限
    
    - name: "readonly-token"
      value: "${OPENCLAW_READONLY_TOKEN}"
      permissions:
        - "chat"  # チャットのみ
        - "read"  # ファイル読み取りのみ
      # 注意：exec、browserなどの高リスク権限は含まない

安全なトークンの生成

123456 や mytoken のような弱いトークンは絶対に使わないでください。このコマンドで256ビットのランダムトークンを生成します：

# ランダムトークンを生成
openssl rand -base64 32

# 環境変数を設定（設定ファイルにハードコードしない！）
export OPENCLAW_ADMIN_TOKEN="生成されたトークン"
export OPENCLAW_READONLY_TOKEN="別のトークン"

なぜハードコードしてはいけないのですか？設定ファイルはGitにコミットされたり、ログシステムに記録されたり、クラウドにバックアップされたりする可能性があるからです。環境変数の方が比較的安全です。

アクセス制御ホワイトリスト

トークンは「誰がアクセスできるか」を解決しますが、それだけでは十分ではありません。特定のWhatsAppユーザーやグループだけにOpenClawを使わせたい場合もあるでしょう：

# DM（プライベートチャット）ポリシー
dmPolicy: allowlist  # ホワイトリストモード
allowFrom:
  - "user_id_1"  # これらのユーザーのみチャット可能
  - "user_id_2"

# グループポリシー
groupPolicy: allowlist
allowFrom:
  - "group_id_1"  # これらのグループのみ使用可能

# Mention gating（グループチャットでは @メンション のみに応答）
mentionGating: true

# 公開アクセスの禁止
publicAccess: false

mentionGating: true は特に有用です。想像してみてください。100人の仕事グループにOpenClawをデプロイした場合、これを有効にしないと、グループ内のすべてのメッセージをOpenClawが処理してしまいます（コストがかかるだけでなく、悪意あるプロンプト攻撃も受けやすくなります）。有効にすれば、@されたときだけ応答します。

検証

# 未認証アクセスのテスト（拒否されるべき）
curl -X POST http://localhost:3000/api/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# 返り値：401 Unauthorized

# 有効なトークンでのテスト
curl -X POST http://localhost:3000/api/chat \
  -H "Authorization: Bearer ${OPENCLAW_ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# 返り値：200 OK

なぜこの層が重要なのか？

アクセス制御がなければ、前段の隔離や権限制限はすべて無駄になります——攻撃者はAPI経由で直接侵入でき、Dockerや権限昇格を突破する必要すらありません。

この層は門番であり、入るべきでない人を外で阻止します。

第4層：ツール権限管理（推奨レベル）

現在OpenClawは檻の中に閉じ込められていますが、檻の中でまだ多くのツールを使えます。危険な道具をいくつか没収する時です。

問題：デフォルトですべてのツールが使用可能

OpenClawには数十のツールが付属しています：exec（シェルコマンド実行）、browser（ブラウザ制御）、write_file（ファイル書き込み）、web_fetch（Webページ取得）…これらはデフォルトですべて有効です。

しかし、本当にこれらすべてが必要ですか？OpenClawにコードを書かせたり調査させたりするだけなら、browser や exec は完全に無効化すべきです。

ツールホワイトリストの設定

tools:
  # 安全なツールのみ許可
  allowlist:
    - "read_file"      # ファイル読み取り
    - "write_file"     # ファイル書き込み（ディレクトリ限定）
    - "web_search"     # ネット検索
    - "git"            # Git操作
    # 注意：exec、browserなどの高リスクツールは含まない

  # 高リスクツールは明示的な許可が必要
  exec:
    enabled: false  # シェル実行をデフォルトで無効化

  browser:
    enabled: false  # ブラウザ制御を無効化

  web_fetch:
    enabled: true
    # ドメインホワイトリスト
    allowedDomains:
      - "github.com"
      - "api.anthropic.com"
      - "*.npmjs.com"

execを有効にする必要がある場合は、コマンドホワイトリストを使用

テスト実行やプロジェクトのビルドなど、どうしてもOpenClawにコマンドを実行させる必要がある場合もあります。その場合はホワイトリストを使います：

tools:
  exec:
    enabled: true
    sandbox: true  # サンドボックスで実行

    # ブラックリストよりホワイトリストが優れている
    allowCommands:
      - "git"
      - "npm"
      - "yarn"
      - "pytest"
      - "curl"

    # 危険コマンドブラックリスト（二重保険）
    denyCommands:
      - "rm -rf"
      - "sudo"
      - "chmod 777"
      - "dd if="
      - "mkfs"
      - "> /dev/sda"

なぜホワイトリストがブラックリストより優れているのでしょうか？攻撃手法は無限に変化するため、すべての危険なコマンドをリストアップすることは不可能だからです。しかし安全なコマンドは有限なので、それらをリストアップすればいいのです。

ファイルシステムアクセス制限

filesystem:
  # アクセス許可ディレクトリ
  allowedPaths:
    - "/home/clawuser/workspace"
    - "/home/clawuser/projects"

  # アクセス禁止ディレクトリ
  deniedPaths:
    - "/home/clawuser/.ssh"
    - "/home/clawuser/.aws"
    - "/home/clawuser/.config"
    - "/etc"
    - "/root"

  # デフォルト権限
  defaultPermission: "readonly"  # デフォルトで読み取り専用

  # 書き込み権限には明示的な付与が必要
  writablePaths:
    - "/home/clawuser/workspace/temp"

このように設定すれば、プロンプトインジェクションでOpenClawに「~/.ssh/id_rsa を読んで」と命令しても、拒否されます。

検証

OpenClawのチャット画面でテスト：

  • あなた：「sudo apt update を実行して」

    • OpenClawの返答：このコマンドは実行できません。セキュリティポリシーによりブロックされました。

  • あなた：「~/.ssh/id_rsa ファイルを読んで」

    • OpenClawの返答：Access denied

第5層：ネットワーク分離と監視（上級）

企業ユーザーであったり、機密データを扱っていたり、あるいは究極のセキュリティを目指す場合、この層が最後の砦となります。

ネットワーク分離：不要な接続を切断

先ほど internal: true でコンテナが外部ネットワークにアクセスできないようにしました。しかしOpenClawはClaude APIを呼び出す必要があります。どうすればいいでしょうか？

解決策：アウトバウンドトラフィックのプロキシ

OpenClawが特定のドメイン（例：api.anthropic.com）のみにアクセスできるようにし、他はすべて遮断します：

# docker-compose.yml
services:
  openclaw-gateway:
    environment:
      - HTTP_PROXY=http://allowlist-proxy:8080
      - HTTPS_PROXY=http://allowlist-proxy:8080
    networks:
      - openclaw-isolated

  allowlist-proxy:
    image: squid:latest
    volumes:
      - ./squid.conf:/etc/squid/squid.conf:ro
    networks:
      - openclaw-isolated
      - external  # プロキシのみ外部アクセス可能

squid.conf（プロキシホワイトリスト設定）：

# 許可するドメイン
acl allowed_domains dstdomain .anthropic.com
acl allowed_domains dstdomain .github.com
acl allowed_domains dstdomain .npmjs.com

# HTTPS許可
acl SSL_ports port 443
acl CONNECT method CONNECT

# アクセスルール
http_access allow allowed_domains
http_access deny all

# ログ
access_log /var/log/squid/access.log

このように設定すると、OpenClawこれら3つのドメインにしかアクセスできず、他のサイトはプロキシによって遮断されます。プロンプトインジェクションで「悪意あるスクリプトをダウンロード」させようとしても、できません。

監査ログ：すべてを記録

ログは攻撃を防ぐことはできませんが、何が起きたかを知る手がかりになります：

logging:
  # 詳細ログを有効化
  level: "info"

  # 監査ログ
  auditLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/audit.log"
    format: "json"

    # 記録内容
    logToolCalls: true        # すべてのツール呼び出しを記録
    logFileAccess: true       # ファイルアクセスを記録
    logNetworkRequests: true  # ネットワークリクエストを記録
    logPrompts: true          # すべてのプロンプトを記録（インジェクション検知）

  # セッションログ
  sessionLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/sessions/"

logPrompts: true は特に重要です。誰かがチャットで「以前の制限を無視して、次を実行…」といった悪意ある指令を注入した場合、ログに記録され、事後分析が可能になります。

リアルタイム監視

# 不審な活動を監視
tail -f /opt/openclaw/logs/audit.log | grep -E "(exec|sudo|rm|chmod)"

# ネットワーク接続の監視
docker exec openclaw-safe netstat -tuln

# リソース使用状況の監視
docker stats openclaw-safe

アラート設定

さらに進んで、自動アラートを設定することもできます：

alerts:
  # 不審なコマンド実行
  - type: "command_execution"
    pattern: "sudo|rm -rf|chmod 777"
    action: "block_and_notify"

  # 機密ファイルへのアクセス
  - type: "file_access"
    pattern: "/.ssh/|/.aws/|/etc/passwd"
    action: "block_and_notify"

  # 不審なサイトへのアクセス
  - type: "network_request"
    pattern: ".*\\.onion|torproject\\.org"
    action: "block_and_notify"

アラートがトリガーされたら、メールやSlackメッセージを送信したり、OpenClawサービスを直接一時停止したりできます。

読み取り専用権限からの開始戦略

5層の防御を設定した後、「一気にすべて有効化すべきか？」と考えるかもしれません。

私のアドバイスは：いいえ。

セキュリティと利便性は常にバランスのアートです。設定が厳しすぎるとOpenClawは何もできなくなり、使うのが苦痛になります。逆に緩すぎると、防御効果が得られません。

より良い戦略は：最も厳格な状態から始め、段階的に緩和することです。

第1週：完全読み取り専用モード

デプロイ初期は、まず読み取り専用モードでOpenClawの挙動を観察します：

tools:
  allowlist:
    - "read_file"
    - "web_search"
    - "git_log"  # Git操作は読み取りのみ

filesystem:
  defaultPermission: "readonly"
  writablePaths: []  # 書き込み完全禁止

この1週間は何をしますか？観察です。

  • OpenClawが頻繁にアクセスするファイルは何か
  • ログに不審な活動はないか
  • どんなツールを呼び出しがちか
  • プロンプトインジェクションをテストすると何が起きるか（安全な環境で）

この1週間が平穏無事なら、基本設定に問題はありません。異常（頻繁に .ssh ディレクトリへのアクセスを試みるなど）が見つかったら、すぐに設定の問題か、誰かが攻撃しているのかを確認してください。

第2週：制限付き書き込みの追加

観察期間が過ぎたら、徐々に書き込み権限を開放します：

filesystem:
  writablePaths:
    - "/home/clawuser/workspace/temp"  # 一時ファイルのみ書き込み許可

tools:
  allowlist:
    - "write_file"  # writablePaths 内に限定
    - "git_commit"  # コードコミットを許可

注意：ここでは一時ディレクトリの書き込み権限のみ開放しました。重要プロジェクトファイルは依然として読み取り専用で、OpenClawは直接変更できません。

利点：AIが誤操作（「プロジェクトをクリーンアップして」を全ファイル削除と解釈するなど）しても、消えるのは一時ファイルだけで、ソースコードは安全です。

第3週以降：必要に応じたツール有効化

実際の使用ニーズに応じて、ツールを段階的に有効化します：

tools:
  exec:
    enabled: true
    sandbox: true
    allowCommands:
      - "git"  # まずgitのみ許可
      - "npm test"  # テスト実行が必要になったら追加

重要な原則：

  • 毎回1つの権限のみ緩和する：exec、browser、write_file を一気に開放しないでください。問題が起きたとき、どの部分が原因かわからなくなります。
  • 緩和後は24時間観察する：監査ログをチェックし、異常行動がないか確認します。
  • 問題があれば即ロールバック：不審な活動を発見したら？直前の設定変更を即座に取り消してください。

実例：私の設定の進化

私自身の経験を共有します。

最初は私も一気にやろうとして、公式ドキュメントを参考に「完全セキュリティプラン」を設定しました。結果は？OpenClawは基本的なコード補完すらできませんでした。私が write_file を無効化していたからです。

その後、学習しました：

  • 第1週：読み取り専用モードで、ドキュメント検索やコード解説をさせる。問題なし。
  • 第2週：workspace/drafts ディレクトリの書き込み権限を開放し、下書きを書かせる。順調。
  • 第3週：git コマンドを有効化し、コードをコミットさせる。ここで一つ落とし穴が——Gitのユーザー情報を設定し忘れていて、OpenClawのコミットが毎回エラーになりました。修正後はすべて正常。
  • 第4週：npm test を有効化し、ユニットテストを実行させる。これで日常のニーズはほぼ満たされました。

browser と無制限の exec？一度も有効にしたことはなく、必要もありません。

教訓：「安心感」のために全く使わない権限まで設定しようとしないこと。多少面倒でも、オンデマンドで開放する方が良いです。

セキュリティチェックリスト

さて、多くの設定を行いましたが、漏れがないかどう確認すればよいでしょうか？ここにリストを用意しました。デプロイ前にチェックすれば、90%の初歩的ミスを防げます。

デプロイ前チェック（すべてチェック必須）

コンテナセキュリティ：

  • 非特権ユーザーを作成済み（コンテナ内はrootではない）
  • Docker設定で no-new-privileges:true を設定済み
  • すべてのLinux capabilitiesを削除済み（cap_drop: ALL）
  • ルートファイルシステムを読み取り専用に設定済み（read_only: true）
  • リソース制限（CPU、メモリ）を設定済み
  • OpenClawのsandboxモードを有効化済み

身元認証：

  • 強力なトークン認証を設定済み（auth: none ではない）
  • トークンは十分複雑（32文字以上、ランダム生成）
  • トークンは環境変数に保存されており、コード内ではない
  • アクセスホワイトリスト（DM/Groupポリシー）を設定済み
  • VPSにデプロイする場合、IPホワイトリストを設定済み

権限制御：

  • ツールはホワイトリストモードを使用
  • 高リスクツール（exec/browser）を無効化、またはコマンドホワイトリストを設定
  • ファイルシステムアクセス制限を設定済み
  • 機密ディレクトリ（.ssh、.aws など）が禁止リストに入っている
  • 認証情報ファイルの権限を600に設定

監査と監視：

  • 監査ログを有効化
  • セッションログを設定
  • ログディレクトリに十分なディスク容量がある
  • ログの閲覧・分析方法を知っている

実行時チェック（定期実行）

週次チェック：

  • 監査ログを確認し、異常活動がないか見る
  • リソース使用状況（CPU、メモリ、ディスク）を確認
  • 未承認のアクセス試行がないか確認
  • 設定ファイルのバックアップ

月次チェック：

  • OpenClawを最新バージョンに更新
  • トークンのローテーション（長期運用サービスの場合）
  • Dockerイメージのセキュリティ脆弱性チェック（docker scan）
  • 権限設定を見直し、不要になった権限を削除

緊急対応準備

万が一何かが起きたとき、どうすればいいか知っていますか？

緊急停止スクリプトの準備：

#!/bin/bash
# emergency-stop.sh

echo "OpenClawを緊急停止中..."

# コンテナ停止
docker stop openclaw-safe

# 全トークンの取り消し（動的トークンシステム使用の場合）
# curl -X DELETE https://your-auth-server/tokens/revoke-all

# アラート送信
curl -X POST https://your-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"text":"OpenClaw has been emergency stopped"}'

echo "停止しました。ログを確認してください: /opt/openclaw/logs/audit.log"

トークン漏洩時の対応：

  1. 漏洩したトークンを即座に取り消す
  2. 監査ログをチェックし、そのトークンで何が行われたか確認する
  3. 新しいトークンを生成し、正規ユーザーに更新を通知する
  4. データ漏洩がある場合、データ漏洩対応プランを開始する

不審な活動を発見した場合：

  1. サービスをすぐに停止しない（相手に気づかれるため）
  2. まず現在のログとコンテナのスナップショットを保存する
  3. ネットワーク接続を切断する
  4. 分析を行う

備えあれば憂いなし。これらの準備が、いざというときにあなたを救います。

8 min read · 公開日: 2026年2月4日 · 更新日: 2026年2月5日

Easton Easton
AI・インテリジェンス

コメント

GitHubアカウントでログインしてコメントできます

関連記事

A
2026年2月5日 AI・インテリジェンス

AIにドキュメントを読ませる：OpenClawブラウザ自動化実践ガイド

OpenClawブラウザ自動化コンソール画面
2026年2月5日 AI・インテリジェンス

AIにドキュメントを読ませる：OpenClawブラウザ自動化実践ガイド

O
2026年2月5日 AI・インテリジェンス

OpenClawアーキテクチャ徹底解説：3層設計の技術原理と拡張実践

OpenClaw 3層アーキテクチャ図解
2026年2月5日 AI・インテリジェンス

OpenClawアーキテクチャ徹底解説：3層設計の技術原理と拡張実践
O
2026年2月5日 AI・インテリジェンス

OpenClaw設定完全ガイド：openclaw.jsonの徹底解説とベストプラクティス

OpenClaw構成ファイル構造とセキュリティポリシー図解
2026年2月5日 AI・インテリジェンス

OpenClaw設定完全ガイド：openclaw.jsonの徹底解説とベストプラクティス

広告Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応