相次ぐセキュリティインシデント：Webシステムに求められる「侵入防止」と「被害の最小化」

2026年に入り特にここ数ヶ月、国内企業のWebシステムを狙った不正アクセスや情報漏えいの報告が相次いでいます。
10月8日にはJPCERT / CCが「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」を公開し、翌9日にはIPAも不正アクセスによる情報漏えいを踏まえた緊急対策を呼びかけました。

こうしたインシデントを見ると古いシステムや更新されていないソフトウェアの問題に目が向きがちです。
もちろんそれらは大きなリスクですが、システムを新しくすれば安全になるというような単純な話でもないのです。

侵入を未然に防ぐための対策を徹底し、それでも万が一セキュリティ上の問題が発生した場合には被害を最小限に抑えられる多層防御の設計が重要だと思うのです。

今回はCloudflare、Supabase、そして2026年9月に正式リリースされたEmDashを例にこれからのWebセキュリティについて考えてみました。

不正アクセスは特別な企業だけが狙われるわけではない

JPCERT / CCが今回の注意喚起で取り上げているのは既知の脆弱性を狙った攻撃だけではなく、設定ファイルやバックアップファイルの探索、APIへの不正なリクエスト、窃取されたAPIキーの悪用、公開Webサーバーを足掛かりとした内部への侵入など攻撃手法は多岐にわたります。

特に気になるのは一般利用者向けのサービスに加えて、従業員向けの管理システムやBIツールなども被害対象になっている点です。
昨今はAIの発展に伴い、昔のようにGoogleにインデックス化しなければよい！という概念は消え去り、インターネットに公開されたシステムは即座に日常的に自動化された探索や攻撃を受ける可能性があります。

「うちのような小さなシステムは狙われない！」という考え方はもはや通用しないのです。

モダンな技術を使えば安全なのか

古いPHPやサポートが終了したフレームワークや長年アップデートされていないCMSには当然ながらリスクがあります。
ではNext.jsやAstroで構築しクラウドサービスを利用すれば安全なのでしょうか？

残念ながらそうとも限りません。😭

最新のフレームワークでも脆弱性は発見されますしAPIの認可処理に不備があれば本来アクセスできないデータを取得される可能性があります。
認証情報やAPIキーの管理を誤れば堅牢なクラウドサービスであっても被害につながるため、技術が新しいこととシステムが安全であることは別の問題なのです。

Cloudflareでアプリケーションの手前に防御を置く

CloudflareはCDNとして知られていますがWebアプリケーションのセキュリティを考えるうえでも重要な役割を担います。
例えばWAF（Web Application Firewall）によって不審なリクエストを検知・遮断したり、レート制限によって大量のアクセスを抑制したりできますし、Cloudflare Accessを利用すれば、社内向け管理画面などへのアクセスを認証済みの特定ユーザーに限定することも可能です。

とは言え、それで完璧では全くありません。😭
そもそも一般公開する必要のない管理画面を誰でもアクセスできる状態にしておくことがリスクとなります。

WAFがあればすべての攻撃を防げるわけではなく、正常な形式のリクエストを悪用した不正操作やアプリケーション固有の認可不備などは別途対策が必要です。
Cloudflareはアプリケーションの手前に防御を設ける仕組みであり、アプリケーション自体の安全性を保証するものではないのです。

Supabaseではデータベース側でもアクセスを制御する

ここで考えたいのがSupabaseで利用できるRLS（Row Level Security）です。
RLSはPostgreSQLが持つ機能でデータベースの行単位でアクセスできる範囲を制御できるため、例えば複数企業が利用する業務システムでA社のユーザーはA社のデータだけを参照できるといったルールをデータベース側にも設定できます。
アプリケーション側の認可処理に誤りがあった場合でも適切に設定されたRLSが追加の防御として機能します。

ただ..…RLSも設定すれば万能というものでもないのです。😭

Supabaseのsecret keyや従来のservice_roleキーは利用方法によってRLSを迂回できる強い権限を持つので、管理を誤ればRLSによる防御は成立しないのです。
テーブルの権限設定やポリシーのテストも欠かせません。

重要なのはアプリケーションだけに認可を任せずデータベースにも独立した制御を持たせることなのです。

EmDashが採用したプラグインを信用しない仕組み

2026年9月28日、Cloudflareの支援を受けて開発されているCMS「EmDash 1.0」がリリースされ、公式プラグインレジストリも公開されました！
私どももリリース時からフォローしており既にサイト実装しているためとても感慨深いです。

EmDashで多言語ブログを作った話〜SSRでも翻訳APIのコストを抑える方法〜
microCMSからEmDash + Cloudflareに移行してみた

EmDashで興味深いのは、プラグインのセキュリティモデルです。
従来型CMSでは、プラグインがCMS本体と近い権限で動作することがあり、プラグインの脆弱性がシステム全体に影響する原因になりますが、EmDashの公式レジストリから導入するプラグインはサンドボックス内で実行されます。
プラグインが利用できる機能やリソースを制限し必要な権限を明示することで、影響範囲を小さくする設計です。

もちろんEmDashにもサンドボックスを利用しないネイティブプラグインが存在し、すべてのプラグインが安全という意味ではありませんし、EmDash自体も登場して間もないCMSであり今後の運用実績やセキュリティ対応を見ていく必要があります。

それでもプラグインを最初から全面的には信用しないという設計思想は、これからのCMSを考えるうえで注目すべき点になります。

共通しているのは「すべてを信用しない」という考え方

Cloudflare、Supabase、EmDashは、それぞれ異なる役割を持つサービスですが、セキュリティの観点では共通した考え方が見えてきます。

Cloudflare： 不審なアクセスをアプリケーションの手前で制御する
Supabase： アプリケーションからのアクセスもデータベース側で権限制御する
EmDash： プラグインに必要以上の権限を与えず実行環境を分離する

いずれも一つの仕組みに安全性を任せきるのではなく、信頼できる範囲を限定するという考え方であり、これはゼロトラストや最小権限の原則にも通じているのではないでしょうか？

仮に認証を突破されても、すべての操作が許可されるわけではない。
仮にAPIに不備があっても、すべてのデータが取得できるわけではない。
仮にプラグインに脆弱性があっても、システム全体を操作できるわけではない。

こうした境界を設けることでひとつの問題がシステム全体の被害につながるリスクを抑えます。

まとめ：侵入を防ぎ、万が一の被害も最小限に

Reactにした！Next.jsにした！クラウドに移行した！
こうした技術更新にも意味はありますが、（本当に一昔前のように思えてきますが、）フレームワークやインフラを置き換えただけでは十分なモダン化とは言えないので、認証、認可、API、データベース、外部サービスと、それぞれの責任と権限を整理しひとつの侵害が他の領域へ広がりにくい構造を作ることが重要だと思います。

セキュリティ対策に絶対はありません。
だからこそ侵入を未然に防ぐための対策を重ね、万が一問題が発生した場合でも被害の拡大を防げる多層防御の設計が求められます。

CloudflareもSupabaseもEmDashも万能ではありませんが、これらの技術には必要な権限だけを与え役割ごとに境界を設けるための仕組みがあります。

リベロジックではWebシステムの構築にあたって、単に新しい技術を採用するだけではなくこうした責任分離や多層防御を重視しています。

セキュリティインシデントが相次ぐ今、Webシステムのモダン化を考える際には、「何の技術を使うか」だけでなく、「どこまでを信用する設計になっているか」にも目を向ける必要があるのではないでしょうか。