静的化が最強のWebサイトセキュリティと信じて疑わない昨今です。こだわり続けて1年強でしょうか。ようやく理想の形に近づけた気がします。
エスパーと読みます。Elastic Static PAge Renderer の頭文字(?)をとって espar。タイトルの通りですがCMSの静的化サービスです。本日付でリリースしてまして、プレスもプレスリリースのページ(任意のCMSを静的化して第三者攻撃を無効化できるサービス「espar」をリリース)からご覧頂けますので宜しければ御覧下さい。
だいぶ長文になりますが、以下に詳細をご紹介します。まず espar の静的化ホスティングという仕組みについて。
静的化ホスティングって？
このブログをご覧頂いている方であれば図を見て頂くのが一番早いかも知れません。
従来の静的化とは全く異なるアプローチで静的化し、攻撃を無効化します。仕組みは以下。
- CMSでの更新のたびに適宜静的化してホスティング
- DNS設定変更により、サイト訪問者はesparのホスティング環境から応答を受け取る
- CMSサーバは管理者とesparのアクセス以外を全て拒否する (IP制限/Basic認証)
- サーバサイドプログラムやフレームワークが一切存在しないため脆弱性を狙った攻撃は成立しない
- 攻撃者はCMSサーバの所在が分からない (仮に所在が分かっても3.の制限でアクセス不可)
これまでも色んな静的化アプローチがありました。
個人的にはどれも一長一短。Aは黒い画面(ターミナル)必須で敷居が高く、Bは問合せフォーム等に課題が残り、Cは引越し前提にするのは難しいし前者のNORENとかだと超高額だし…と。
Aはホント色々やって勉強会もしましたがエンジニア以外は無理と結論を出しました。BのアプローチでWP Guardというプラグイン製品も出しましたが何か違う感は残っていました。
なので今回、外から静的化することにしました。…もう力技ですね(笑)
弊社製エンジンで外から静的化、そしてそのまま静的化したファイル群を全部ホスティング。この構成なら、専用の配信サーバ(ステージングサーバ)を用意する必要はありませんし、CMSの引越しも必要なく従来のCMSをそのまま使い続けられます。ぶっちゃけCMSでなくてもWebサイトとして機能しているサイトなら何でもokですね。
CMS側とDNSの設定を少し変えて、アクセスを全てesparのホスティング側で受ける構成になります。CMSサーバ側はIP制限やBasic/Digest認証で閉じるとか、ぶっちゃけ社内ローカルに移設して貰っても大丈夫、だから悪意ある第三者はCMSのサーバに辿り着くことすらできないよね…という訳です。
勿論、セキュリティに完璧はありませんので、社内に物理的に侵入されてftpアカウントパスワードまで盗られたとか、リクエスト元IPを詐称されたうえBasic/Digest認証の情報まで漏れちゃったなんて事になればどうしようもないですが。
既存のCMSをそのまま使えて、CMSの種類を問わず静的化して、ホスティングまでしてくれる…というのが他にないesparの新規性。既存のCMSに何も強いることなく連携して安全性を最大化しましょってコンセプトです。
外からの静的化って？
実は前述の構成を実現するのに必要不可欠なのが、外から静的化するクオリティ(再現性)です。TOPページからサイトのツリーを解析し、各ページに必要なリソース(画像/動画/js/css等)を全部取ってくるエンジン、これを完全に内製しました。
開発者の方なら wget などのツールがあるのをご存知かと思いますが、静的化をつきつめようとすると実は不十分なんですよね。例えば、
- css で background-image に指定された画像ファイル
- HTML5 の SVGタグやdata-属性
などがその例。wgetでは取ってこれません。他のツールも同様。何かしら欠けてるのです。
esparはこれらにも対応しているのと、何より内製ですので万が一静的化NGだった場合でも、調査して対応が可能だということです。esparが Elastic(柔軟な) たるゆえんですね。
問合せフォームは？
これまでの静的化アプローチでは余り考慮されてこなかったことです。フォームとなるとどうしても php や perl などサーバサイドに頼らざるを得ませんでした。
esparは、静的化しても問合せフォームが機能する仕組み(jsのライブラリ)を一緒に提供します。
- 指定のjsタグをコピペする
- <form> タグに指定のクラスを追加
- 各 <input> タグに指定のクラスを追加 (validation条件とか)
をするだけで指定のメールアドレスにメールが届く仕組みを標準搭載してます。実装的には入力されたデータを元に弊社サーバを介してメール送信します。送信やバリデーション、エラーの表示等にサーバサイドプログラム(phpやperl)は必要ありません。
既にウチのオフィシャルサイトの問合せフォームはこれで動いてます。
(例えば、input要素に email クラスを指定すると自動でバリデーションする。phpやperlは必要ない)
書きながら思いましたが、静的サイトジェネレータで作られたサイト向けに、この機能単体でも御提供する意味があったりするかも知れませんね。
問合せフォーム以外の動的要素は？
静的化で更に悩ましいのが、問合せフォームのようにパターン化できるもの以外に動的要素が存在するケース。商品検索ページとかページ内検索とかはその典型ですね。
これらも頑張れば静的化(js化)できます。前者はKintoneとかクラウド上のDBにデータを引っ越してjsで実装とか、後者はGoogleのカスタム検索とか。でもその為に数十万円かけて作り直すとかは有り得ない訳です。
そういった場合に、リスクと利便はトレードオフという原則を御理解頂いた上で、指定したURLパスだけ元のCMSサイトに代理アクセスして返答するプロキシ機能をご用意しました。
絵にすると、つまりこういうことですね。静と動の共存です。
例えば、search.php?key=espar みたいなリクエストを受けた場合にそのままCMS側に転送します。リダイレクトではなくプロキシなので、アクセス元はesparになるってのがポイント。CMS側のBasic認証やIP制限を弱くする必要はありません。
でも一点心配があります。ここに、SQLインジェクション等の脆弱性攻撃を意図したリクエストが転送されてきたらどうするか。search.php?key=’ OR 1 = 1； とかそういうのですね。
そこはもうトレードオフです…という割り切りをしたとしても、全URLに対してフルオープンしている状態より随分マシ(指定URLパス以外は静的化されるので)なのですが、そうは言っても…というのが正直なところ。僕も利用者視点に立てば同じことを思いますから。
そこで、esparがプロキシ転送する直前にWAFを挟むことにしました(上図)。OWASP の core ruleset に準拠したものをベースに構築しており、またサイト毎の独自拡張もできる仕組みにしてるので随時対応も可能です。これなら、安心ですよね。
という訳で、動的要素が存在する場合については、トレードオフであることを御理解頂いた上で
- Webサイトは出来る限り全部静的化を目指す
- どうしても残る動的箇所のURLパスに限りプロキシでCMS側に転送
- 転送時にはWAFで一般的な攻撃は防御する
こんな優先順位でやりましょうと。これで、95%は静的化してますとか、まだ70%ですとか、そういう静動混在が可能になる訳です。段階的に全静的化を目指すことができます。動的部分だけホスト名を別にして下さいとか無茶な話にはなりません。
esparが目指すもの
だいぶ長文になってきたので最後にesparで目指していることを書いて筆を置きます。
無理ゲーだろと言われそうですが、esparは「情報発信を主体とするあらゆるWebサイトの静的化」を目指しています。つまり、html/css/js でWebサイトの動作を静的に完結させること。そうすれば、Webサイトに起因する情報漏洩問題も改ざん問題も消え失せます。
攻撃が成立しないのですから。
Webの脆弱性による被害とは『サーバサイドプログラムを意図しない形で悪意ある第三者に動作させられてしまうこと』です。ならば、サーバサイドプログラムのないサーバでサイトを公開し更新もできる仕組みを作れば良い。それがepsarのコンセプトです。
多少のインタラクションが発生するサイトでも、kintone や Google SpreadSheet などセキュリティリスクを転嫁できるクラウドサービスにjs使ってAPI連携させれば、静的化できちゃいますしね。
CMSとは、Content Management System の略です。つまりコンテンツの管理システムです。コンテンツを管理することが本来の役割であり、コンテンツを配信する役割を無理に担う必要はありません。そのややこしい(そして一筋縄ではいかない)「配信」という役割まで同じサーバでやろうとするから、インターネットにCMSサーバを晒す必要があり、その結果攻撃にあってしまうのです。
然るべき静的ファイル群を生成し、それらの配信を委託できるサーバがあれば、CMSをインターネットにフルオープンで晒す必要なんて無いし、CMSは今ほど神経質にセキュリティを気にする必要なんて無いのです。全く気にしないことを推奨はできませんが、少なくとも今ほど「常に最新バージョンにするように！」と現場を無視した無理を強いて、何の売り上げにも繋がらない非生産的なCMSメンテナンスに多くの貴重なリソースが割かれる現状は改善できる筈です。
この議論は深掘りすると、CDNとかリバースプロキシとどう違うんだという話になるんですが、そのあたりはこちらのサービス解説ページをご覧頂ければと思います。
以上、長々と書きましたが新サービス espar の御紹介でした。今後ともどうぞ宜しくお願い致します。
