Vercelセキュリティインシデントから考える責任共有とリスク

2026/04/20 22:45

2026/4/20のVercelのセキュリティインシデントがあったので、その概要と教訓的なのを書いておきます。

以下の記事が公開され、数百のユーザーの環境変数の情報が漏洩した可能性があることが共有された。

Vercel CEOのGuillermo Rauch氏によると、概要はインシデントの流れは以下のようなものだったらしい。

これらのことから我々は何ができるのかを考えたい。

権限のスコープを絞る

まずは、社員のスコープやレイヤーが分からないのでなんとも言えないが、仮に従業員だったとして、顧客の環境変数の情報にアクセスできる状況が果たして顧客のインフラを預かる組織として適切だったのかは考える必要がありそうだ。

環境変数をSensitiveにすれば、顧客ですらも具体的な値にアクセスすることはできないのでこの対応をすることが推奨されていた。

改めて顧客のデータへのアクセスは最小限に絞ることの重要性を感じた。環境変数などセンシティブな内容であれば尚更だろう。

Context.aiの侵害に起因しているという点も注目すべきだろう。

Context.aiなどのAIサービスを利用することについてとやかくいうつもりはないが、利用SaaSが増えるごとに侵害のリスクが高まっていることを再認識すべきだろう。

サプライチェーン攻撃により、npmなどでの依存が増えるごとに比例してリスクも増えることがさらに明白になったがそれはSaaSにおいても同じことが言えると思う。

SaaSは便利なのでいろいろ試したくはなるが、その利便性とリスクを天秤にとって採用を考える必要があるだろう。

Context.aiを利用したことがないので断定はできないが、例えばプロンプト評価であればskillやエージェントに分析してもらうことで自前でもある程度検証ができるかもしれない。そもそもそのような評価は不要かもしれない...みたいに。

※これはエアプなので、貶める意図はないです。あくまでこういう考え方もできるかもという例です。

また会社での端末管理やSaaS導入のPolicyなどの重要性が高まっていくかもしれない。

今回の例で考えると流出はサプライチェーン攻撃を受けたVercel側の責任であるといえそうだが、環境変数Sensitiveにしていれば問題はないということだった。このSensitiveはつまるところ暗号化のようなものであるということを私ははじめて認識した。

ただし鍵管理の責任モデル・内部制御・鍵の復号タイミングについて明確化されていないので、この暗号化の仕組みについてはブラックボックス化されている部分も多い。

Vercelはこのようにブラックボックス化されている部分が多いので、その部分の責任共有モデルが曖昧という点に疑問が残る。

私も今回の件で、環境変数やデータの取り扱いの暗号化についてユーザー側に責任があるということを知った。

一方でAWSはSecrets ManagerやKMSといったドキュメントで責任共有モデルが示されている。

同じく内部ではブラックボックスな部分もあるが、KMS・IAM制御などユーザー側で制御できる部分が明記されている。

Vercelはこのような権限設定などを抽象化している。そこにAWSとの差別化があるとも思う。

まとめるとAWSは「責任を明確にしてユーザーに委ねる」設計であり、Vercelは「責任を抽象化して使いやすさを優先する」設計とも言える。

今回の件で私はどこまでをユーザー責任としているのか？というところを技術選定の一部に加えたいと思った次第だ。

今後Vercel側から何かしらのレポートが出るかもしれないので注目したい。

サービス設計という点では今回は環境変数の漏洩の可能性ということで、対応していて、接続しているSaaSの数も再認識した次第だった。

環境変数の数という意味では、そこが攻撃者からすると攻撃の糸口となりうるのでVercelをインフラのハブとして使用するリスクというのも考えた今回のインシデントだった。

Vercel単体でインフラを完結させようとすると構造的に、フロントエンド・API・env・トークンなどが集約されるアーキテクチャになるので侵害された時の影響範囲が大きいとも言えると思う(これはAWSも同じだが、Vercelの場合はサービスが集約されているという観点で)。

例えばVercelはあくまでフロントエンド配信としてのインフラとして考えるなどVercelの強みを生かしつつ、バックエンドの機密データに関してはAWSやその他に寄せるみたいな技術構成を考えるのも効果的かもしれない。

あまり一度のインシデントで重く考えたくはないが、このような技術選定の感覚は持っておきたいと思った。

あとVercelはとても好きなサービスなので、普通にこれらを踏まえても使っていきたいと思っているので今後のレポートや改善に期待したいと思っています。

そして今回はVercelのインシデントだったのでややVercel寄りに厳しい意見になってしまっていることを明記しておきます。

今回のインシデントは影響範囲が広く、インパクトのあるものでした。

セキュリティの

というシンプルなセキュリティ対策が有用であることも示したインシデントだったと思う。