Web サイト・アプリの環境変数の注意点！APIキー・認証情報の棚卸しから始めるシークレット管理

こんにちは、ゼノクリース合同会社の齋藤です。このコラム記事では、最新の Web セキュリティに関する内容を紹介し、企業のサイトを守るための考え方と実践方法をご紹介します。

2026 年 4 月に Vercel はセキュリティインシデントに関する情報を公開しました。公式発表によると、第三者 AI ツールの侵害を起点に Vercel の一部環境へ不正アクセスがあり、sensitive（後述）として扱われていなかった環境変数について、API キー、トークン、データベース認証情報、署名鍵などを潜在的に露出したものとして扱い、ローテーションするよう案内しています。

Vercel April 2026 security incident | Vercel Knowledge Base

Vercel は Next.js などの世界的に有名な OSS を開発している会社で、さまざまな Web サイト・Web アプリをホスティングできるサービス（これも社名と同じ Vercel という名前）を運営しています。

また、sensitive とは Vercel の環境変数の設定のことで、「一度設定したらもう参照できない」というものです。この方法で設定することにより、例えば「Vercel アカウントに不正ログインされてしまっても、環境変数に入れた API キーなどの機密情報を見られずに済む」という効果があります。

環境変数と Secrets、その注意点

ここでは、API キーや DB パスワードなどの機密情報のことを Secrets と呼ぶことにします。

この記事で取り上げたいのは、特定サービスの是非ではありません。今回の事案から学べるのは、環境変数、CI/CD の Secrets、SaaS の管理画面、サーバー上の設定ファイルなどに散らばる認証情報を、どのように管理すべきかという点です。

環境変数 (Environment Variables) は、アプリケーションに値を渡すための仕組みです。一方で、API キーや DB パスワード、OAuth トークン、Webhook 署名鍵などは、単なる設定値ではなく Secrets です。つまり、環境変数に入れているかどうかよりも、「その Secrets を誰が管理し、どこで使われ、どう更新し、緊急時にどう止めるか」が重要になります。

OWASP の Secrets Management Cheat Sheet でも、Secrets はソースコード、設定ファイル、CI/CD、クラウド環境などに散らばりやすく、保管・配布・監査・ローテーション・管理を中央集約する必要があると説明されています。また、ローテーションは新しい Secrets の作成、設定、テスト、完了という複数ステップで安全に進めるべきものとされています。

WordPress にも Secrets はたくさんある

WordPress を運用していると、wp-config.php というファイルを見たことがある方も多いと思います。WordPress 公式ドキュメントでも、wp-config.php は WordPress の重要なファイルの 1 つであり、データベース接続情報など、サイトの基本設定を含むファイルと紹介されています。

実際、WordPress の設定例では、DB_NAME、DB_USER、DB_PASSWORD、DB_HOST のようなデータベース接続情報が wp-config.php に記述されます。また、ログイン状態や Cookie の安全性に関わる認証キー・ソルトも、この設定ファイルに含まれます。

• wp-config.php – Common APIs Handbook | Developer.WordPress.org
• Editing wp-config.php – Advanced Administration Handbook | Developer.WordPress.org

そのため、WordPress の設定ファイルには、サイトを動かすために必要な情報だけでなく、漏えいすると影響の大きい情報が集まっています。

さらに実際の運用では、ここに SMTP のパスワード、外部 API キー、決済サービスの秘密鍵、S3 や外部ストレージ連携の認証情報、フォーム連携のトークンなどが加わることもあります。そうするともはや、wp-config.php や .env は「便利な設定ファイル」ではなく、「Secrets の保管場所」になっていきます。

環境変数に入れたら安全、ではない

よくある誤解として、「wp-config.php, .env ファイルなど、環境変数を記載しているファイルを Git にコミットせず、環境変数に入れているから安全」というものがあります。

もちろん、その対策は重要です。GitHub などリモートで Git リポジトリを扱うことのできるサービスにシークレットなどの値をアップしてしまうことは大変危険ですし、誤って public リポジトリにしてしまうなど、ミスで流出してしまうリスクもあります。

しかし、これらのファイルの取り扱いを気を付けるだけでは不十分です。例えば、次のようなケースを考えてみてください。

• 制作会社・保守会社の担当者が、本番サーバーに SSH で入れる
• CI/CD の設定画面に API キーが登録されている
• バックアップファイルに古い wp-config.php が残っている
• ステージング環境と本番環境で同じ DB パスワードを使っている
• 退職者や過去の委託先が、まだクラウドや GitHub にアクセスできる

これらはすべて、Secrets の漏えい・悪用につながり得るポイントです。開発者から見ると当たり前の設定欄でも、攻撃者から見ると、そこには本番環境への鍵が並んでいる可能性があります。

Web 担当者が今すぐ確認すべき 5 つのポイント

また、今回の話はエンジニアだけが意識しておくべき問題ではありません。Web 担当者、マーケティング担当者、情報システム部門、制作会社との窓口になっている方も当事者です。

1) まず Secrets の棚卸しをする

最初にやるべきことは、どの Secrets が存在するかを洗い出すことです。怖いのは、漏えいそのものよりも、「漏えいしたときに何を止めればよいか分からないこと」です。

2) Secrets の正本を決める

次に、Secrets をどこで管理するかを決めます。すべてを一気に移行できない場合でも、「本番 DB パスワードだけは AWS の Secrets Manager で管理する」「wp-config.php はこのように管理する」といった段階的な対応は可能です。

3) 本番・検証・開発環境で Secrets を分ける

開発時の利便性のために本番環境とステージング環境で同じ認証情報を使っているケースは、意外と多いです。

しかしステージング環境は本番よりも多くの人が触れることがあり、アクセス制御も緩くなりがちです。そこで本番と同じ DB パスワードや API キーを使っていると、ステージング環境の事故が本番環境に波及してしまいます。

本番・検証・開発環境では、きちんと Secrets は分けましょう。

4) ローテーション手順をまとめる

Secrets は、漏えいしたときだけ慌てて変えるものではありません。

どのキーを、誰が、どの順番で、どのタイミングで変更するのか。変更後にどの画面・フォーム・決済・メール送信・管理画面ログインを確認するのか。旧キーをいつ無効化するのか。ここまで決めておかないと、「変えたつもりだが一部の環境では古いキーが残っていた」「旧キーを消したらフォーム送信が止まった」といった事故が起こります。

あらかじめきちんと手順をまとめておきましょう。

5) 委託先・退職者・過去プロジェクトの権限を見直す

気を付けなければならないのが、人と組織の権限です。

Web サイト運用では、社内担当者だけでなく、制作会社、保守会社、広告代理店、計測タグの担当者、外部エンジニアなど、さまざまな関係者が関わります。プロジェクト終了後も、GitHub、AWS、WordPress 管理画面、FTP、SSH、SaaS 管理画面へのアクセスが残っていることがあります。誰が見られるか、誰が変更できるか、誰がローテーションできるかを決めておく必要があります。

まとめ 

今回の Vercel 事案は、Vercel ユーザーだけが気にすべき話ではありません。WordPress で Web サイトを運用している企業にとっても、「環境変数」「設定ファイル」「API キー」「DB パスワード」をどう管理するかを見直す良いきっかけになります。

大事なのは、Secrets を「どこかに置いておく値」として扱わないことです。Secrets にはライフサイクルがあります。作る、渡す、使う、監視する、ローテーションする、無効化する。この一連の流れを、Web 運用の中に組み込む必要があります。

GMOプライム・ストラテジーでは、こうした運用の標準化や継続的なセキュリティ対応を支援するサービスを提供しています。ぜひご活用いただき、運用の見直しのきっかけにしてみてください。

• CMS プラットフォーム統合サービス（増え続ける CMS 環境を共通ルールのもとで高速かつ安全に運用するためのサービス）
• 簡易脆弱性診断（WordPress の脆弱性を無料で診断）
• Webガバナンスガイドライン