10月に発表しました、WordPressサイトへの第三者攻撃を無効化するというセキュリティ強化サービス WP Guard でトライアル環境の提供を始めます。

僕らは、WordPressをはじめとする動的CMSを使ったサイト構築に一石を投じたいと思っています。

その一石とは、サイト公開の在り方。公開用サーバを別途用意して、CMS部分(プログラムやDB)をオープンなネットの世界から隔離。CMS側で静的化したページ群を公開サーバに都度転送するという考え方のこと。

大半を占める情報発信系サイトにおいては、このアーキテクチャに勝るセキュリティ施策はありません。(超)高額な法人向けソリューションに同様のものがありますが、小中規模のサイトでも同じことができたほうがいいに決まってます。

WP Guard の仕組みは絵として描くとこんな感じで、前述のコンセプトをWordPress環境で手軽に実現できるようになっています。

そんなWP Guardですが、発表当初にはオフィシャルサイトを立ち上げただけで、サイト記載の内容が御客様にお伝えするモノの全てでした。ただ、やはり…

自由に触って頂く環境があったほうがいい

静的化という行為や、公開サーバが分離されているという仕掛け、いずれもなかなか想像しにくいのが正直なところです。

そこで少しでも WP Guard の世界観を体験して頂くべく、WordPressサーバと公開サーバのセットをトライアル環境としてご提供を開始することにしました。(上図参照)

WP Guardサイトの専用フォームから申し込んで頂いた皆様にトライアル環境をご用意致します。トライアル環境の有効期間は、申し込み日の翌月末実まで。(例えば12月5日にお申込み頂くと翌1月末まで)

勿論、WordPressサーバには、WP Guard のプラグインをインストール済みで、公開サーバとの連携も設定済みの環境になってます。

(トライアル環境のWordPress画面。トライアル環境の使い方エントリも予め投稿されている)

WordPressは最新版のv4.6.1(随時追随予定)。管理アカウントもご提供しますので、記事や固定ページを追加したり、テーマを変更したり、プラグインをインストールしたりと管理画面から自由に操作して頂ける、申込者様ごとの個別環境となります。

仕組み的にはもう、WordPressのホスティングサービス始めました…に近いかもですね :-)

• 公開サーバ : http://demo001.wpguard.biz/
• WordPressサーバ : http://private-demo001.wpguard.biz/

という感じで2台のサーバをご用意。この例で言うとURLの demo001 の部分の文字列をお申込時に指定して頂きます。

この2台のサーバで、後者のWordPress側をどれだけ触っても前者が全く影響しないこと、さらに後者の管理画面から「反映」ボタンを押してはじめて 静的化 と 公開サーバへの反映 が行われること、この一連の動きを見て頂けます。

また、申込時に御要望として書いて頂ければ、WordPressサーバ側に認証をかけて、固定IPからしかアクセスできないようにすることも可能です。

(Thanks! the photo on flickr by John Seb Barber CC BY-SA 2.0)

公開サーバを別にするメリット

実は、公開サーバを別立てにすると、安全度が高まる以外にもメリットがあります。

公開サーバが別なので、CMS側をどれだけ適当にいじっても、そして万が一壊れるようなことがあったとしても、公開サイトには全く影響がないのです。これは、 サイト閲覧不可時間をほぼゼロにできる ことを意味します。

WordPress本体のアップデートや、テーマ変更とかプラグイン更新とか、変更する時って普通は相当怖いですよね。いきなりサイトが見れなくなったりしますから。でも、公開用サーバ分離型の構成ならそういう心配はありません。公開サーバに静的化されたページ群が存在していますから。安心してWordPress側をいじることができるというわけです。

よくよく考えてみれば、ECサイトや会員サイトでない限り、情報発信用サイトの為にCMSをそのままインターネットに晒す理由は余りないのですよね。

弊社では、早晩、静的化を前提とするWeb構築が普通になるとみています。前述の通り、既に高価格帯の企業向けCMSではその兆候が随分前からありますし。でも高額過ぎてとても手が届かない層があります。

技術的な核心は凄まじく、静的化技術の進歩やインフラ低価格化の進行は、中堅・小規模サイトでも公開サーバ分離型構築を当たり前のものとする推進力になるのかも知れません。

仮想化の最新テクノロジを駆使

最後にちょっと技術的な話を。

今回のトライアル環境基盤の構築にあたり、今トレンドのDockerコンテナと、それを管理するAWS ECSを使っています。

トライアル環境を作ろうと思うと、サーバ立てて、WordPress環境を作って、初期設定して、プラグインも入れて、公開サーバも立てて設定して、2台のサーバの連携も設定して…と一連の作業が必要ですが、これを全部手作業でやっていたら日が暮れてしまいます。

この一連の作業をワンステップで高速実行できるようにし、しかも有期限で当該サーバをカンタンに(言葉は悪いですが)捨てられるという軽さも欲しい、そんな動機でDockerコンテナ技術を採用しました。

この構築に少し時間がかかり、トライアル環境のご提供がリリース時から少しずれました。ただ、時間かけて作ったおかげで、上記のトライアル環境の構築は社内でボタンを1つポンッと押すだけでできるようになってます。(ビジネス的な面から2営業日頂くことにしてますが)

担当した @t0shiya はすっかり Docker の魅力に魅せられたようです。で、サーバ維持費が気になる経営者としても、ECSはよくできてると感じますね。コンテナ基盤のエンジンとしてEC2を増強していくだけでいいというのが何とも素敵。個別にEC2でサーバを立てていくよりもリソースの無駄遣いが発生しにくいと思います。

という訳で、WordPressサイトを静的化する WP Guard のトライアル環境ご提供開始のお知らせでした。法人様じゃなくても全然結構です。ブロガーさんはじめ個人の方でもお気軽にお申込み頂ければと思います。

トライアルお申込みのページからお気軽にどうぞっ！

また、WordPressに限らずWebサイトの静的化に興味がおありでしたらお気軽にお問い合わせ下さい。

昨日発表した WP Guard ですが、Web担当者Forumさんに掲載頂いたり、IT系のメディアサイトに掲載頂いたりしたからか、お陰様で早速お問い合わせを頂くなどしております。取り上げて頂いたメディア様、有難うございます。

(via Wikimedia Commons. Thanks Renee French. CC BY 3.0)

さて WP Guard ですが、コア部分はGo言語で開発してます。上はお馴染みGo言語の象徴Gopherくん。可愛いなぁ…って話はさておきGo言語も2009年登場らしいですからもう7年ですね。早いです。

誰得か分からない話ですが、今回ウチがなぜGo言語を選択したのか備忘録を兼ねて書いてみようと思います。何かの参考になれば幸いです。

昨日のエントリで WP Guard に内包される的化エンジン espar は

いわゆるクローラーに近いものなので

と書いたのですが、実のところクローラーです。ただWebサイトの静的化を目的にしてるので従来のクローラーとは若干違うんですね。元々は、既存のモノを駆使する方法も検討してたのですが、要件を満たせず結局ゼロベースで作ることにした次第なのです。

作るぞ！となった時、顧客満足とビジネス推進という観点で考えたのは5つのことでした。

1. デプロイがし易いこと

今回、静的化エンジンを御客様環境に入れて頂き、稼働させる為のライセンスを発行するという形態を前提にしてました。実行は御客様サーバ。WordPressをはじめCMSが稼働している環境それぞれで簡単に動くのが良い。フレームワークはこれ、ライブラリはこれ、そのインストールはこう、設定はこう…という環境構築の手間を極力無くしたかったのです。

2. クロスプラットフォームに対応すること

前述の通りエンジン配布を考えてましたので、御客様の環境によって使えないとかは極力避けたいなと。動作環境の制約はビジネス拡大シーンで制約になる、ということを以前のビジネス(SYNCNEL)で学んでいたので、過度な労力なくLinuxでもFreeBSDでも、WinでもMacでも動かせるようにしたいと考えました。

3. 並列処理の実装が容易であること

全ページを漏れ無く静的化する際に、1ページずつ順番に処理をしてたら時間がかかります。高速な処理の為に、同時並行で処理しながら「もうそのページは静的化終わったよ」と協調して無駄なく動けることも必要でした。並列処理は往々にしてカオスな世界になりがちですが、それをシンプルに実現できることも重視しました。

4. コンパイル型言語であること

これはビジネス要件の色合いが強いですね。ソースコードをそのままばらまく事になってしまうのは避けたかったという思いがあります。ウチが困る…というよりも販売頂くパートナーさんを困らせる事になるからですね。

5. 未経験なら学習コストが低いこと

既存言語なら別にokですが、新しい言語を学ぶなら学習コストは低いに越したことはありません。ネット界隈や書籍を含め、先人の知恵の量が結構重要。情報が多ければ学習コストは下がります。将来の人財戦略にも影響出るだろうし、マイナー過ぎる言語も避けたいと思いました。

いわゆるLL言語系はまっさきに除外され、javaやscalaも考えなくは無かったのですが、全体を良い感じに満たすのがGo言語だったと。というか正直、まさにGo言語で何か作るならこういうものを…というお手本的なカテゴリのものだったこともあり、Go言語以外に選択肢は無いなぁという感じでした。

今はやりのGo言語で作ったらネタ的に面白いだろうなぁとか、エンジニアが新たに体得するスキル的にも良いだろうなぁ..って気持ちありましたけどね(笑)

あ、一つ加えるなら誕生から9年を経て、ある程度成熟してきたように思えたってのもありますかね。これが5,6年前とかだとちょっと悩んでたかも知れません。

(Thanks! the photo on flickr by Yuko Honda CC BY-SA 2.0)

そんなこんなでGo言語に決めて @t0shiya に開発担当して貰いました。手前味噌ながら、良いものができたのではないかと思います。営業や他の事業のサポート業務で忙しいなか頑張ってくれました。

何度もスクラップ＆ビルドをしながら…だったですが、ここまで半年かからなかったですね。Go言語による開発のスピードが早いのは噂通りでした。最初のバージョンでは、実現できたことに対するソースコードの少なさにビックリしたものです。

商品構想を練ってステルスで紹介などもして、Go言語で書いた espar を PHP による WordPress プラグインで包んで WP Guard は形になりました。実際作ってみて、エンジンやライブラリ系はGo言語で、インターフェースやフロントは従来の軽量言語でという組み合わせは、一つの理想系だなと思いましたね。

ウチで今後何かを作る時はGo言語の採用をまず考えると思います。実際に使ってるのを傍らで見ていて、開発効率がUPする仕組み、クオリティが上がりやすい仕組み、が言語仕様として散りばめられているのが本当に素晴らしいと思ったんですよね。そういう意味でも良いなと。Go言語、バンザイ。

およそ一ヶ月ぶりの更新。

このカテゴリでのサービスは初めてとなりますが、この度WP Guardというサービスを始めました。今年の頭からWebサイトの「静的化」というキーワードで勉強会を開いたり色々技術調査もしてきて、行き着いた先がこうなりました的な感じです。プレスリリースをこちらに掲載しておりますので御覧下さい。

以下、開発の経緯などを簡単に書いてみます。

静的サイトジェネレータは難しい

随分前に、CMSにもうずっと疑問を持ってますという話というエントリで問題提起をしてからというもの、静的サイトジェネレータを色々触ってきました。

(2016年3月に開催した第二回静的Webサイト勉強会の様子)

しかし、やっぱり開発者以外の方には難し過ぎるなと。勉強会の発表でもデメリットとして強調していたので、分かってはいたのですけどね。

ツールとしての難しさが解消する見込みはどうも無さそうなこと、制作現場・運用現場での要求に見合う程の成熟にまで時間がかかりそうということから、一般的な浸透は難しいという結論に至ってしまいました。黒い画面が分かる人には手軽でとっても良いツールなのですけどね。

じゃぁ静的化は現実的ではないのか。

…という訳ではなく、依然として CMSによるサイト運営は利便の割に余計な面倒やリスクを抱えている という問題意識は持っていたので、もう少し追求してみようと考えたのです。自分もCMSでさんざん辛い思いをしてきましたから。

CMSの利便はそのままに、セキュリティの心配を限りなくゼロに近づけられないか。

自社開発のWebサイト静的化エンジン

そこで、現存するCMSサイトを、無理やり静的化して別立ての公開用サーバに静的化済みファイルを転送。更に「問い合わせフォーム」もちゃんと機能させる仕組みもセットにするという方向で作り込んでみた次第です。全く違うアプローチですね。

これが形になってみたら結構良い感じだったと。図を書くとこんな感じになります。

CMSは変えません。まず、既存のCMSを完全に封印します(右側の茶色の囲い)。Basic認証とかクライアント証明書とか、要するに第三者のアクセスを一切受け付けないようにします。更新担当者が編集/確認をできるだけ。安全を優先確保です。

でもこれだと一般の閲覧者も見れなくなるので、CMS側のサーバでWebサイトを更新の度に静的化、公開用サーバへ安全に差分転送。閲覧者には公開サーバ側を見て貰います。公開用サーバ内は、静的ファイルしかありませんので、幾ら攻撃されても漏洩や改ざんのしようがありません。事実上の攻撃無効化ですね。

更に、一般的には静的化すると問い合わせフォーム等が動作しなくなる(phpやperlを期待しているから)ので、それも機能させる仕組みも織り込んで静的化してしまう。いわゆるサーバレスアーキテクチャです。

こんな一連の連携を実現するエンジンを開発しました。名を espar と言います。elastic static page renderer の頭文字とって espar。目指しているのは、Webサイトの完全静的化。CMSを使いながらも静的化によって安全を担保すると。PowerCMSやNORENなどの企業向けの高額CMSには標準で備わっているのですけどね、汎用的という意味でちょっと違います。

実はこの種のエンジンって作る必要ありません。勘の良い方は気付かれると思うのですが、いわゆるクローラーに近いものなので、それこそ GNU wget とか既存のモノを使ったらいいんです。ただ、パフォーマンスの問題、サイトごとの特性に応じた柔軟さ、セキュリティの為の静的化という観点の相違、などなどからベストマッチには至らず、自前で実装することにしました。目的が違うと手段であるツールは別に必要ってことなのでしょうね。

やりたいことが上述の通りなので、言語はもちろんGo言語を使ってます。エンジニアの間で流行ってるからということではなく、要件が見事にマッチしたのでGo言語を選択しました。期待通りのパフォーマンスを出してくれています。Go言語、素晴らしいですね。

espar の提供第一弾として「WP Guard」

espar は、原理的にはWebサイトとして存在していれば良いのでCMSに全く依存しません。

が、まずは自分がよく使っていたし、世界中で一番使われているCMSだし、問題も色々とあることがよく知られているし…ということで、WordPress 向けに espar をラップして使い易くしたプラグインを提供することにしました。それが今回発表した WP Guard です。(前置きが長くなりました)

実際にはプラグインをインストールしてはい完了！というシンプルなものではなく、サイト毎の要件に従って色々設定が必要にはなります。それを弊社やパートナー企業様が実施する(インテグレーションする)ということなんですが、一度 WP Guard を導入すると、

• コンテンツ管理をするWordPressには、原則的に一切の攻撃が不可
• コンテンツ配信をする公開サーバにも、原理的に一切の攻撃が不可

という鉄壁を作れると同時に、

1. 今まで通りにWordPressの管理画面から編集/更新
2. プレビューして保存
3. WP Plugin の画面から「START」をクリックして、転送完了を待つ

ってな感じで、最後の1クリックだけ追加になる以外は、これまでの編集/更新操作を基本的に踏襲することができます。

プラグインの画面はこんな感じです。

ボタン1つで超シンプル。いつも通りサイト更新して頂いて、最後にここのボタンを押すだけです。ボタン1つで、サイトが静的化され安全が確保されるのですから、安心してWordPressサイトを運用できます。

結局これは、コンテンツの管理機能と配信機能の完全分離 なんですよね。閲覧が主体のWebサイトの場合、サイトの脆弱性の根本原因はコンテンツの管理機能と配信機能を同じサーバ内に共存させていることにあります。それを分離する。

ぶっちゃけ、WordPress本体やプラグインのアップデートが全然追いつかなくても、不正アクセスを受ける心配はほぼありません(とはいえ、マメなアップデートやはり実施頂いた方が良い訳ですが)。WordPress側はIPや証明書で制限されますし、公開側はそもそもプログラムやデータベースが存在しないからです。悪意ある第三者には、どこでCMS(WordPress)が稼働してるかすら分かりません。

これが静的化によってコンテンツ管理と配信を分離するメリットです。ちなみにその仕組み上、リアルタイムな即時反映が必要な会員サイトやECサイトには向いていません。どちらかというと、企業サイトやサービスサイトやオウンドメディア等の情報発信系サイトを想定しています。

勿論、WP Guard のオフィシャルサイトも WP Guard が導入されていて、オフィシャルサイトの www.wpguard.biz には、html/css/js/画像などの静的なファイル以外存在していません。perlやphpなどのサーバサイドプログラムも、データベースも存在せず、問い合わせフォームも普通に動作します。

当然、競合もおられます。WordPress に限って言えば StaticPress というプラグインがありますしね。でも目指すものが違った(ウチは、CMSを選ばず高速なこと、フォームも含め完全静的化を目指すこと)ので開発した次第です。

Webサイトセキュリティ市場へ

espar はその目的からしてセキュリティ市場と相性が良く、開発途中からステルスで営業をしていく中で色んな方から興味関心をお寄せ頂きました。

既に、複数の地方自治体様(都道府県単位)のWebサイトでセキュリティを担保する仕組みとして espar を導入して頂くことが決まっているほか、プレスリリースにエンドースを寄せて頂いたM2Mテクノロジーズ様には、同社が手がけられるサイト改ざん検知サービスの仕組みと WP Guard を連携して頂くことにもなっています。

当社は元々、SYNCNELというiOSデバイス向けクラウドサービスでセキュリティをウリにしてビジネスしていましたが、今度はWebサイトのセキュリティに 静的化 という視点で関わっていきたいと思います。

サーバの価格は一昔前に比べると随分と下がりました。AWS S3のウェブホスティングのように安価な仕組みもある時代です。ファイアーウォールや侵入検知システムやWAFなどの高度なセキュリティ製品をいれなくても、コンテンツの管理と公開の機能を完全分離 することで守るスタイルもアリではないか。そんな問題提起をしていければと思います。

このたび、発表しました WP Guard と高速静的化エンジン espar ともども、これからもフィードテイラーをどうぞ宜しくお願い致します。興味関心お持ち頂けましたら、こちらからお問い合わせ頂けたら幸いです。