WordPress等のCMSを静的化するサービス espar vault の新オプションについてプレスリリースを出しました。プレス本文はこちら。
WordPressセキュリティ強化の新形態！管理画面への全アクセスを別ドメイン化して攻撃対象面を限りなくゼロに近づける「隠蔽化オプション」の提供開始
(展示会で作成した espar vault のリーフレット)
長らく WordPress のセキュリティ分野でビジネスしておりますが、運用中のWordPressサイトを守る一つの理想形に到達できたと思っています。攻撃ができないとはどういうことか、少し技術的なことを紹介してみたいと思います。
閲覧系URLに加え、管理系URLも攻撃されないようにする
WordPress サイトをhttp/https層で見ると攻撃される箇所は2つに大別されます。
- 閲覧系URL
- 管理系URL
WordPress は1,2の両方でアクセスの度にPHPやDBが動作するため、常に攻撃が成立する可能性が孕んでいます。この状態を「サイト全体が攻撃対象面である」といい、WordPress の構造的な脆弱性です。
そこで、静的化技術を使って、主に1の側、つまり閲覧系URLでは原理的に攻撃が成立しないようにしてセキュリティを強固にするのが espar vault でした。
(静的化したファイルのみを別サーバに設置。PHPもDBも存在せず、攻撃は原則成立しない)
そして今回発表した「隠蔽化オプション」は、主に2の側ですね。管理系で原理的に攻撃を試みさせないようにするものです。「攻撃を成立させない」のではなく「攻撃を試みさせない」という点が、従来の防御手法とは一線を画している部分です。
どういうことか。
管理系URLだけを別ドメイン化する
WordPressサイトのURLが https://www.exmple.com/ なら、よく知られる通り管理画面は https://www.example.com/wp-admin/ で、管理系の重要なアクセスは https://www.example.com/wp-admin/〜 以下に集約されています。
ここも狙われるのです。
ですが、もし以下のように、管理画面だけ別ドメインでWordPressを運用できたらどうでしょう？
https://www.example.com/wp-admin/〜は原則全て404で応答するhttps://admin.sample.jp/wp-admin/〜でWordPress管理系のアクセスができるようにする
パッと見は謎に見えますが、要は管理系URLを根っこの部分(ドメイン)から別物にしてしまい、誰にも推測できないURLにするということです。で、関係者は https://www.example.com/wp-admin/ ではなく、管理系専用の https://admin.sample.jp/wp-admin/ という別ドメインからアクセスして、今までと全く同じ操作感で WordPress を操作します。
(WordPressに直接アクセスしなくても良い環境に隠蔽することでWordPressを守る、という発想)
全く関係ない別ドメインなのにそんなことができるのか？
はい。
普通のWebサーバではできないんですよね。Apache でも NGiNX でも不可能です。弊社が独自に開発した ホスト名置換型リバースプロキシ技術 で可能になりました。全く別のドメインにアクセスしているのに、WordPress の管理画面にアクセスができるようになります。
ちょっと不思議ですよね。
そんな管理系アクセス仲介専用サーバをお客様ごとに用意します。これなら、その全く別のドメインを知らない限り誰も管理画面にアクセスできないって理屈です。管理系URLには、攻撃者は攻撃を試みることすらできません。だって管理用URLが全く分からないのですから。
espar vault の静的化と合わせると、前述の攻撃されやすい2大ポイントはこうなります。
- 閲覧系URL → 静的化した結果が置かれる公開用サーバが応答
- 管理系URL → 隠蔽化オプションで用意した管理系専用サーバが応答
元々あった www.example.com のCMSサーバには原則、直接アクセスが一切届かなくなるんですね。なので、CMSサーバには全アクセスに対してIP制限とBasic認証を設定でき、より安全になります。
この構成で、攻撃するのは事実上不可能と言えるほどにWordPress サイトは強固になります。閲覧系への存在しないURLや管理系URLは全て404ですし、別に用意する管理系URLは推測不可能であると。
もちろん例外はあります。これを我々は「動的要素」と呼んでいます。問い合わせフォームから「送信」ボタンを押す瞬間とか、どうしてもその瞬間にPHPが動作しなければいけないURLパスってのがあったりします。ここは、リバースプロキシ技術を使ってWordPress本体にアクセスが届くようにします。
(本当に必要なURLパスのパターンでのみ通過するように設定するので、簡易の手動設定WAFみたいなもの)
そこが攻撃されないよう、やっぱり全て静的化できたほうがいい。だから静的化したページ上で JavaScript で動作する espar from を開発したという経緯があります。
このようにわずかな例外が生じる場合はあるものの、ほぼほぼ攻撃不可能な WordPress になることがご理解いただけるかと思います。
セキュリティで最も大切で有効な考え方
セキュリティに絶対はありません。
だから、何かを守りたい時、最も大切な考え方は、deny all, each allow の原則を貫くことです。まずは全てをいったん拒否(deny)し、個別に許可(allow)する。
家の玄関とか、まさにそうですよね。すべてをいったん拒否(鍵付き扉を設置)し、個別に許可(家族にだけ鍵を渡す)します。飛行機や万博のゲートもそうです。いったん拒否(ゲートでせき止め)し、個別に許可(持ち物検査して通す)します。
もちろん絶対はないですが、まず入り口の初手で「現実的に攻撃は不可」と言える状態までセキュリティをいっきに引き上げるのです。細かいことはその後です。このやり方が一番安全であることは、現実世界を見れば自明の理でしょう。
CMSやWebシステムの多くは、残念ながらこれができていません。allow all, each deny なんですよね。メールだってそうです。まず全部受け入れちゃう。そこから守ろうとする。そりゃ漏れますよ。
システムやメールの特性上、どうしても deny all を初手に持ってこれない場合もあるんですけどね。でも、情報発信が主体の CMS サイトならこれが比較的容易です。まず全部拒否(404)することにし、存在するページのURLだけ応答する、以上。というわけです。
まぁ、究極は「使わない」ですけど。ぶっちゃけるとWordPressをはじめCMSを使わないことです😁 SSGを使うか手書きで書いてHTMLファイルを設置するだけが一番安全です。でもそれはまだまだ現実的ではない。だから deny all, each allow で守りを固めてから使うべき、と弊社では考えています。
ということで、新たにリリースした espar vault の「隠蔽化オプション」についての解説でした。WordPress の使いやすさはそのままに、セキュリティを高めたいという場合に是非ご検討ください。「静的化」が前提になっているので、理論上の最高速度にスピードUPするというメリットもついてきて、一挙両得です😁