サーバーレス構成のセキュリティ｜Vercel・Supabase・Cloudflareを選ぶ理由と注意点

サーバーレス構成では、サーバーのOS更新、ネットワーク設備、DDoSへの基本的な防御をプロバイダーが担うため、少人数の会社でも自分たちで守る範囲を絞り込めます。一方で、アプリのコード、データへのアクセス制御、APIキーの管理は、利用する会社が自分で設定・管理します。サーバーレスにすれば安全になるのではなく、守る範囲が変わる、と捉えるのが正確です。

wrenは自社で運営するad-cre.aiとCS Copilot.aiで、Vercel・Supabase・Cloudflareを組み合わせたサーバーレス構成を採用し、データ分析とAI機能にGoogle Cloudを使っています。受託開発でも、お客様からAWSなどの指定がなければ同じ構成で作ります。本記事では、この構成を選んでいる理由をセキュリティの観点から説明し、利用者側に残る責任と注意点も合わせて整理します。（調査時点: 2026年10月）

サーバーレス構成とはどういうものか？

サーバーレスは、サーバーが存在しない構成ではありません。サーバーの調達・OSの管理・台数の増減をクラウド事業者に任せ、利用者はアプリのコードと設定だけを用意する形態を指します。リクエストが来たときに処理が起動し、使った分だけ課金されるサービスが多いのも特徴です。

従来の構成では、仮想サーバーを1台借りて、OS、Webサーバー、言語のランタイム、データベースを自分たちで入れて更新していました。サーバーレスでは、このうちOSから実行環境までをプロバイダーが管理します。利用者が触るのは、アプリのコード、データベースの中身と権限、各サービスの設定です。

wrenが使っているサービスと役割

Vercelアプリの配信・実行Supabaseデータベース・認証Cloudflare公開経路の防御・記録Google Cloudデータ分析・AI機能

本文で扱う技術の例です。ロゴは各技術の識別に使用し、公式サイトへリンクしています。提供元との提携・認定を示すものではありません。

wrenの構成は、役割ごとに専門のサービスを組み合わせています。

ad-cre.aiとCS Copilot.aiは、この構成で開発・運営しています。受託開発では、お客様の社内規定や既存のシステムに合わせてAWSなどを選ぶこともあり、指定がない案件ではこの構成を提案しています。

このコーポレートサイト自体もNext.jsで作り、Vercelで配信しています。PHPやWordPressのサーバーを持っていないため、2026年10月に公表されたPHPの脆弱性（php2shellの対応記事を参照）でも、自社サイトについての更新作業は発生しませんでした。

サーバーレスがセキュリティ面で合う理由

OSやミドルウェアの更新をプロバイダーが担う

自社でサーバーを管理すると、OSの脆弱性が公表されるたびに更新・再起動・動作確認が必要になります。担当者が休みの週や、別の案件で手が回らない時期にも、この作業は止められません。

サーバーレスでは、この更新がプロバイダーの責任です。Vercelは責任共有モデルで、計算資源・ストレージ・ネットワークの安全性と、基盤の定期的な更新を自社の責任としています。Supabaseも責任共有モデルで、OSの保守、インフラの監視、データベースのバックアップを自社が管理すると明記しています。

小さな会社にとって、サーバーの更新を担う専任者を置くのは負担が大きい作業です。その部分を、専任のセキュリティ部門を持つ事業者に任せられる点が、wrenがこの構成を選ぶ一番の理由です。

DDoSや不正な通信への防御が標準で付いている

大量の通信でサービスを止めるDDoS攻撃は、自前のサーバーで防ぐのが難しい攻撃です。

Vercelは、ネットワーク層からアプリ層（L3・L4・L7）のDDoSを、すべてのプランで自動的に緩和すると公式ドキュメントで説明しています。Firewallで遮断した通信は課金対象にならないとも書かれています。Cloudflareは2017年に、無料プランを含む全プランでDDoSの緩和を量の上限なしで提供すると発表し、2022年からはWAFのマネージドルールも全プランに提供しています。

どちらも、追加の機器を用意しなくても基本的な防御が働く状態から始められます。wrenでは独自ドメインへの通信をすべてCloudflare経由にし、WAFで不正な通信を遮断しています。

サービス同士が疎結合で、影響範囲を区切りやすい

サーバーレス構成では、配信・データベース・DNSなどを別々のサービスが担い、APIと認証情報で接続します。1台のサーバーにすべてが同居する構成と比べて、各サービスの役割と権限が分かれています。

この分離は、侵害が起きたときの影響範囲に関わります。たとえば配信側の環境変数が漏れた場合でも、そこに入っているのがデータベースの読み取りに必要な最小限の鍵だけなら、被害はその鍵の権限内に収まります。鍵を作り直して入れ替える作業も、サービス単位で進められます。1台のサーバーに侵入されて、OSの権限からデータベース、メール送信、バックアップまでたどられる、という形にはなりにくい構成です。

疎結合は運用面でも利点があります。データベースを別のサービスへ移す、DNSの事業者を替える、といった変更を、他の部分を止めずに進めやすくなります。

常時起動のサーバーと管理用の入口を持たない

自前のサーバーには、SSHなど管理用の接続口が必要です。パスワードの使い回しや、退職者の鍵の消し忘れがあると、そこが侵入口になります。

サーバーレス構成では、利用者がログインして操作するOSがありません。管理操作は各サービスの管理画面かCLIから行い、ログイン認証と2段階認証、チームの権限設定はサービス側の仕組みを使います。管理用の入口が各サービスのアカウントに集まるので、権限の棚卸しの対象もはっきりします。権限と退職者アカウントの見直しは、Webサービス事業者のセキュリティ対策で詳しく扱っています。

構成と変更履歴がGitに残る

Vercelでは、Gitのリポジトリにコードを反映すると自動でビルドと配信が行われ、プルリクエストごとにプレビュー環境が作られます。どの変更がいつ本番に出たかがGitの履歴と配信履歴に残り、問題があれば以前の配信に戻せます。

手作業でサーバーの設定を変えると、誰が何を変えたかが記録に残らないことがあります。変更をコードとして管理しておくと、障害やセキュリティ事故の調査で、原因の変更を特定しやすくなります。

通信と保存データの暗号化が既定で効いている

Vercelは通信中と保存時のデータの暗号化を、自社が管理するサービスの範囲で担うとしています。Supabaseも、データを保存時・通信時ともに暗号化すると責任共有モデルに書いています。自前のサーバーではTLS証明書の更新切れが起きがちですが、これらのサービスでは証明書の発行と更新も自動です。

利用者に残る責任はどこか？

プロバイダーが担うのは基盤までです。VercelもSupabaseも、データ、アプリのコード、アクセス管理は利用者の責任と定めています。

Vercelは、悪意ある通信で発生したコストへの対応も利用者の責任とし、利用額の上限設定（Spend Management）を有効にするよう求めています。実行時のログの保存期間も短いため、調査に備えるなら外部への転送（Log Drains）を設定します。

サーバーレスでも起きている事故

SupabaseのRLS未設定によるデータの公開

Supabaseでは、ブラウザから直接データベースのAPIを呼び出せます。このとき、テーブルにRow Level Security（RLS）が設定されていないと、公開されている鍵を使って誰でもデータを読み書きできてしまいます。

2025年には、AIでアプリを作るサービスLovableで作られた多数のアプリで、RLSの未設定や不十分な設定によりデータベースが外部から読める状態になっていたことが報告されました（CVE-2025-48757）。メールアドレスなどの個人情報が含まれていた事例もあります。Postgresやサービス基盤の欠陥ではなく、アクセス制御の設定の問題です。

Supabaseは、ブラウザ向けのpublishableキー（旧anonキー）はRLSの制限を受け、サーバー向けのsecretキー（旧service_roleキー）はすべてのRLSポリシーを迂回すると説明しています。secretキーをブラウザのコードやリポジトリに入れないことが前提です。AIでコードを書かせた場合に起きやすい問題は、AIで作った業務システムを本番に出す前の確認項目で扱っています。

環境変数の露出

Next.jsでは、NEXT_PUBLIC_で始まる環境変数はブラウザに送るコードに埋め込まれます。秘密にすべき鍵にこの接頭辞を付けると、誰でも閲覧できる状態になります。Vercelも、環境変数と秘密情報の扱いは利用者の責任と明記しています。

関数に与えた権限が広すぎる

OWASPのServerless Top 10は、サーバーレスの関数に必要以上の権限を与えることを主要なリスクに挙げています。関数に入力の検証漏れがあったとき、被害の大きさはその関数に与えた権限で決まります。読み取りだけの処理には読み取り権限だけを渡す、という原則は、サーバーレスでも変わりません。

万一データの漏洩が疑われるときは、情報漏洩時の初動と原因の切り分けの手順で、鍵の無効化と影響範囲の確認から進めてください。

サーバーレス構成のデメリット

サーバーレスはすべての業務に合うわけではありません。選ぶ前に、次の点を比べます。

依存の問題は、標準技術の上に作られたサービスを選ぶことで小さくできます。SupabaseはPostgreSQLそのものなので、データを他のPostgreSQL環境へ移せます。Next.jsもVercel以外の環境で動かせます。wrenがこの組み合わせを選んでいる理由の一つです。

wrenがデータ分析とAI機能をGoogle Cloudに分けているように、すべてを一つのサービスに寄せず、処理の性質に合うサービスを組み合わせることもできます。

wrenがこの構成で運用するときに決めていること

構成を選んだ時点で安全になるわけではないので、プロバイダーに任せられない部分は、運用のルールとして決めています。ad-cre.aiとCS Copilot.aiでは、次の5点を実施しています。

依存ライブラリの更新は、このコーポレートサイトでもlockfileで管理し、更新の要否を確認しています。具体的な手順はWebサービス事業者のセキュリティ対策に掲載しています。

構成の選定や見直しを相談するには

これから業務システムを作る場合も、既存のサーバー構成の保守に手が回らなくなっている場合も、扱うデータ、利用者数、処理の重さによって合う構成は変わります。wrenの受託開発では、構成の選定から開発、公開後の運用までを担当しています。

受託開発の相談フォームに、作りたいもの、または現在の構成と困っていることを書いてお送りください。どの部分をサーバーレスにし、どこを残すかの案をメールでお返しします。