Vercelまわりでセキュリティの話題が出るたびに、『プラットフォーム側がどこまで守るのか』『利用者側は何を持つべきか』が曖昧なまま不安だけが先行しがちです。2026年6月時点のVercel公式ドキュメントを見ると、答えはかなり明確で、共有責任モデル、自動DDoS緩和、WAF、Attack Mode、Firewall Observabilityという形で役割分担と防御手段が整理されています。
この記事では、個別事件の真偽や推測ではなく、公式情報で確認できる防御機能と運用上の教訓に絞って、安全対策を見直します。タイトルは『事件から学ぶ』ですが、実際に重要なのはニュース消費ではなく、自社の設定と初動フローを点検できる状態にすることです。
1. まず押さえるべき前提は「共有責任モデル」
VercelのShared Responsibility Modelでは、顧客はデータ、アプリケーション、IAM、環境変数、ソースコード、サードパーティ連携、コンプライアンス対応を担い、Vercelは計算基盤、ストレージ、ネットワークなどのインフラ側を守ります。つまり、プラットフォームが強くても、アプリ側の認可設計、秘密情報の扱い、不要な権限付与、ログ不備は利用者側の責任です。
ここで見落とされやすいのは、Vercelの保護と、自社アプリの保護は別階層だということです。デプロイ基盤の安全性と、ユーザー向け管理画面の認証・認可、CMS接続、Webhookの許可範囲は同じではありません。事件を教訓化するなら、まず『どこまでがVercel、どこからが自社』を一枚の運用図に落とすところから始めるべきです。
2. 自動防御だけで終わらせず、Firewallを運用に組み込む
Vercel Firewallは、全リクエストに対してplatform-wide firewallとWAFを多層で適用します。公式ドキュメントでは、DDoS mitigation、IP blocking、custom rules、managed rulesetsの順でルールが効くと説明されています。平時は自動緩和に任せつつ、特定パスや特定条件だけ厳しくしたいときはWAFで足す、という考え方が基本です。
攻撃が明確になったときの追加手段がAttack Modeです。Attack Modeは全プランで使え、検索エンジンやWebhookプロバイダのようなknown botsは自動で通しつつ、通常のブラウザ利用者にはセキュリティチャレンジを要求します。しかも、Attack Modeでブロックされた通信は利用量にカウントされず、内部のFunctionsやCron Jobsからのリクエストは自動許可されます。『攻撃時に即座に一段防御を上げる』運用を設計しておく価値は高いです。
3. 監視・通知が弱いと、守れていても気づけない
守れているかどうかと、説明できるかどうかは別問題です。Firewall Observabilityでは、Overview、Traffic、Alertsから、適用ルール、イベント、Denied IPs、パス別トラフィック、JA4フィンガープリント、国別傾向などを見られます。さらにDDoS mitigationが10分で10万リクエスト超の悪性トラフィックを検知すると、アラートを生成し、WebhookやSlack経由で通知できます。
つまり、攻撃そのものを完全に防ぐことよりも、何が起きたかを5分〜30分で共有できる体制が重要です。ダッシュボードの存在だけでは足りず、誰がOverviewを見るか、どの閾値でAttack Modeを有効化するか、どのログを事後レビューへ残すかまで決めておく必要があります。
4. 開発体験を落とさずに実践したいチェックリスト
現実的なチェックポイントは6つあります。第一に、IAMとチーム権限を最小化すること。第二に、環境変数と外部接続を棚卸しし、不要な秘密情報を減らすこと。第三に、Preview、本番、管理画面、内部APIの公開範囲を分けること。第四に、Firewall Alertsの通知先をSlackまたはWebhookで必ず持つこと。第五に、Attack ModeやWAFルールを誰がいつ有効化するか決めること。第六に、事後レビュー用のログ保管先と担当者を決めることです。
AI機能やWebhookが多いアプリほど、公開エンドポイントが増え、Botやスパイクアクセスの影響を受けやすくなります。だからこそ『自動防御があるから大丈夫』ではなく、自社コード、認証、通知、権限、可視化をセットで回す必要があります。運用の粒度を少し上げるだけでも、事故耐性はかなり変わります。
5. 事件を消費せず、再発防止の設計に変える
ニュースを読むだけでは、次の攻撃に備えたことにはなりません。Vercelの公式情報をたどると、共有責任モデル、自動DDoS緩和、Attack Mode、Observability、Slack/Webhook通知まで、再発防止に必要な材料はかなり揃っています。差がつくのは、その材料を自社の初動手順と設定変更フローへ落とし込めるかどうかです。
クラウド開発基盤のセキュリティ設計や運用フローを見直したい場合は、 HelloCraftAIまでお問い合わせください 。権限整理、監視設計、インシデント初動の整備まで伴走できます。
