法人の担当者・経営者、仕事でAIやITを活用したい個人
APIキーは、外部サービスを使うための重要な鍵です。試作品だからと画面のコードへ入れると、他の人へ見えることがあります。保存先と権限を分け、漏れた場合の対応も決めましょう。
- 01秘密を分離
- 02権限を最小化
- 03履歴・ログを確認
- 04漏洩時は失効
矢印の順に、自社の状況へ置き換えて確認しましょう。
1. 画面へ渡す情報と秘密を分ける
ブラウザーへ送ったコードや設定は、利用者から確認できる場合があります。サービスの秘密鍵を画面側に置かず、サーバー側で保管し、必要な処理だけを呼び出します。公開用として設計された識別子と秘密のキーは区別してください。
管理者だけが見る画面でも、HTMLへキーを表示すれば安全な保管とは言えません。
2. 環境ごとに権限を絞る
試験用と本番用のキーを分け、必要な機能だけを許可します。費用の上限や通知を設定できる場合は活用し、担当者と管理方法を決めます。環境変数などを使ってコードから分離しても、ログや配布ファイルへ含めない確認が必要です。
ファイル名だけで安全性は決まりません。どこから読めるかまで確かめましょう。
3. 履歴へ入れない仕組みを持つ
Gitへ追加しない設定を用意し、公開前に対象ファイルを確認します。すでに記録した秘密を、後から除外設定へ追加するだけでは過去の履歴から消えません。共有先の権限と自動検出の仕組みも検討します。
開発会社へキーを渡す場合は範囲と期限を決め、終了時には必要な権限を見直します。
4. 漏れたら、削除より先に無効化する
公開したキーは、第三者が取得した可能性を考えます。該当サービスで無効化・再発行し、利用記録や費用を確認します。コードの削除だけで対応完了としないでください。
新しいキーを正しい保存先へ設定し、動作を確認します。重要な漏洩では責任者へ報告し、影響するデータと通知の要否を調査します。
判断に使う比較表
| 段階 | すること | まず確認する内容 |
|---|---|---|
| 秘密を分離 | 画面へ渡す情報と秘密を分ける | ブラウザーへ送ったコードや設定は、利用者から確認できる場合があります。 |
| 権限を最小化 | 環境ごとに権限を絞る | 試験用と本番用のキーを分け、必要な機能だけを許可します。 |
| 履歴・ログを確認 | 履歴へ入れない仕組みを持つ | Gitへ追加しない設定を用意し、公開前に対象ファイルを確認します。 |
| 漏洩時は失効 | 漏れたら、削除より先に無効化する | 公開したキーは、第三者が取得した可能性を考えます。 |
相談前のチェックリスト
- ブラウザーへ秘密を渡さない
- ログと配布物を確認
- 失効と再発行の担当が明確
よくある質問
公開したキーをファイルから消せば大丈夫ですか？
履歴や取得済みのコピーへ残る可能性があります。まず提供元で無効化し、利用記録と影響を確認してください。
具体的な仕様が決まっていなくても相談できますか？
困っている作業、利用する人、希望時期を分かる範囲でお知らせください。一般的な記事の内容をそのまま当てはめず、現状と制約から必要な支援範囲を確認します。
NEXT STEP / 次の一歩
自社の場合を、
一緒に整理する。
使う外部サービスと運用体制を、秘密の値を含めず教えてください。安全な接続、権限、費用制限を設計します。