本番の秘密情報管理を見直すための改善チェック

「本番のDBパスワード、どこで管理してましたっけ」と聞いたら、Slackの検索窓を叩いて古いDMを探し出す担当者を見たことはないでしょうか。あるいはconfig/database.ymlや.env.productionを開いたら、決済APIのシークレットキーが平文でコミットされている。こうした状態のまま本番稼働しているプロダクトは、実際のところ珍しくありません。この記事では、本番の秘密情報(APIキー・DBパスワード・トークン類)がどのようにずさんに扱われがちか、何がリスクなのか、どう改善すればいいかを発注者向けに整理します。

よくある「秘密情報がだだ漏れ」な状態

私たちが既存プロダクトの引き継ぎで見る典型パターンはだいたい共通しています。

• コードにハードコードされている。決済代行やメール配信、地図APIなどのシークレットキーが、.rbや.jsのソースコードに直書きされ、そのままgitにコミットされている。過去のコミット履歴をgit log -pで遡ると平文のまま残っているケースも多く、「今の最新ファイルから消した」だけでは解決していません。
• Slackやメールでバラまかれている。「本番のAWSキーです」というメッセージが個人間DMやチャンネルに投稿され、そのまま検索可能な状態で残り続けている。Slackはワークスペースの全メンバーが(権限次第で)過去ログを検索できるため、共有した瞬間に事実上「社内全員が閲覧可能」になります。
• .envファイルがgit管理下にある。.gitignoreに.envを入れ忘れていた、あるいは初期構築時に一度コミットしてしまい、その後.gitignoreに追加しても履歴には残り続けている。
• 共有スプレッドシートやNotionに一覧化されている。管理しやすさを優先した結果、アクセス権限のスコープが緩く、退職者や委託先が閲覧権限を持ったままになっている。
• 本番と開発で同じ秘密情報を使い回している。ステージング環境のDBパスワードと本番のDBパスワードが同一で、権限の低い開発メンバーやテスト用アカウントでも本番に到達できてしまう。

いずれも「誰かがサボった」というより、プロダクトが小さいうちは困らなかった運用が、そのままスケールしてしまった結果です。人数が増え、委託先が増え、退職者が出るたびにリスクは積み上がっていきますが、機能に影響しないため誰も手を付けないまま放置されがちです。

放置するとどんなリスクがあるか

秘密情報の管理不備は、機能不具合と違って平常時には何も起きないタイプのリスクです。だからこそ発覚したときの被害が大きくなります。

• 退職者・元委託先が本番にアクセスし続けられる。アカウントは削除しても、共有していたAPIキーやDBパスワードそのものをローテーション(再発行)していなければ、退職後も技術的にはアクセス可能な状態が続きます。悪意がなくても、私物PCに残ったメモやSlackのエクスポートから漏れるリスクは消えません。
• gitリポジトリの漏洩がそのままインフラの漏洩になる。GitHubリポジトリを誤ってPublicにしてしまう、あるいは委託先の退職者が個人アカウントにcloneしたまま持ち出す、といった事故が起きたとき、コード自体だけでなく本番のAPIキーやDBパスワードまで一緒に流出します。
• APIキーの不正利用による金銭被害。特にAWSやSendGridのような従量課金APIのキーが漏洩すると、第三者が大量にリソースを消費し、想定外の高額請求が発生する事例は実際に多く報告されています。
• 個人情報を含むDBへの不正アクセス。DBパスワードが漏洩すれば、会員情報や決済情報を含むテーブルへの不正アクセスに直結します。情報漏洩が発覚した際、原因が「秘密情報の管理不備」だと分かれば、単なる技術的トラブル以上に取引先・利用者からの信頼を損ないます。
• 取引先のセキュリティ審査で不利になる。エンタープライズ企業との契約前に、秘密情報の管理体制についてチェックシートで確認されることが増えています。「APIキーはコードや共有チャットに直接書かず、専用の仕組みで管理している」と即答できないと、契約の障害になり得ます。

改善の進め方

秘密情報管理の改善は、一気に全部やり直そうとすると業務が止まるので、段階を踏んで進めます。

1. 環境変数への移行

まず、コードにハードコードされている秘密情報を洗い出し、環境変数(ENV)経由での参照に置き換えます。Railsであればcredentialsの仕組みも活用できますが、いずれにせよ「秘密情報とコードを物理的に分離する」のが最初の一歩です。この段階で、過去のgit履歴に残った秘密情報についても、git filter-repoのような履歴書き換えツールでの除去を検討します(ただし、履歴を書き換えた時点でそのキーは「漏洩済み」扱いとして再発行するのが安全です)。

2. Secrets Managerへの一元化

環境変数はサーバー上に置くだけでも、直書きよりはましですが、アクセス制御やローテーションの仕組みまでは持ちません。AWSであればSecrets ManagerやSSM Parameter Store、GCPであればSecret Managerといったマネージドサービスに秘密情報を一元化し、アプリケーション起動時にそこから取得する構成に変えると、「誰がいつ参照したか」のログが残り、アクセス権限もIAMで細かく制御できるようになります。

3. アクセス制御とローテーションの仕組み化

秘密情報にアクセスできる人を最小限に絞り(最小権限の原則)、退職・契約終了のたびに関連する秘密情報を機械的にローテーションする運用を決めます。「誰が何にアクセスできるか」が一覧で把握できていない状態だと、退職者対応のたびに漏れが出ます。定期的な棚卸しをスケジュール化しておくのが現実的です。

4. すでに漏洩している秘密情報への対処

コードやSlackに残っている秘密情報を見つけた場合、「消せば終わり」ではありません。一度でも外部に晒された秘密情報は、漏洩したものとして扱い、必ず再発行(ローテーション)するのが原則です。gitの履歴から削除しても、フォークやローカルクローンに残っている可能性はゼロにできないためです。優先順位は、決済系・個人情報にアクセス可能なDB・インフラ管理権限を持つキーから順に、影響範囲を確認しながら進めます。

外注する場合に確認すべきこと

秘密情報管理の見直しを外部に依頼する場合、次の点を確認すると失敗を避けやすくなります。

• 「消す」だけでなく「再発行」まで提案してくるか。既に漏洩している秘密情報をgitから消すだけで終わらせず、ローテーションまで含めた提案になっているかを確認してください。
• 段階的な移行計画があるか。「全部Secrets Managerに一気に移行します」という提案は、移行漏れによる本番障害のリスクを伴います。優先度の高い秘密情報から段階的に移すロードマップを示せるかを見極めます。
• アクセス制御の設計まで踏み込めるか。単にツールを導入するだけでなく、「誰が何にアクセスできるべきか」を業務体制に合わせて設計できるかが重要です。
• 運用に定着させる仕組みまで含むか。導入して終わりではなく、新しいAPIキーを追加する際のルール整備や、退職時のチェックリスト化まで提案してくる会社は、その場しのぎで終わらせない意識があります。

私たちは保守・運用で、本番の秘密情報管理の現状診断からSecrets Managerへの移行、アクセス制御の設計、ローテーション運用の仕組み化までを支援しています。インフラ領域でAWS環境の構築・改善を数多く手がけており、既に漏洩している秘密情報への対処を含めた優先順位づけも実務で行っています。既存プロダクトの改善に着手する際に最初に見るべき観点全般は既存プロダクトの改善、外部チームが最初に見る観点で、放置されたセキュリティパッチへの対応は放置されたセキュリティパッチ対応を進める方法で整理しています。あわせてご覧ください。

まとめ

• 本番の秘密情報がコードやSlack、共有スプレッドシートに直書きされている状態は「平常時は何も起きない」ため放置されがちだが、退職者アクセス・不正利用・情報漏洩に直結するリスクを抱えている
• 改善は「環境変数への移行→Secrets Managerへの一元化→アクセス制御とローテーションの仕組み化」の段階を踏み、既に漏洩している秘密情報は削除だけでなく必ず再発行する
• 外注する場合は、消すだけでなく再発行まで含むか、段階的な移行計画があるか、運用に定着させる仕組みまで提案してくるかを見極める

「秘密情報の管理がずさんなのは分かっているが、どこから手をつければいいか分からない」という段階でも構いません。torcheees では既存プロダクトの診断から、継続的な改善支援まで、実際のコードとインフラ構成を確認した上で優先順位と概算費用をご提示します。お問い合わせフォームからご相談ください。