メールAPIキーは短い文字列ですが、大きな力を持っています。キーを手にした人は誰でも、あなたのドメインから、誰に対しても、あなたの名前でメールを送れます。漏えいしたキーは、正規の企業のインフラからフィッシングメールが送られてしまう最も一般的な原因のひとつです。
幸い、いくつかの習慣を身につけるだけで漏えいは起こりにくくなり、万一起きても被害を抑えられます。このガイドでは、Inbixioがすべてのキーに用意している設定を使って、その方法を解説します。
Inbixioのキーでできること
API Keys → Create Api Key（APIキー → APIキーを作成）で作成するキーには、3つの設定があります。
- Name（名前）：自分で管理するための名前。例：
prod-auth-service。 - Server Access（サーバーアクセス）：All Server（すべてのサーバー。最初に接続したSMTPサーバー経由で送信）またはSelected Server（選択したサーバー。指定した1台だけを使用）。
- Permissions（権限）：Send（送信）、Read（読み取り）、Manage（管理）。現在APIのエンドポイントはメール送信の1つだけなので、サービスに必要な権限はSendです。
キーはibx_の後に16進数32文字が続く形式です。このプレフィックスによって見分けやすく、シークレットスキャナーでも検出しやすくなっています。
ルール1：サービスと環境ごとにキーを1つずつ
1つのキーを会社全体で共有してはいけません。サービスごと、環境ごとに別々のキーを作成しましょう。
| キー名 | Server Access | 権限 |
|---|---|---|
prod-auth |
Selected: security@yourco.com |
Send |
prod-billing |
Selected: billing@yourco.com |
Send |
staging-all |
Selected: テスト用メールボックス | Send |
キーを分けることには、次のメリットがあります。
- 漏えいの影響を限定できる：
prod-billingを失効させても、サインインのメールは止まりません。 - 各サービスが正しいアドレスから送信できる：
billing@のサーバーに固定したキーは、最初に接続したサーバーではなくbilling@から送信します。固定先のサーバーを削除すると、キーは最初のサーバーにフォールバックするので、サーバーを削除したらキーを固定し直しましょう。 - ローテーションが簡単になる：他のサービスに影響を与えずに、1つのサービスのキーだけを更新できます。
ルール2：必要最小限の権限だけを付与する
メールを送信するバックエンドに必要なのはSendだけです。ReadとManageはチェックを外したままにしておきましょう。キーにできることが少ないほど、漏えいしたときの被害も小さくなります。
ルール3：キーはサーバーに置き、クライアントには置かない
ブラウザやモバイルアプリに配布したものは、圧縮（minify）されていても抜き取られる可能性があります。たとえば次のようなものです。
- JavaScriptバンドル（React、Vue、Next.jsのクライアントコンポーネント）
NEXT_PUBLIC_、VITE_、REACT_APP_などブラウザ向けのプレフィックスが付いた環境変数- iOSやAndroidのアプリバイナリ
フロントエンドでのユーザー操作をきっかけにメールを送る場合は、自社のバックエンドのエンドポイントを呼び出しましょう。バックエンドがそのユーザーに操作が許可されているかを確認し、レート制限をかけたうえで、環境変数に保管しているキーを使ってInbixioを呼び出します。
// ✅ Browser → your API → Inbixio
await fetch('/api/invite', { method: 'POST', body: JSON.stringify({ email }) });
// ❌ Never do this in frontend code
fetch('https://backend.inbixio.com/api/send-email/', {
headers: { 'X-API-Key': 'ibx_…' }, // visible to every visitor
});ルール4：キーはパスワードと同じように保管する
- キーはシークレットマネージャー（AWS Secrets Manager、Google Secret Manager、Doppler、1Password、Vault）か、プラットフォームの暗号化された環境変数に保管します。
- キーは絶対にコミットしないでください。
.gitignoreに.envを追加し、リポジトリのシークレットスキャンを有効にしましょう。GitHubのプッシュ保護を使えば、多くの漏えいを未然に防げます。 - キーをログに残さないでください。送信リクエストをログに記録する場合は、先に
X-API-Keyヘッダーを取り除きます。 - キーをチケット、チャット、スクリーンショットに貼り付けないでください。共有するのはシークレットへのアクセス権であり、値そのものではありません。
ルール5：定期的に、そして疑わしいときはすぐにローテーションする
Inbixioではキーを更新できます。API Keysページでキーの横にある更新アイコンをクリックします。更新すると、名前、サーバーアクセス、権限はそのままで新しい値が発行され、古い値はただちに使えなくなります。本番環境のキーを送信失敗なしでローテーションするには、次の手順に従います。
- 同じ設定で2つ目のキーを作成します（例：
prod-auth-2）。 - 新しいキーをサービスにデプロイし、自社のアプリケーションログなどで、そのリクエストが
200を返すことを確認します。 - 古いキーを削除します。
漏えい直後など、スムーズな切り替えよりスピードが重要な場合は更新アイコンを使いましょう。通常のキーは数か月ごとに、またアクセス権を持つメンバーがチームを離れるたびにローテーションします。
キーが漏えいした場合
インシデントとして扱いましょう。ただし、対処可能なインシデントです。
- すぐにキーを更新（更新アイコン）または削除します。これで古い値は一切使えなくなります。
- ダッシュボードのログを確認し、不審な時間帯の呼び出しや送信量の急増など、異常なアクティビティがないか調べます。ログには呼び出しの日時は記録されますが、どのキーによる呼び出しかは記録されないため、自社サービスのログと照らし合わせてください。
- メールプロバイダーを確認し、自分が送っていないメッセージによるバウンスや迷惑メールの報告がないか調べます。
- コミット、ログの1行、フロントエンドのバンドルなど、漏えいの経路を特定し、その経路をふさぎます。
- あなたの名前でメッセージが送られていた場合は、影響を受けたユーザーに知らせ、それらを無視するよう伝えます。
簡単なチェックリスト
- サービスと環境ごとにキーを1つずつ用意し、わかりやすい名前を付けている
- 各サービスが使うべきサーバー（送信元アドレス）にキーを固定している
- 送信用のサービスにはSend権限だけを付与している
- フロントエンドのコード、モバイルアプリ、リポジトリにキーがない
- キーをシークレットマネージャーに保管し、ログから取り除いている
- ローテーションの日程をカレンダーに入れ、漏えい時の対応計画がある
セキュリティは、迷惑メールフォルダー行きを防ぐことにもつながります。不正利用されたキーから送られたメッセージは、ドメインの評価を損なうからです。全体像をつかむには、このチェックリストとSPF、DKIM、DMARCを組み合わせてください。
