APIキーの漏洩対策、制作会社は「書かない仕組み」と「漏れたら止める初動」──Git・.envの置き方、シークレットスキャン、鍵の無効化と再発行

この記事は、Web制作会社のAPIキーの漏洩対策として、Gitや.envファイルに秘密情報を残さない仕組みと、漏れたときの初動を扱います。

「テスト用だったので、そのまま入れていました」

ある日、外部サービスの事業者から、一通のメールが届きます。
「お客様のAPIキーが、公開された場所で見つかりました」

調べると、半年前に若手が作ったリポジトリでした。
テストのために、キーを設定ファイルに直接書き、その履歴がそのまま残っていたのです。

最初に考えるべきは、ファイルを消すことではありません。その鍵を、使えなくすることです。

秘密情報の漏えい対策とは、鍵をコードと履歴に残さない仕組みを作り、それでも漏れたときは、まず鍵を無効化して取り替えることである

黒字化の外科医です。APIキー、パスワード、接続情報といった「鍵」の守り方と、漏れたときの最初の一手を解剖します。

なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。

二本立てにする理由は、三つあります。

第一に、Gitは、消したはずのものを履歴に残すから。
最新のファイルからキーを消しても、過去のコミットには残っています。GitHubの公式ドキュメントも、履歴を書き換えても、ほかの人の複製（クローンやフォーク）からは消せないと説明しています。

第二に、漏れた鍵は、消すより止めるほうが確実だから。
GitHubの公式ドキュメントは、リポジトリから秘密情報を取り除くとき、最初の一歩として、その鍵を無効化（revoke）または取り替え（rotate）するよう求めています。取り替えれば、その鍵ではもう入れません。

第三に、制作会社の鍵の多くは、顧客のものだから。
顧客の名義のキーが漏れれば、費用と信用の被害は顧客に出ます。

今すぐ試せる：自社の秘密情報の置き場所を棚卸しするプロンプト

私はWeb制作会社の技術責任者です。社内の秘密情報の置き場所を棚卸しし、漏えい対策の優先順位を付けてください。
（実際のキーやパスワードの文字列は入力しません。種類と置き場所だけを書きます）

【前提】
・使っている外部サービスのキーの種類（決済、地図、メール配信、生成AIなど）：〔　〕
・それぞれの名義（自社／顧客）：〔　〕
・今の置き場所（.envファイル、設定ファイル、サーバーの環境変数、チャット、表計算など）：〔　〕
・リポジトリの置き場所と、公開・非公開の別：〔　〕

1. 漏れたときの影響が大きい順に並べる。
2. コードやGitの履歴に残っていそうな所を挙げる。
3. 今週やる対策と、来月までにやる対策に分ける。

鍵の管理工場：書かない仕組み、見つける仕組み、止める初動

書かない仕組み

□ キーは、コードに直接書かず、環境変数や.envファイルから読み込む
□ .envファイルは、プロジェクトを作った最初の日に、Gitの管理から外す設定をする
□ 代わりに、値を空にした見本のファイル（例：.env.example）だけをGitに入れる
□ キーは、案件ごと・環境ごと（開発用と本番用）に分けて発行する
□ キーの権限は、その案件に必要な範囲だけにする
□ 利用の上限や、利用額の通知を設定できるサービスは、設定しておく
□ チャット、メール、生成AIの入力欄に、キーを貼らない

案件ごとに分けておくと、漏れたときに止める鍵が一つで済みます。
1本のキーを複数の顧客で使い回すと、一つの漏れで全員を止めることになります。

見つける仕組み

□ GitHubを使うなら、シークレットスキャン（秘密情報の検出）の設定を確かめる
□ プッシュ保護（秘密情報を含むプッシュを止める機能）の設定を確かめる
□ 新しいリポジトリを作るときの手順に、この2つの確認を入れる

GitHubの公式ドキュメントによると、シークレットスキャンは、リポジトリの全ブランチのGitの履歴全体を走査し、公開リポジトリでは無料で自動的に動きます。プッシュ保護は、秘密情報を含むプッシュを、リポジトリに届く前に止める機能です。個人アカウントの公開リポジトリ向けには、GitHub.com上で初めから有効になっています。

リポジトリ単位のプッシュ保護を使うには、「GitHub Secret Protection」を有効にする必要があります。料金と対象は変わるため、導入の前に公式のページで確かめてください。

漏れたときの初動（順番どおりに）

1. 鍵を無効化し、新しい鍵を発行する（発行元の管理画面で）
2. 新しい鍵を、決められた置き場所に設定し、サイトの動作を確かめる
3. 古い鍵の利用履歴と請求を、発行元の管理画面で確かめる
4. 顧客の名義の鍵なら、その日のうちに顧客へ第一報を入れる
5. 漏れた経路（どのリポジトリ、どのファイル、誰が）を記録する
6. 履歴から消す作業が必要かを判断する
7. 同じ置き方をしているほかの案件を点検する

6を最後に置いているのが要点です。GitHubの公式ドキュメントは、鍵を取り替えれば、それで足りる場合があり、履歴を書き換える手間は必ずしも要らないとしています。

顧客の個人情報に影響があり得るときは、報告が必要かどうかの判断に進みます。報告の考え方は個人情報の漏えい、報告は誰がいつまでにで扱っています。

顧客への第一報の文例

〇〇様

御社名義で発行いただいている〔サービス名〕のAPIキーが、弊社の管理の誤りにより、外部から見える状態になっていたことが分かりました。

本日〇時に、該当のキーを無効化し、新しいキーに切り替えました。サイトの動作に問題がないことを確認しています。
現在、古いキーが使われた形跡がないかを確認しております。結果は〇日までにご報告します。

ご迷惑をおかけし、申し訳ございません。

顧客から預かるログイン情報の受け取りと保管のルールは、こちらにまとめています。

▶ パスワード管理、顧客から預かるIDで事故を起こさない制作会社のルール──FTP・管理画面・サーバー・ドメインの受け取り、保管、返却と依頼文

構造的なリスク

逆説を指摘しておきます。

検出の仕組みを入れると、「見つけてくれるから大丈夫」と考えがちです。
けれど、検出の仕組みが、すべての秘密情報を拾えるとは限りません。独自のパスワードや接続情報は、すり抜けることがあると考えておくべきです。

だから、見つける仕組みは、書かない仕組みの後ろに置く「網」です。
新人への教育で、まず「書かない」を身につけてもらってください。

▶ セキュリティ教育を社員に続ける制作会社の型──年1回の研修をやめ、12か月の計画、IPAの無料教材、確認テストで「聞いただけ」を終わらせる

よくあるQ&A

Q. 非公開のリポジトリなら、書いても大丈夫ではないか？

非公開でも、外注先や退職者、乗っ取られたアカウントから見られることがあります。公開・非公開にかかわらず、書かない前提にしてください。

Q. 鍵を取り替えると、サイトが止まるのでは？

止まる時間を短くするため、新しい鍵の設定先と手順を、案件ごとに台帳に残しておきます。止まるおそれより、漏れた鍵を使われ続けるおそれのほうが大きいのです。

Q. AIのコーディング支援が、キーをコードに書いてしまったら？

人のレビューで止めます。AIが書いたコードのレビューの観点に、秘密情報の混入を入れています。

最後に

秘密情報は、一度コードと履歴に入ると、完全には消せません。

書かない仕組みと見つける仕組みを先に作り、漏れたら真っ先に鍵を取り替える会社だけが、顧客の鍵を預かる資格を守り続けられるのです。

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #APIキー #情報漏えい #GitHub #セキュリティ対策 #開発ルール #制作会社経営 #中小企業 #インシデント対応 #Web開発