Vercelにデプロイした場合、セキュリティインシデントに関する今日の見出しが、多少の不安を引き起こしたかもしれません。
サプライチェーンに関するアラートがどれほど混乱を招くのかは、身をもって知っています。深呼吸してください。
ここでは、ノイズと事実を切り分け、今日からあなたのインフラを確実に守るために実際に取れる手順に焦点を当てます。
アプリケーションを保護するための、わかりやすい手順をご紹介します。
実際に何が起きたのか
手順に入る前に、確認済みの事実は以下のとおりです：
- 根本原因： Vercelは、Google WorkspaceのOAuth連携を含む、侵害されたサードパーティのAIツールを通じて社内システムへの不正アクセスが確認されたと述べています。
- 影響範囲： 「Sensitive（機密）」としてマークされた環境変数は暗号化された状態で保護されていました。しかし、標準または機密ではない環境変数は、攻撃者に公開されていた可能性があります。
- 主張： ShinyHuntersという名前を使う脅威アクターはVercelのデータを販売していると主張しています。Vercelは現在、この事態に積極的に対応しており、主要なサービスは引き続きオンラインのままです。
機密ではない変数が公開されていた可能性があるため、あなたの直近の最優先事項は、資格情報（クレデンシャル）の監査とローテーションです。
手順別の復旧ガイド
Step 1: Vercelの環境変数を監査する
Vercelのダッシュボードにログインし、稼働中のすべてのプロジェクトについて環境変数を確認してください。「Sensitive（機密）」フラグが明示的に付いていなかったものを探します。特に次に注意してください：
- データベース接続文字列（Postgres、MongoDB、Redis）
- サードパーティAPIキー（Stripe、SendGrid、OpenAI）
- 認証シークレットおよびJWTキー
Step 2: 上流の資格情報を取り消す
機密が「機密ではない」変数に保存されていた場合、Vercel内でそれを変更するだけでは不十分です。侵害されたキーを、発生元（ソース）で無効化する必要があります。
- サービスプロバイダー（AWS、Supabase、Stripeなど）に移動します。
- 古い資格情報を完全に取り消す（または削除する）
- まったく新しい資格情報を生成します。
Step 3: 更新し、「Sensitive」としてフラグを立てる
新しく生成したキーをVercelのプロジェクトに反映します。更新する際は、必ず変数を「Sensitive（機密）」としてマークするチェックボックスをオンにしてください。これにより、その値が保存時に暗号化され、以後ダッシュボードUIから隠されます。
Step 4: OAuth連携を監査する
この侵害は侵害されたWorkspaceアプリが起点だったため、この機会に自社チームの連携を整理しましょう。
- GitHubの組織設定を見直し、認識できないOAuthアプリを削除します。
- Google Workspaceの連携を確認します。
- チームがもはや使用していないサードパーティツールについてアクセスを取り消します。
Step 5: ログを監視する
今後数日間、アプリケーションとデータベースのログを注意深く監視してください。データベースにアクセスしている見慣れないIPアドレスや、API利用の予期しない急増を探します。これらは、漏えいしたキーが実際に使われている可能性を示す明確なサインです。
今後の対応
セキュリティインシデントはつらいものですが、手順立てて対処することが最善の防御策です。公開されてしまったキーをローテーションし、環境変数を厳格にロックダウンすることで、直近のリスクを遮断できます。チェックリストを実行し、ワークスペースを保護して、また構築に戻りましょう。
