Bot トークンはどう守られているか

BotShade をお使いのみなさんが一番気にされるのは、おそらく Bot トークン の扱いだと思います。Bot トークンが流出すると、Bot が乗っ取られ、サーバーを荒らされるおそれがあります。そこでこの記事では、私たちが Bot トークンをどこにどう保管し、どこまで守っているかを率直に説明します。私たちが何をしないと決めているかも、あわせて書いておきます。

セキュリティの話は、結論だけを並べると味気なくなりがちです。この記事では、なぜそうしているのかという設計の意図も、なるべく一緒に説明します。

この記事で扱う内容は次のとおりです。

• そもそも Bot トークンとは何か
• 預けるときの流れ
• 保管時はどう守るか
• Bot 同士が混ざらない仕組み
• 通信経路で守ること
• 誰がトークンに触れられるか
• 万一に備えて
• 私たちが意図的にやらないこと
• できないこと、お願いしたいこと

そもそも Bot トークンとは何か

Bot トークンは、Discord の開発者ポータルで Bot を作ったときに発行される長い文字列です。Discord に対して「自分はこの Bot だ」と名乗るためのもので、いわば Bot 専用のパスワード にあたります。

トークンを持っている人は、Bot として何でもできます。Bot に与えた権限の範囲であれば、メッセージの送信、ロールの付与、メンバーの BAN、サーバーの設定変更がすべて可能です。そのため、トークンは「最も慎重に扱うべき情報」と言われています。

BotShade のような Bot プラットフォームを使うときは、この Bot トークンをサービス側に預けることになります。預けたトークンがどう扱われ、どう守られているのかを知っておきたいと思うのは当然のことです。

預けるときの流れ

ユーザーがダッシュボードに Bot トークンを貼り付けて「保存」を押すと、BotShade の内部では次の順番で処理が進みます。

1. トークンは 暗号化された通信 で、ブラウザから BotShade のサーバーに送られる
2. サーバーは受け取ったトークンを Discord に 1 度だけ照会 し、有効なトークンか、どの Bot に紐づくかを確認する
3. 確認が取れたら、サーバーはトークンを その場で暗号化 してから保存する
4. 処理が終わると、平文のトークンはすぐに破棄される

ブラウザの入力欄に「●●●●●●」と並んでいたトークンは、保存したあとはもう復元できません。ダッシュボードに表示されるのは「最後の 4 文字」など、自分の Bot だと見分けるための最小限の情報だけです。

保管時はどう守るか

お預かりした Bot トークンは、すべて 暗号化して保存 しています。保存されている値だけを手に入れても、そこからトークンを読み取ることはできません。

復号に必要な鍵は、暗号化した値とは分けて厳重に管理しており、扱える権限も限られています。一方が破られても、もう一方で食い止める という、多層防御の考え方に基づいています。

Bot 同士が混ざらない仕組み

BotShade では、多くの方の Bot をお預かりしています。そこで欠かせないのが、A さんの Bot が B さんの Bot のトークンやデータに到達できないようにすること です。

Bot の処理からアクセスできるのは、その Bot 自身のデータだけです。この分離は、アプリケーションのコードだけに頼らず、仕組みの側でも保証しています。

コードのバグやリリース時の不具合で 別の Bot のデータがうっかり見えてしまう 余地を、なるべく仕組みの側でなくしたいからです。アプリのコードは日々更新されます。守りの仕組みは、変わりにくい場所に置くほうが安全です。

通信経路で守ること

トークンが流れる経路は、大きく分けて 3 つです。

• ブラウザ ↔ BotShade のダッシュボード
• BotShade ↔ Discord
• 内部のサービス間通信

これらの通信はすべて暗号化しています。あわせて、不審なリクエストや大量のアクセスからサービスを守る対策を講じ、重要なリクエストは正規のものか、途中で改ざんされていないかを確かめてから処理しています。

通信途中での盗聴、なりすまし、改ざんに対しては、それぞれ別の層で別の対策を同時に講じています。

誰がトークンに触れられるか

率直に書くと、私たちは 復号後のトークンには基本的にアクセスしません。日常の運用ラインには復号の手段を持たせていないため、ダッシュボードの開発でもサポート対応でも、平文のトークンを目にする場面はありません。見たいとも思いませんし、見るつもりもありません。

ただし、暗号化された状態の文字列 (ciphertext) そのもの は、ストレージの整合性確認や改ざん検知のために運用側で扱う可能性があります。これは、値が同じか、壊れていないかを復号せずに確かめるための作業です。中身を見るためのものではありません。

運用上行った管理操作は、誰が、いつ、何をしたかを記録しています。

万一に備えて

完璧な防御はありません。だからこそ、問題が起きてしまったときの対応も同じくらい大事だと考えています。

• 不審なアクセスや、通常と異なるパターンのログイン試行は検知の対象です
• トークンが漏れた可能性が出た場合は、対象のユーザーに通知します
• ダッシュボードからトークンは いつでも再生成 できます。古いトークンは即時に失効します
• セキュリティに関する報告は help@botshade.com で受け付けています。発見した方には誠実に対応します (詳しくは 責任ある開示 のセクションをご覧ください)

トークンの再生成は、利用中のユーザーに「いざというときの非常口」として案内しています。何かおかしいと感じたら、まずトークンを再生成して古いトークンを失効させてください。それだけでも、被害の広がりを大幅に抑えられます。

私たちが意図的にやらないこと

設計の意図は、やっていることだけでなく やらないと決めていること にも表れます。私たちが BotShade で「やらない」と決めているのは、たとえば次のようなことです。

• トークンをログに出力しない：エラーログやデバッグログ、メトリクス、トレースを含め、トークン自体やその一部を残さない設計にしています
• サポートチケットやチャットでトークンを尋ねない：問い合わせ対応のために、運営側からトークンの提示をお願いすることはありません。もし「トークンを送ってください」というメッセージが届いたら、送り主は私たちではない誰かです
• ダッシュボード以外でトークンを表示しない：メール、Discord メッセージ、外部サービス連携のいずれでも、平文のトークンを露出させません
• 復号の手段を広げない：鍵を扱える場所と権限を必要な範囲に限り、鍵が「常時手元にある」状態を避けています

こうした「やらない」リストは、書類上のポリシーにとどめず、コードと運用の両方に反映しています。

できないこと、お願いしたいこと

正直に書くと、私たちが守れる範囲には限りがあります。次のような場合は、私たちの側では守りきれません。

• ユーザー自身がトークンを誤って公開リポジトリにコミットしてしまったとき
• ダッシュボードのログインアカウントが第三者に乗っ取られたとき
• ユーザーのデバイス自体がマルウェアに感染しているとき

後ろの 2 つのリスクを減らすうえで最も効果があるのは、ダッシュボードへの入り口を強くしていただくこと です。BotShade のダッシュボードはパスワードを持たない設計です。Discord などの外部アカウントか、パスキー (Passkey) でサインインしていただく形になっています。

そのため、次のことをお願いします。

• サインインに使っている 連携先のアカウント (Discord・Google など) で二要素認証 (2FA) を有効化 しておくこと。BotShade 自身にはパスワードがないため、入り口の強さは連携先のアカウントの強さで決まります
• 可能であれば パスキーを登録 していただくこと。パスキーは端末に紐づく認証方式で、フィッシングに強いのが特長です

また、トークンをうっかり公開リポジトリにコミットしてしまったなど、最初のリスクに気づいたときは、Discord の開発者ポータルの「Reset Token」からトークンをすぐに作り直して ください。古いトークンはその場で失効します。新しいトークンを BotShade のダッシュボードに登録し直せば、Bot はそのまま動き続けます。

セキュリティは、私たちだけでも、お使いの方だけでも完成しません。両方がそろって、はじめて被害を最小限に抑えられる設計になっています。私たちは、私たちの側の役割を誠実に果たし続けます。

なお、防御の具体的な構成や、使っている製品の名前は公開していません。攻撃の手がかりになるためです。ご理解いただけますと幸いです。