パスワードのない管理画面に残る4つのリスク

2026/10/20

個人ブログの管理画面を、Cloudflare Accessのメールワンタイムコードで保護しました。
それでも、表示されたログイン画面には「WordPressのデフォルトログイン画面みたいな怖さ」がありました。
確認して分かったのは、入口が見えることと、そこから侵入できることは分けて考える必要がある、ということです。
今回は、第三者に見える情報と残る4つのリスク、私が実施した対策を整理します。

第三者に見えるものを確認する

Cloudflare Accessは、アプリにアクセスできる人を制限する仕組みです。今回の管理画面では、許可したメールアドレスに届くワンタイムコード、つまり一度の認証に使うコードでログインします。管理画面用のパスワードを入力する方式ではありません。

不安のきっかけは、ログイン画面の見た目でした。Cloudflareであることに加えて、チーム名とアプリ名が表示されます。管理画面の入口がそのまま外に見えているように感じたのです。

そこで、印象ではなく、実際に何が見えるかを確認しました。

確認した項目	今回の画面や挙動
Cloudflareの利用	分かる。ただし公開ページの通信ヘッダからも元々分かる
チーム名・アプリ名	表示される
許可されたメールアドレス	表示されない
許可外のメールを入力した場合	画面の反応は同じで、コードは送られない

通信ヘッダは、ページの内容と一緒にやり取りされる付加情報です。Cloudflareの利用は、ログイン画面で初めて明かされる情報ではありませんでした。

また、今回確認した画面の反応からは、入力したメールアドレスが許可されているかを区別できません。「認証の入口がある」と分かることと、「誰が入れるかまで分かる」ことは別でした。

WordPressへの怖さを分解する

「WordPressのログイン画面みたい」という感覚を考え直すと、怖いのは画面そのものではありませんでした。私が連想していたのは、その先にある攻撃や運用の負担です。

例えば、パスワードを受け付ける入口には、候補を次々に試す「総当たり」や、別のサービスから漏れたパスワードを試す攻撃が考えられます。ユーザー名を外から調べられる「列挙」ができれば、攻撃対象も絞りやすくなります。

さらに、第三者製プラグインに既知の脆弱性、つまり悪用できる不具合がある場合や、必要な更新を自分で続けなければならないことも、不安の中身でした。これらがすべてのWordPress環境に当てはまるという意味ではありません。

大事なのは、どれも「入口の場所が知られている」という一点だけで起こる問題ではないことです。

入口を隠せば安心、と考えるだけでは、認証方法や更新の責任を見落とします。私が確認すべきだったのは、ログイン画面の雰囲気ではなく、何を渡せば認証を通過できるのか、誰がその仕組みを保守するのかでした。

Cloudflareが知られていないから安全、ではない

Cloudflareは企業でも広く使われており、仕組みも公開されています。「攻撃する人に知られていないから安全」という説明はできません。

今回の構成では、第三者がチーム名やアプリ名を知っても、それだけでは認証を通過できません。許可外のメールアドレスを入力してもコードは届かず、管理画面に対してパスワード候補を試す入口もありません。

この意味で、違いは「知られていないこと」ではなく、「知っただけではログインにつながる手を打てないこと」です。ただし、これはあらゆる攻撃手段が存在しない、という保証ではありません。

更新の担当も違います。提供側の仕組みに未知の穴が見つかった場合、その部分の修正は提供側がまとめて適用します。利用者が個別に認証基盤を更新し忘れる問題は避けられますが、修正されるまでの危険まで消えるわけではありません。

そして、Accessの先で動く私自身のコードは、引き続き私の責任です。認証を任せることと、管理画面全体の安全性を任せることは同じではありませんでした。

残る4つのリスクと、被害の範囲

パスワードをなくした後も、次のリスクは残ります。

リスク	考える必要があること
Cloudflareやメールのアカウント乗っ取り	設定を管理するアカウントと、コードの受信先を守る
提供側のゼロデイ	修正が間に合っていない未知の脆弱性は残りうる
自分のコードの穴	認証の先にある処理もレビューする
ログイン済み端末の乗っ取り	認証済みの状態を使われる可能性がある

アカウント乗っ取りへの対策として考えるのが、2要素認証です。これは、異なる種類の確認手段を組み合わせて本人確認をする方法です。Cloudflareだけでなく、コードが届くメールのアカウントも対策の対象になります。

自分のコードの穴は、仮定の話ではありません。実際に1件あり、公開前のレビューで塞ぎました。穴の詳細はここでは扱いませんが、Accessで入口を保護しただけでは、実装の確認を省けないことを示す出来事でした。

また、今回の管理画面で想定する被害の上限は、記事の改ざんと削除です。決済機能も個人情報も置いていません。

記事が壊されてもよい、という意味ではありません。ただ、何を失う可能性があるかを具体的にすると、不安の大きさだけで判断せずに済みます。この整理は、今回のブログの構成についてのものです。

私が実際に変更したこと

確認した内容を踏まえて、まずアプリ名を無難な名前に変えました。これは認証を強くする操作ではありません。外から見える表示に、必要以上の情報を持たせないための整理です。

次に、Cloudflareの2要素認証を有効にしました。管理画面のログイン方式だけでなく、その認証設定を管理する側のアカウントも守る必要があると考えたためです。メール側も対策が必要ですが、今回実施したこととして書けるのはCloudflare側の有効化です。

バックアップコードの保管方法も変えました。これは、通常の認証手段を使えなくなったときに備える復旧用のコードです。平文、つまりそのまま読めるファイルに置くのをやめ、OSのキーチェーンへ移しました。キーチェーンは、パスワードなどの秘密情報を保管する仕組みです。別途残した記録には、コードそのものではなく、置き場所だけを書きました。

設定中には、パスワード欄が貼り付けを受け付けず、作業が止まる場面もありました。このときはパスワードマネージャの自動入力で通せました。管理画面へのログインからパスワードをなくしても、設定作業でパスワードを扱う場面はありました。

見た目への不安から始まった確認ですが、実際の対策は、表示名の整理、アカウントの保護、復旧用コードの保管へと具体化しました。

今回の学び

ログイン画面が見えることと、認証を突破できることを分けて確認します。表示内容と認証の条件を、それぞれ書き出すと整理できます。
パスワードをなくしたら、認証の頼り先がどこへ移ったかを確認します。メールでコードを受け取るなら、そのメールアカウントも守る対象です。
提供側が更新する範囲と、自分が保守する範囲を分けます。認証を任せても、自分のコードのレビューは必要です。
復旧用コードは通常のメモと分けて保管し、置き場所の記録に秘密そのものを複製しないようにします。
「何となく怖い」で止めず、残るリスクと、侵入された場合に変更・削除されるものを具体的に確認します。