エンタープライズiOSアプリ開発・端末導入・運用支援のリーディングカンパニー

静的化は一石三鳥

通常、セキュリティ(安全性)、パフォーマンス(高速性)、安定稼働(可用性)を確保したい場合、それぞれの用途ごとに全く異なる製品・サービスを個別に導入する必要があります。

例えば、WordPressサイトのセキュリティを強化するなら WAF(ウェブアプリケーションファイアーウォール) や IDS(侵入検知システム) や IPS(侵入防御システム) を導入、高速化させるならキャッシュサーバやリバースプロキシの導入といったようにです。

一方でWordPressを静的化する場合、それぞれ個別に導入する必要はありません。静的化は、安全性を向上させるだけでなく、結果的に可用性や応答性の向上にも及ぶからです。

安全性・応答性・可用性を同時に向上させられますので、静的化では初期費用やランニングコストを安価に抑えることができるのです。

CDNやリバースプロキシとの違い

静的化が、CDNやリバースプロキシと異なるのはその主目的です。

CDNやリバースプロキシをセキュリティ目的で使用することは余りないでしょう。なぜなら、キャッシュされていないリクエストは、そのまま元サーバに届くからです。この際、CDNやリバースプロキシは基本的に何の防御もしません。

リバースプロキシの設定で特定の攻撃パターンを拒否することもできますが、通常はWAFを導入するのが一般的です。

WAFとの違い

CMSもWebアプリケーションの一種ですので、昨今ではWordPressなどオープンソースなCMSとWAFをセットにして導入する事例が増えています。

しかし、WAFは完全ではありません。シグネチャと呼ばれる攻撃パターン文字列の定義にマッチしたhttp/httpsアクセスを遮断することで、攻撃の成立可能性を低くしているにすぎないからです。

残念ながら未知の攻撃やゼロデイ攻撃には対応できません。http/https層でWAFを通り抜ける攻撃が必ず存在します。脆弱性が発覚する度にWAFのシグネチャが更新されるのはこの為で、言わば脆弱性とのイタチごっこです。(これはWAFの費用が下がらない理由でもあります)

静的化によってサイトを守るesparでは、未知の攻撃にもゼロデイ攻撃にも耐性を持つことができます。CMSサイトを静的化してホスティングすることによって、http/https層での第三者攻撃が成立しない状態を作れるからです。

esparではその導入後、WordPressサーバ側にはIP制限とBasic/Digest認証の両方をかけることができます。また、esparのホスティング環境はプログラムやフレームワークを一切搭載しておらず、指定されたファイルを返すことしか行いません。

つまり、仮にCMSに脆弱性があったとしても論理的に攻撃できないだけでなく、静的ファイルしか返さないホスティング側に対しては論理的に攻撃が成立しないという状態を作り出すのです。

これが、イタチごっこを続けるしかないWAFと、静的化によってそもそも攻撃を成立しないようにする静的化との決定的な違いです。

侵入検知システム(IDS)や侵入防止システム(IPS)も同様に、イタチごっこの宿命からは逃れられません。不正は絶対に無くならないからです。これはソフトウェアのコピープロテクトとコピー解除ツールのイタチごっこに似ています。

セキュリティインシデントの本質に目を向ける

セキュリティ事故が起こる根本原因はどこにあるのでしょうか？

それは、攻撃が成立しうるWordPress環境をそのままネットに晒してしまうことです。

攻撃を避けたいなら、まずネットに晒す前に、理屈上安全といえる状態を最大限担保すべきでしょう。ネットに晒すまでもなくWebサイトを公開し発信できるのであれば、それが最も安全な選択肢です。

WordPress環境を数多の攻撃が発生するネットの世界に公開すべきではありません。弾丸飛び交う戦場に盾を持たせてまで送り込むのか、そもそも戦場に飛び込むことを割けるのか。どちらが安全かは自明ですね。