ソースコードの中に書かれたままのパスワードやAPIキーを見つけて、どこへ移そうかと落ち着いて考えている一人運用の保守担当者
セキュリティ・パッチ約12分

パスワードとAPIキーの平文放置をなくす｜一人運用の保管手順

改修のためにソースコードを開いたら、接続用のパスワードが、そのまま文字で書かれている。 共有フォルダを探せば「各種パスワード.xlsx」があって、誰でも開ける。

——見なかったことにしたい気持ち、よく分かります。

これは、あなたが手を抜いたからではありません。前任者から引き継いだ環境や、長く動いてきたシステムでは、本当によくあることです。動かすことが最優先だった時期に置かれたものが、そのまま残っているだけです。

この記事では、その平文をゼロにするために、今あるものを洗い出して、安全な置き場所へ少しずつ移していく手順を一緒に整理します。全部を今日中に直さなくて大丈夫です。まず一番危ない1つから動かせば、それで前に進んでいます。

結論：やることは4つです。①どこに何が平文で置かれているか洗い出す、②「漏れたら一番困る1つ」から、コードの外（環境変数や専用の保管サービス）へ移す、③移し終えたら、その鍵を再発行して古い値を無効にする、④これから足すぶんは平文で書かない仕組みを1つ入れる。この順番で回します。とくに③は忘れられがちですが、一度でも平文で置かれた値は「もう知られたかもしれない値」として扱うのが安全です。

具体的な保管方法は、環境（サーバー1台なのか、クラウドなのか、チーム共有か）で最適解が変わります。この記事の考え方を出発点に、自分の現場で無理なく続けられるやり方を選んでください。

何が起きているのか：平文が残る理由

「なぜ直っていないのか」には、たいてい理由があります。

どれも、現場としては自然な流れです。責める話ではありません。 ただ、時間が経つほどコピーが増えるのがこの問題の性質です。Excelはメールで転送され、コードはリポジトリの履歴に残り、テスト用のコピーが別サーバーにも置かれる。だから、気づいたタイミングで少しずつ減らしていくのが現実的です。

よくある「平文の置き場所」

まずは、自分の環境にどれがあるか思い浮かべてみてください。

「ぜんぶ当てはまる」と思っても、落ち込まなくて大丈夫です。当てはまる数が多いほど、洗い出しの効果も大きいということです。

手順①：どこに何があるか洗い出す

いきなり直さず、まず場所を知ります。10〜30分あればかなり見えてきます。

ソースコード・設定ファイルを探す

よく使われる語で検索をかけます（検証環境やコピーの上で実行するのが安全です）。

grep -rniE "password|passwd|pwd|secret|api[_-]?key|token|access[_-]?key" /path/to/app \
  --include="*.php" --include="*.py" --include="*.rb" --include="*.js" --include="*.yml" --include="*.env*"

ヒット件数が多くて驚くかもしれませんが、大半は変数名だけで値は入っていません。「= の右側に実際の文字列が入っているもの」だけを拾えば十分です。

Gitで管理しているなら、履歴の中も見ておきます。今のファイルから消しても、過去のコミットには残っています。

git log -p -S "パスワードらしき文字列" --all | head -50

それ以外の置き場所を確認する

一覧にまとめる

見つけたものを、こんな粒度でメモします。値そのものは書かず、場所と種類だけにしておくのがコツです。

種類今ある場所漏れたときの影響移し先状態
決済APIキーapp/config.php 直書き大（お金が動く）環境変数未
DBパスワード.env（リポジトリ内）大環境変数未
管理画面ログイン共有Excel中パスワード管理ツール未

「影響」の欄が、次にどれから手を付けるかの答えになります。

手順②：安全な置き場所へ移す

秘密の値をコードの中から環境変数、さらに専用の保管サービスへと移していく3段階の置き場所を示した図
左から右へ、無理のない範囲で1段ずつ移していけば十分

置き場所の選択肢は、大きく3段階です。上から順に整備しなければいけない、という話ではありません。今より1段よくなれば十分です。

段階1：コードの外に出す（環境変数・設定ファイル）

一人運用でまず現実的なのは、値をコードから追い出して、サーバー上の設定ファイルか環境変数に置く方法です。

これだけで、「リポジトリを見られたら終わり」「バックアップのzipに含まれる」といった経路がかなり減ります。

cronやバッチのコマンド引数に書かないのも同じ考え方です。mysql -p パスワード はプロセス一覧から見えることがあるので、~/.my.cnf（権限600）のような設定ファイル側に寄せます。

段階2：人が共有するものはパスワード管理ツールへ

社内や協力会社と共有する必要がある値（管理画面のログイン、SaaSのアカウントなど）は、Excelやチャットではなくパスワード管理ツールにまとめます。1Password、Bitwarden などが代表的で、小規模チーム向けのプランもあります。

ツールを入れる利点は、単に暗号化されることだけではありません。

導入がすぐに難しければ、まずはExcelをやめて、限られた人だけがアクセスできる場所に移すだけでも一歩です。

段階3：システムが使うものはシークレット管理サービスへ

クラウドやCI/CDを使っているなら、その仕組みが持つ保管機能に寄せると管理が楽になります。

これらは「暗号化して保管する」だけでなく、アクセス権の設定・変更履歴・自動での入れ替えまで扱えるのが強みです。ただし運用の手間も増えるので、一人運用なら段階1と2で十分な場面も多いです。無理に入れなくて大丈夫です。

手順③：移したら「古い値」を無効にする

ここが一番忘れられやすく、そして一番大事なところです。

平文の場所から値を消しても、その値自体が安全になるわけではありません。 Gitの履歴、古いバックアップ、転送されたメール、誰かのローカルコピー——消したつもりの場所以外に残っている可能性があります。

なので、移し終えたら次をやります。

  1. 新しい値を発行する（APIキーは再発行、パスワードは変更）
  2. 新しい値を、安全な置き場所に入れる
  3. 動作を確認する（本番反映の前に、可能なら検証環境で）
  4. 古い値を無効化・失効させる

APIキーの多くは「新旧を一時的に両方有効にできる」ため、新しい鍵で動くのを確認してから古い鍵を止めると、切り替えで止まる心配が減ります。

なお、Gitの履歴からファイルを完全に消す作業（履歴の書き換え）は、他の人の手元と食い違いが起きるため慎重さが要ります。まずは「鍵を無効にする」ことを優先してください。無効になった値は、履歴に残っていても悪用されません。履歴の掃除は、余裕があるときに落ち着いて。

手順④：これから増やさない仕組みを1つ

過去を片付けても、明日また直書きしてしまっては元に戻ります。負担にならない範囲で、歯止めを1つだけ入れます。

全部やる必要はありません。.gitignore の1行だけでも、明日から効きます。

影響：直しておくと、何が楽になるか

不安を煽りたいわけではないので、前向きな面から書きます。

そして何より、「あのExcel、大丈夫かな」と頭の片隅で気にし続ける必要がなくなります。これは想像以上に効きます。

明日からやる3ステップ

  1. 10分だけ洗い出す：ソースコードに grep をかけて、値が直書きされている箇所をメモする（直さなくていい、数えるだけ）
  2. 一番影響が大きい1つを選ぶ：お金が動くもの、個人情報に触れるものを優先する
  3. その1つをコードの外へ出し、鍵を再発行する：新しい値で動くのを確認してから、古い値を無効にする

1件終わったら、それで今日は十分です。残りは次に触るついででかまいません。

平文放置をなくすチェックリスト

全部にチェックが付かなくても大丈夫です。一番危ない1件が安全な場所に移って、古い鍵が無効になっている——それだけで、昨日より確実に守れています。

この問題は、一日で終わる種類のものではありません。でも、あなたが今日それに気づいて、1件だけでも動かしたなら、このシステムは前より少しだけ安全になりました。次に触る人は、たぶんそれに気づかないでしょう。それでいいのだと思います。静かに効く仕事を、ひとつずつ。

秘密の値を安全な場所に移し終えて、肩の力が抜けて少し前を向いている保守担当者
一番危ない1件が片付くだけで、頭の片隅の心配はずいぶん軽くなる

関連記事・ツール

本記事は一般的な実務情報です。設定・コマンド・手順は環境やバージョンで挙動が異なります。鍵の再発行・無効化は連携先へ影響が出ることがあるため、最終判断は本番反映前に検証環境と公式情報でご確認ください。