セキュリティ
【セキュリティ】APIキー・パスワードの管理:GitHubに上げてはいけない
2026年10月8日

レン
アプリ作ってたら、APIキーとかDBのパスワードをコードに書いちゃったんだけど…これってマズい?
ウィルスン
…それをGitHubの公開リポジトリに上げていないだろうな?ワタシのような者は、公開されたコードから漏れた認証情報を『自動で』収集している。APIキーが1つ漏れれば、そこから芋づる式にすべてを奪えるのだ。

レン
ま、まさに上げようとしてた…!危なかった!

プロクラ
本当に危なかったね。認証情報(シークレット)は、コードに直書きしないのが絶対の原則。特にGitのリポジトリに含めてしまうと、後から消しても履歴に残るから、実質『一度上げたら漏れた』と考えないといけないんだ。
守りは「重ねる」のが基本
攻撃
ファイアウォール
不要な入口を塞ぐ
SSH鍵認証
総当たりを無効化
OS更新
既知の穴を埋める
サーバー
1つ破られても次の層で止まる。どれか1つでは不十分
シークレットの正しい扱い方
- APIキー・パスワードは環境変数(.envファイル)に置き、コードから読み込む
- .envは必ず.gitignoreに入れて、Gitに含めない
- .envファイル自体の権限も絞る(chmod 600 で本人だけ読めるように)
- 万一漏らしたら、そのキーは即座に無効化して再発行する(消すだけでは不十分)

レン
もし間違えて上げちゃったら、削除すればいいんじゃないの?

プロクラ
それが甘いところ。Gitは履歴を全部覚えてるから、ファイルを消してもコミット履歴を辿れば見えてしまう。だから『漏らしたキーは、消すんじゃなく無効化して作り直す』のが鉄則。GitHubには漏洩を自動検知して警告する仕組みもあるけど、頼り切りは禁物だよ。
ウィルスン
覚えておけ。強固なファイアウォールも、鍵認証も、たった1つの漏れたパスワードの前では無力だ。認証情報の管理こそ、キミの城の『鍵束』そのもの。決して落とすな。
どこに置くか
鍵の置き場所を考えるとき、判断の軸は「うっかり共有される経路に乗っていないか」です。ソースコードは共有される前提のものなので、そこに書いた時点で漏れる可能性が生まれます。設定ファイルへ分け、そのファイルをバージョン管理の対象から外す。この2つで、事故の大半は防げます。

プロクラ
「コードに書かない」の次に来るのが、じゃあどこに置くか、だよね。規模に応じて選べばいい。
- 個人・小規模: サーバー上の環境変数か、権限を600にした設定ファイル
- 自動デプロイを使う場合: その仕組みが用意している秘密情報の保管機能
- 複数人・複数サーバー: 専用の管理サービスを検討する
- 共有するときは、チャットやメールに貼らない
漏れにくくする工夫
- 本番用と検証用の鍵を分ける(どちらが漏れたか切り分けられる)
- 鍵に権限の制限をかける。全部できる鍵を作らない
- 定期的に作り直す。使わなくなったものは無効化する
- エラーの記録やログに、認証情報が出力されていないか確認する
- 画面共有やスクリーンショットに写り込ませない

プロクラ
4つめは意外な落とし穴だよ。エラーの詳細を出力する設定にしていると、接続情報がそのままログに残ることがある。ログは消し忘れやすいので、そこも確認しておこう。

レン
書かない、分ける、絞る、作り直す。ログに出ていないかも見る。
VPSの料金を比較する
あわせて読みたい
- セキュリティ【セキュリティ】侵入されたかも?と思ったときにやること不審な挙動に気づいたときの初動を順番に解説します。何を疑うか、消す前に何を残すか、認証情報をどこまで変えるか、そしてなぜ掃除ではなく作り直しなのかまで。
- セキュリティ総当たり攻撃のログが止まらない:無視していいのか毎日大量に届く認証失敗の記録を、どこまで気にすべきか。放置してよい条件と、本当に危ない記録の見分け方、ログを減らす手段を解説します。
- セキュリティログイン機能の落とし穴:セッション管理ログイン状態を保つ仕組みと、なりすましを許す典型的な実装ミス。Cookieに付ける属性の意味、ログアウトで何をすべきか、そして認証を自作しないほうがいい理由を解説します。
- セキュリティファイルアップロード機能は危険な機能「画像だけ受け付ける」判定がなぜ難しいのか、中身を検査しても残る危険、容量と回数の上限、そして受け取ったファイルをどこに置くかまで解説します。