APIキーを安全に共有する方法
秘密情報を露出させずに
APIキーはSlack、Teams、メール、チケット、Gitの履歴に置くものではありません。鍵の範囲を絞り、ローカルで暗号化し、ワンタイム秘密リンクを使い、受け渡しが終わったらローテーションする、より安全な手順を説明します。
要点
- APIキーをメール、チャット、チケット、文書、Gitに貼り付けないでください。
- 必要最小限の権限だけを持つキーを使い、有効期間を短く設定して、作業後に更新してください。
- 秘密情報は、ブラウザで暗号化したワンタイム秘密リンクで送ってください。
- リスクの高い鍵は、まずローカルで暗号化し、暗号文だけを共有してください。
- 共有後は不審な利用がないか確認してください。PrivateNoteは一時的な受け渡しのためのツールであり、長期保管庫ではありません。
このページの内容
どの開発者も、やがて誰かにAPIキーを送る必要が出ます。ステージングへのアクセス、委託先、Webhookの連携、顧客への受け渡しのためです。いちばん速い道は、通常、いちばん長い跡を残す道でもあります。
APIキーを本番のパスワードのように扱う
APIキーは、実質的にソフトウェア用のパスワードです。権限によっては、漏れた鍵が顧客データを露出させ、有料リソースを消費し、クラウド基盤をデプロイし、検証済みドメインからメールを送り、AIの請求を膨らませることがあります。
人間のパスワードと異なり、APIキーは何か月も有効なまま、設定ファイルの中に置かれ、多要素認証を完全に迂回することが多いです。鍵が漏れると、攻撃者はアプリケーションとして動作できます。悪意のあるトラフィックは、費用が急増するかデータがすでに露出するまで、通常の本番利用に紛れることがあります。
APIキーを恒久的なシステムに貼り付けない
これらのチャネルが便利なのは、履歴を保持するからです。まさにその理由で、秘密情報を置く場所としては不適切です。
- Slack、Microsoft Teams、Discord、その他のチャット履歴
- メール、SMS、転送された受信箱のスレッド
- Jira、Trello、Notion、Confluence、GitHubのissue
- プレーンテキストの文書、スプレッドシート、共有クラウドフォルダ
- Gitのコミット、プルリクエスト、コードコメント
APIキーが実際に漏れる場所
ほとんどの漏えいは、高度な暗号の破れではありません。記録を残すために作られたシステムへ、誰かが秘密情報をコピーしたときに起きます。
メール
メールは長期間残るコピーを作ります。鍵は、作業が終わったずっとあとまで、受信箱、アーカイブ、バックアップ、モバイル同期、転送されたスレッド、検索インデックスに生き残り得ます。
チームチャット
SlackとTeamsは文脈を保持します。それが秘密情報にとって危険です。貼り付けたひとつの鍵が、将来のワークスペースメンバーから検索できたり、侵害された端末から漏れたりします。
プロジェクトツール
Jira、Notion、Confluence、Trello、GitHub Issuesは、認証情報の保管庫ではありません。削除したチケットも、書き出し、バックアップ、監査証跡、AI支援の検索に残ることがあります。
Gitリポジトリ
Gitの履歴は粘着します。後のコミットで鍵を消しても、以前のコミットは消えません。公開リポジトリは絶えずスキャンされ、露出したクラウド認証情報は数分で悪用され得ます。
リスクの高い鍵：まずローカルで暗号化する
ほとんどのAPIキーは取り替えられます。ステージングのトークン、短命の連携秘密、ローテーションする予定の狭い範囲の認証情報です。それらには、ブラウザで暗号化したワンタイムの受け渡しで通常は足ります。
より重い鍵もあります。本番の管理者アクセス、署名鍵、ルートのクラウド認証情報、きれいに失効させるのが苦痛または不可能な長寿命のものなどです。マスター秘密のように扱ってください。Webへアップロードする前にローカルで暗号化し、その後、暗号文をPrivateNoteで送ってください。
- age。ファイル暗号化の最も簡単な初期設定です（
age -p -o key.txt.age key.txt） - OpenSSL。フラグをすでに知っている場合の、信頼できるCLIです
- 暗号化したファイルはPrivateNoteでアップロードし、復号用のパスフレーズは別の経路（Signal、電話、対面）で送ってください
同じ手順は、暗号通貨のシードフレーズや、ほかの取り替えられないマスター秘密にも当てはまります。ageとOpenSSLの詳しい手順、パスフレーズのヒント、ワンタイムリンクが適切な場合と適切でない場合は、暗号通貨のシードフレーズとワンタイム秘密リンクをご覧ください。
より安全な受け渡しの手順
アプリが実行時に取得するときではなく、人が鍵を必要とするときは、この順序に従ってください。
鍵の範囲を絞る
最小の権限だけ
ローカルで暗号化する
鍵はブラウザの外に出ません
リンクを送る
生の秘密情報ではありません
終わったら失効する
受け渡し後にローテーション
メモのパスワードは別の経路で共有してください。リンクと同じメッセージには入れないでください。
PrivateNoteが受け渡しにどう当てはまるか
PrivateNoteは、人から人への瞬間のために作られています。APIキー、SSHの秘密鍵、データベース認証情報、復旧コード、Webhookの署名秘密、ひとりに届ける必要があり恒久的な記録になるべきでない一時パスワードです。
秘密情報がAPIの認証情報ではなくSSHキーである場合は、公開鍵と秘密鍵、デプロイキー、エディタ拡張機能について、SSHキーを安全に共有する方法をご覧ください。
秘密情報は、アップロード前にブラウザで暗号化されます。PrivateNoteが保存するのは暗号文であり、平文ではありません。復号鍵はURLフラグメント、つまり#よりあとの部分にあります。ブラウザはページを読み込むとき、それをサーバーに送りません。これが、APIの認証情報に適用したワンタイム秘密リンクのモデルです。
https://privatenote.ai/note/abc123#kL8mN4...
- サーバーが受け取るのは、メモIDと暗号化されたペイロードです。
- サーバーは復号鍵を受け取りません。
- 閲覧後に破棄する設定と有効期限が、暗号化されたメモの存在期間を制限します。
PrivateNoteは専用のシークレットストアを補います。連携相手にStripeの鍵を送るとき、委託先に一時的なOpenAIの鍵を共有するとき、チームメイトにステージング認証情報への一度きりのアクセスを渡すとき、その隙間を埋めます。
よくある質問
環境変数を使えば十分ではないのですか？
環境変数は、ローカルのソフトウェアを動かすのには向いています。その値をチームメイト、委託先、顧客、連携相手に渡す必要があるときの、輸送の問題は解決しません。
APIキーは常に期限切れにすべきですか？
提供者が対応しているなら、はい。短命の認証情報は、誤って開示されたあとの悪用の窓を狭くし、ローテーションを通常の作業の一部にします。
最も安全な手順は何ですか？
範囲を狭く絞った鍵を作り、ブラウザで暗号化したワンタイム秘密リンクで送り、任意のパスワードは別の経路で共有し、作業が終わったら鍵をローテーションまたは失効させてください。リスクが高い、または長寿命の鍵は、先にageまたはOpenSSLでローカルに暗号化し、暗号文だけをアップロードしてください。
PrivateNoteはシークレットマネージャーですか？
いいえ。PrivateNoteが解決するのは、人から人への安全な受け渡しです。マシンからマシンへの秘密情報の保管には、HashiCorp Vault、AWS Secrets Manager、Google Cloud Secret Manager、またはAzure Key Vaultを使ってください。
結論
ほとんどのAPIキーの漏えいは、暗号が失敗したから起きません。便利さのために、誰かが秘密情報を、恒久的で検索できるシステムへコピーしたから起きます。鍵の範囲は厳しく絞り、必要なときだけ共有し、チャット、チケット、メール、Gitに平文の跡を残さないでください。配送パイプライン側、つまり`.env`のコミット、CIログ、GitHubの履歴については、[CI/CD、.envファイル、GitHubの秘密情報](blog:secrets-in-cicd-env-github-leaks)をご覧ください。
