EmDashは本当に安全？100%と言い切れない理由とCloudflareの防御

「安全」とひとまとめにせず、止まらない・侵入されにくい・戻せるで見る

EmDash(エムダッシュ)は、記事や画像を管理するCMSです。「M-Dash」と聞こえることもありますが、正式な表記はEmDashです。安全性を考えるときは、製品名だけで判断せず、何を守る仕組みがあるかを見ると分かりやすくなります。

大量アクセスでサイトが止まる問題、管理画面へ不正に入られる問題、記事を誤って消す問題では、対策が違います。Cloudflareは通信と実行基盤を、EmDashはログインやプラグインの操作を守ります。そこへ更新や復旧の備えを重ねる構成です。

Cloudflareは、通信がサイトへ届く手前で対処できる

Cloudflareは、世界に広がるネットワークでWebサイトへの通信を受けます。EmDashをCloudflare Workers上で動かす場合も、この基盤を使います。Workersは、サーバーの設備を自社で管理せずにプログラムを動かせるサービスです。

大量の通信を見分けて、ネットワーク側で抑える

サイトを止めるために大量の通信を送りつける攻撃をDDoS（分散型サービス妨害）と呼びます。Cloudflareは通信量やリクエストの特徴を分析し、攻撃のパターンに応じた防御ルールをネットワークへ配ります。担当者が異常に気づいてから手作業で遮断するだけ、という仕組みではありません。DDoS対策の仕組み

自社の小さなサーバーだけで大量の通信を受ける構成と比べ、ネットワーク側で対処できるのは頼もしい点です。ただし、これは「どんな障害でもサイトが止まらない」という保証とは別の話になります。

不正なリクエストを調べるWAFを組み合わせる

WAFはWeb Application Firewallの略で、サイトへ届く要求を調べる防御機能です。例えば、入力欄を悪用しようとする通信をルールに照らして制限します。Cloudflareには更新される管理ルールや、URLなどで条件を決める独自ルールがあります。Cloudflare WAF

使える機能やルールの範囲はプランで異なり、設定も必要です。Cloudflareへ置いただけで、考えられる防御が全部有効になるわけではありません。ドメインの登録だけで対象の通信が保護されるとも限らないため、どのURLがCloudflareを通り、どのルールが適用されるかを制作担当者が確認します。

プログラムを動かす基盤にも、隔離の仕組みがある

Workersの実行環境は「isolate」で区切られていて、別のプログラムのメモリーへ勝手に触れない設計です。Cloudflareはこれとは別に、プロセス単位の制限なども加えて、防御を複数重ねています。Workersのセキュリティ設計

通信の防御だけでなく、動かす場所にも対策がある。Cloudflareの安全性を評価できる理由は、このように仕組みを分けて説明できるところです。一方、御社のサイトにあるプログラムの不備や権限設定の誤りまで、基盤が自動で直すわけではありません。

パスキーで不要になるのは、覚えて入力するパスワードです

EmDashは標準のログイン方法としてパスキーを使います。指紋・顔認証・端末のPINなどで本人確認する方式で、パスワードをサイトへ送って照合する必要がありません。認証情報がサイトのドメインに結びつくため、偽サイトにパスワードを入力させるフィッシングへの耐性があります。EmDashの認証ガイド

ログイン画面でIDとパスワードを毎回入力しないので、「そもそもログインIDがない」と感じるかもしれません。正確には、ユーザーのアカウントや権限は残ります。初回設定ではメールアドレスを登録し、CMS側は誰がログインしたかを管理しています。

パスキーの強みを使っても、端末の紛失やログイン済みのブラウザーへの対策は必要です。復旧用のメールを使う構成なら、そのメールアカウントも守ります。入口が変わるのであって、担当者ごとのアクセス管理までなくなるわけではないんですよ。

プラグインを隔離するのは、被害を広げにくくするため

プラグインは、CMSに機能を足す部品です。EmDashのサンドボックス型は、隔離用の実行環境を設定すると、本体から分けて動かせます。Cloudflare上ではDynamic Workerという仕組みを使います。プラグイン実行環境の設定

Cloudflare上でこの隔離を使うには、Workersの有料プランと、隔離用の実行環境を有効にする設定が必要です。

記事の読み書きや外部への通信は、宣言した権限を通じて行います。例えば、記事を読むだけの部品に、書き換えの権限まで渡さない設計ができます。ホスト側の環境変数などを直接読めない点も、秘密情報へ無制限に触れさせないための対策です。

ただし、EmDashには本体と同じ環境で動くネイティブ型もあり、こちらに同じ隔離はありません。「EmDashのプラグインは全部隔離される」と一括りにはできない点です。プラグイン形式の違い

さらに、隔離されていても、許可した操作は実行できます。記事の書き換え権限を与えたプラグインが、意図しない内容へ変更することまで防げるわけではありません。外部通信の許可も必要な宛先へ絞り、導入元と更新時の権限追加を確認します。権限で守れる範囲と限界

なぜ、それでも100%安全とは言えないのか

基盤が強くても、リスクがなくなるわけではありません。まだ見つかっていない不具合、担当者の誤設定、端末や接続トークンの流出は残ります。正しい権限での誤操作や、基盤そのものの障害にも、備えが要ります。

運営では、本体とプラグインの更新、必要最小限の権限、バックアップから戻す手順を決めます。AI連携用のトークンは接続の鍵に当たるので、人のパスキーとは別に管理するものです。EmDashの更新とバックアップの公式ガイドも、この運用を前提にしています。

制作会社には「100%安全ですか」に加えて、「何をCloudflareで防ぎ、何をCMSの設定で制限し、問題が起きたら誰が戻しますか」と聞いてみてください。担当と手順まで答えられる構成なら、導入後に何を続けるべきかも見えてきます。

侵入の入口や被害の広がりを減らす具体的な仕組みは、EmDashとCloudflareのどちらにもあります。安心して任せられるサイトかどうかは、その仕組みと運用の両方を確認して判断できます。実務での確認項目を知りたい方はEmDash導入前のセキュリティ確認を、動く部分を絞る考え方を知りたい方はCMSをニュースだけに入れる設計をご覧ください。