WordPress のセキュリティ対策(補遺)

河本孝之(Takayuki Kawamoto)

Contact: https://plus.google.com/112326853631114362590/about

First published: 2017-03-03 17:18:47,
Modified: 2017-03-08 17:25:22,
Last modified: 2017-03-11 09:22:10.

はじめに

本稿は、2016年の2月に更新を終了した「WordPress のセキュリティ対策」という記事(本稿では「先の記事」と呼びます)の補足です。僕は先の記事の更新を終了した際に、少なくとも日本で活動されている多くのセキュリティの専門家が WordPress の運用について発言したり著作を出すようになったため、知見も責任もある彼らに任せたほうが良いと判断したと書きました。

しかしながら、そうした著名な方々でも十分満足に情報を公開したり更新しているわけではありません(自著の更新情報を一年ごとに公表するだけでは、残念ながら不十分だと言わざるを得ません)。他方で、少なくとも関西のウェブ制作業界においては、僕も非機能要件を適正に満たすべき成果物の品質を管理しナショナル・クライアントや大手広告代理店へ責任を負う立場にある者として、自分のサイトでメンテナンスを終えた不十分なセキュリティ対策の文書を(いくら「古い」と断り、記録としての意味しかないと言い訳を付け加えているからといって)公開し放置し続けるのは無責任というものではないかと考え直しました。つまり、それなりに狭い(あるいはレベルの低い)意味合いでは、もちろん僕自身もセキュリティの実務家であり業務上の責任を負っているプロフェッショナルの一人なので、コンテンツを公開し続けるのであれば一定の責任に応じて内容をメンテナンスした方がよいのでしょう。ということで、必要に応じて本稿でコンテンツを追加したり、必要に応じて先の記事を修正していきます*1

本稿では、追加したい話題を章立てで区切って公開するため、前後の内容に時間上の、あるいは推論上の関係があるとは限りません。つまり冒頭のコンテンツを読まないと後のコンテンツが理解できないという書き方はしていませんし、逆の順番についても同じです。但し、それぞれの文章で仮定している経験や知識は異なるので、一応の目安として、[G] = General topics, [B] = Business use topics という区別はしておきます。[G] は先の記事と同じていどの知識があれば理解できると思いますが、[B] は情報セキュリティの実務なり業務として納品する立場にある人でなければ理解できないことが多いと思います(とは言え、それは「高級な話題だから」だとは限りません。そういう業務上の用途でもない限りは、多くの人は特に考えなくてもいい話題かもしれません)。

なお、このような文書は、本来は僕が情報セキュリティ系の別サイトとして運営している identifiable.info で公開するべきかもしれませんが、正確に言うとこのサイトはドメイン名が表しているように online identity や個人の認証をテーマにしたいという意図で始めたので、情報セキュリティ全般の話題を混在させると運営方針が不明確になってしまうため、このまま当サイトで公開します。

*1 新しく記事を公開する理由は他にもあります。やはり依然として(僕らの観点から見ると)アマチュア、あるいは生半可にセキュリティの考え方を聞きかじった技術者が不適切な対策を気軽にブログ記事として公表しているようなので、こうした間違いを指摘する嫌われ役が必要なのでしょう(もちろん、嫌われ役を買うとは言っても、僕は博士課程で哲学を専攻した人間として、アドラーなどという三流心理学または「洗練された占い」をネタに本を書くほど恥知らずではありませんが)。もちろんそのような「掃除」を WordPress のセキュリティに関する著名人たちに期待してもいいわけですが、得てして有名となった方々は、素人の間違いをあからさまに指摘するといった野暮なことはしなくなって「いいひと」になりがちです(また、素人の書いたものをいちいち訂正すると「無料の家庭教師」や「無償奉仕のセミナー講師」になってしまうからでもあります)。このため、皮肉にも WordPress のセキュリティについてエスタブリッシュメントとされる人々が明確な発言を避けるようになり、皮肉にも間違いが間違いとして放置されてしまいます(更には、間違った対策を主張しながら「エスタブリッシュメント」となってしまった立場上、簡単には訂正できなくなってしまうという問題もあり得ます)。

日曜プログラマが自分の使っている WordPress サイトで勝手に脆弱な対策を施し、知らない間にロシアのスケベ姉ちゃんの写真をトップページに掲載されて家庭不和となるくらいの些事なら、全世界のブログで頻発しても大して驚くようなことではありませんが、僕らが業務で預かっているクライアントのブランド価値や個人情報の価値は、規模に関係なく制作プロダクション企業が簡単に倒産するようなインパクトとなり得ます(もちろん、個人のトラブルの方が瑣末だからというだけではなく、専門家の個人情報から愚かなセキュリティ対策を導入している人たち自身の個人情報も含めて影響の範囲が広いからです)。僕は納品したウェブサイトで使っている CMS やフレームワークや個々のコードや OS を全てメンテナンスしたり監査しているわけではないので(というか、そんなことは他社でも IT ゼネコンでも不可能でしょう)、当社の人間やクライアントがオンラインで公開されている間違った対策を勝手に導入しても気づきませんし、そもそもオープンソースのツールであろうと有償販売のシステムであろうと、使っている側に無条件で全ての責任があるなどという契約は民事として成立しません。とは言え、事前に愚かな対策を導入しないように牽制する責務はあると思うので、このような文書を作成して一定の範囲でメンテナンスしようと決めました。現に、僕が取引先でレクチャーしたり社内研修を開催するときには、先の記事も含めて(もちろん当サイトはプライベートな目的で運営しているので、この URL を紹介しているわけではありませんが)、ここで書いていることを具体的に紹介しています。従って、本稿は、個々の実装では与件に応じて色々な対処の仕方があるとは言え、ポリシーとしては当社の実装レベルはこの記事と同じであると言えるていどに僕自身の現実の職責と関連している文書です。

冒頭に戻る

[G] バージョン表記の抑制について

WordPress の「セキュリティ対策」として頻繁に語られるのが、バージョン表記の抑制です。これは Apache のような他のアプリケーションについても、ServerSignature ディレクティブでエラーページのバージョン表記を抑制するべきかどうかが話題となってきました。

具体的に言うと、WordPress が出力しているページのソースをブラウザで表示すると、

<meta name="generator" content="WordPress 4.7.3" />

のようにバージョン番号が <meta/> 要素として自動で出力されます。これを情報漏洩の一種だとでも考える人々がいて、「セキュリティ対策」と称しては抑制する方法を SNS で公言したりオンラインでページを公開したり本や雑誌に書いているわけです。

しかし現在のユースケース、技術的な可能性、それから現実に起きているインシデントで使われている手法がどれくらい簡単に入手して使えるかを考慮すると、バージョン表記を抑制するていどのことでリスクが実質的に低減した時代は既に終わっていると考えるのが妥当です。その最も大きな根拠は、WordPress で構築されたウェブサイトに対する攻撃の多くは大量のボットで構成されたボットネットで自動化された、無差別かつ大規模な手法を使っているというポイントにあります。いまや、攻撃する側は WordPress のバージョンが幾つなのかとか、それがページに表示されるかどうかなどということは気にしません。

つまり、実質として WordPress のバージョンが当該の脆弱性について対策できていなければいけないという、ごく当たり前の事実だけが残るわけです(最初は「最新でなければならない」と書いていましたが、もちろん最新のバージョンにしているからといって安全だとは限りません。せいぜい「既知の脆弱性について一定のセキュリティレベルの対策を施した」と言えるだけです)。バージョンの表示を抑制するなどというハッタリがセキュリティ対策になるなどという牧歌的な時代は終わりました。

セキュリティの原則として考えても、情報を秘匿するという手法は一般的に「下策」とされています。なぜなら、情報を隠蔽する方法も隠蔽できなければ万全とは言えず、そのまた情報を隠蔽する方法を隠蔽する方法も隠蔽できなければならず・・・と切りが無くなり、つまりは万全な隠蔽方法などないからです。しかし、上記のようなメタ情報の隠蔽がそもそも隠蔽として適切であるかどうかを考えると、そのサイトを攻撃してみるだけで WordPress が古いかどうか判定できるのですから、実質としても隠蔽の役にすら立っていないことは明らかです。そもそも、攻撃する側が目指しているのは WordPress のバージョンを知ることではなく、攻撃して情報を盗んだりサイトにマルウェアや不正ページへのリンク等を仕込むことなので、つまるところバージョン番号などどうでもよいわけです。

上記に加えて、例えば WordPress の公式ドキュメント群と言える WordPress Codex というサイトで情報セキュリティ対策を解説しているページをご覧いただいても、バージョン情報を抑制せよなどということは一言も書かれていません

僕がこの手の「セキュリティ対策」とやらを見かけて最初に感じたことは、WordPress のバージョン番号を秘匿して「古いバージョンでサイトを運用していることが分からないようにする」のが情報セキュリティだと説明されていることへの不信感でした。上記でも述べたとおり、脆弱なままのシステムを放置して、そのバージョン番号の表示を抑制すれば安全になるという牧歌的な発想がセキュリティの原則としても幼稚であるという点はもちろんですが、それはつまり WordPress のバージョンを隠すというよりも寧ろ、システムの改善が何らかの事情でできないという運営側の失態や、予算不足というファイナンス上の失敗(僕は企業の役職者でもあるため会社経営の立場からも書きますが、予算を確保できないのは組織の人員なり事業に問題があるからであって、運のせいでもなければ不況や世の中のせいでもありません)、そして会社に資金があっても情報セキュリティへ(もちろん過剰ではなく適度に)投資する経営判断が欠けているという実情を隠蔽しているだけではないかと思えるからなのです。

社内に、この程度の「セキュリティ対策」とやらを検索して見つけてくるくらいの従業員はいても、WordPress をアップデートすると現行サイトにどういう影響があるかを予め検証できる従業員がいないのであれば、それができる外部スタッフやセキュリティ企業に相談するという発想がすぐに出てこなければなりません。それはつまり、自分達に基礎的な見識が不足していると自覚することでもあります。僕も含めて、古今東西の誰であれ人は完全無欠ではありえない以上、色々な分野について平凡どころか基本的な素養すら身に着けていないわけです。情報セキュリティのプロフェッショナルとして活動している人々の全てが個展を開催できるくらいの書道の才能があるわけでもなく、ハーヴァード大学の医学部教授を全員集めて一つのテーマに没頭させても10年以内に毛生え薬や癌のワクチンが開発されるという期待は殆どできないでしょう。つまり、専門であろうとなかろうと、どのような人にとっても困難なことが数多くあり、我々はそういうものと関わりながら生活したり仕事をしているという、或る種のリスクにさらされています。そして、ほぼ全ての人は、そういうリスクが実際に顕在化して対策を講じなければならなくなったときに、自分自身が適正な情報とスキルを弁えていて対策を講じられるとは限らないと自覚していなければなりません。この自覚がない人は、会社経営であろうとウェブサイトの運営であろうと、あるいはあるいは家庭を持つということでも構いませんが、そういう「マネジメント」が必要とされる事案へ軽率に関与すると大多数は失敗を引き起こしますし、それによって被害を蒙るのが他人でもあるならなおさら、どのように関わるべきなのか、あるいは関与するべきかどうかについて慎重であることを求められます。

冒頭に戻る

[B] 管理画面としての WordPress

成果物として WordPress で構築したウェブサイトを納品する場合、セキュリティ対策の一つとして僕が(もちろん闇雲・一律にではなく必要に応じて)採用しているのは、WordPress を管理画面としてだけ利用するという手法です。これはつまり、ウェブサイトで記事やページを作成・更新するのがトップクライアントの担当者であり、CMS を導入する目的の一つが彼ら担当者の負荷を軽減することにあるなら、WordPress のような CMS を導入するという与件を導き出している「要件」はサイトの運営業務の負荷を軽減したいということであって、「要求」は彼ら担当者がオンライン業務の専任者でもなければウェブコンテンツの制作や運用についてスキルをもつインセンティブが存在しないのでシステムに任せたいということになります*2。もちろん、これらの要件や要求を汲み取っている我々は、殆どの場合にはそれら要件や要求について「お小言」を言う立場にはありません。マーケティングがどうのウェブ戦略がどうのと瑣末なビジネス用語をまくし立てようと、結局は面倒臭いだけだろうと見越した上でも、表面的には彼らの要求を満たす要件を設定して仕様をまとめるのがサービスというものです(もちろん限度はありますが)。通常、システム開発を受託する企業において、実装したり開発するシステムつまり成果物だけでなくサービスの設計やビジネスメソッドにも関わるような「アーキテクト」と呼ばれる職種の人々は、単にプログラムやサーバの仕様だけではなく営業担当のディレクターに話を聴いたりクライアントへ直に接触して、彼らが実際に何を求めているのかを「要件」や「要求」として掴み取る必要があります(僕は社内で正式な職位として「アーキテクト」を拝命しているわけではありませんが、職能としてはアーキテクトとして振る舞うことを期待されている立場でもあります)。

ということで、WordPress を利用したウェブサイトの構築を担ってきた経緯から、WordPress を管理画面として導入するという手法を採用することが何度かありました。トップクライアントの多くは(広告代理店や当社のディレクターに、自分たちの要求とは関係なく勧められたからという理由とは違って)、自分たちで(もちろん自分たちの)ウェブサイトを一定の範囲でコントロールしたいと望んでいます。しかし、HTML のコーディングや部品画像のデザインをしたいという(いわば多くの人にとっては趣味的な)欲求まではありません。こういう場合、ウェブサイトの運営を楽にするために CMS を導入するのは自然な提案ですが、それはあくまでも彼らトップクライアントの担当者の事情であって、コンテンツを利用するビジターの事情は関係がありません。そして、動的なしくみである CMS を導入するということは、ウェブサイトだけでなくビジターをも一定の脅威に晒すこととなるため(ウェブサイトがワームなどに感染すると、ビジターにも脅威となるのは当然です)、先の文書でも、そもそも CMS を導入する必要があるのかどうか検討しようと書きましたが、CMS を導入するべき理屈を自分たち運営側の事情だけで組み立ててはいけないのです。アーキテクト、とりわけ情報セキュリティにも関わる人間は、情報資産の適正な運用を全てのステークホルダへの影響について評価しなくてはいけませんから、ウェブサイトの運用・運営にかかわるステークホルダでもあるビジターへの影響は無視できません。

このような理由から僕の選択した手法が、WordPress を管理画面としてだけ構築し、フロントエンド側のコンテンツはオリジナルのコードで構築するということでした。模式図は下記のようになります。

WordPress as an administration system

*2 もちろん、それに加えて、単に「話題の CMS を使ってみたい」という理由で WordPress を与件に引っ張り出す人がいないわけではありません。また、CMS を使えば構築・制作の工数が削減されて費用を抑えられると考えているのかもしれません。実際、受託側のディレクターも「制作費用を削減できる」とセールスする場合もありますが、その場合は CMS を使えば CMS の仕様を理由に後から余計な機能を追加しろと言われても断れるとか、CMS の仕様を拡張するような追加要求には特別な費用を請求できるといった、営業担当者としての目論見があるはずで、単に顧客の予算を低く抑えるためだけに CMS を提案するようなディレクターは、人物としては誠実かもしれませんが、企業人としてはナイーブすぎると言えます。もちろん顧客の予算を不当に引き上げろと言いたいわけではありませんが、後から発生しうるリスクを予測して先手を打つことは別に何も悪逆非道なことではないでしょう。

WordPress は管理画面としてだけ運用するので、WordPress は MySQL 互換の DBMS とファイルシステムに対して正常に動作すれば十分です。テーマファイルは必要最低限(というか実質としては不要)でよいため、ディフォールトのテーマである Twenty(****) を選択し、それ以外のテーマは全てサーバから削除します。ウェブサイトのセキュリティを維持する些細でありながらも確実なコツの一つは、「使わないファイルを放置しない」(少なくともウェブサーバの公開領域に放置しない)ということです。残念ながら、WordPress の更新機能を使っている場合には、自動更新であろうと管理画面からの手動更新であろうと、アップデートのたびに削除したファイルが勝手にサーバ内へ再び展開されてしまいます。例えば、殆どのコーポレートサイトではコメント機能やユーザ登録機能などは不要ですし攻撃場所を放置するだけなので、/wp-comments-post.php や /wp-signup.php などはサーバから削除するのが安全ですが、WordPress を更新すると再びサーバに設置されてしまいます。WordPress の自動更新という「なんちゃって自動化」(実はビジターのアクセスをトリガーにしているだけなので、アクセスのないサイトは全く更新されない)ではなく、PHP と crontab で本物の自動処理を追加できる場合には、逆に不要なファイルをサーバから削除するスクリプトを書いて 1 時間ごとに動作させてもよいわけですが、そういうスキルも準備もしていない場合は、知らない間に削除したはずのファイルが再びサーバ内へ展開されていることに気づかないままとなるかもしれません(特にトップクライアント企業の運営担当者は FTP ソフトでサーバにアクセスする理由も責任もない・・・と思っていることが多いため、納品された後は管理画面にしか関心が向かないものです)。

こういう状況に対応する一つの手法が、WordPress は導入するがフロントエンドは独立させるということでした。この手法を導入する場合、ウェブサイトの FQDN を www.test.com とすると、admin.test.com のようなサブドメインを「管理サイト」として WordPress をインストールし、admin.test.com へはサイト運営者が利用しているネットワークの IP アドレスからのアクセスだけを許可したり、ベーシック認証を設定するなどの処置が望ましいです。ただし、この手法は SSL サーバ証明書が公開サイトと管理サイトの二つに必要なので、予算に一定の余裕が必要でしょう(昨今はメール認証やドメイン認証で取得できる証明書なら年間でも 3,000 円以下で取得できますが、レンタルサーバで好き勝手な SSL サーバ証明書をインストールできるところはありません。やはり専有サーバか VPS を借りるのが使い勝手は良くなります。自分でサーバを運用できないなら、「マネージド」と呼ばれるオプションがついたプランのサーバを選べばよいでしょう)。こうして管理サイトを独立させると、公開サイトには WordPress に関わるファイルが一つもなくなるため、フロントエンド側の作業は非常に見通しがよくなります。

WordPress で運用する管理サイトと公開サイトを分離した後は、公開サイトの構築は一般的な PHP なりウェブ・アプリケーションのセキュリティ対策を守って構築すれば問題ありません。WordPress のデータを利用するため、特に SQL コマンドの扱いと、ウェブページを出力するときのデータの扱い、それから HTML や CSS や JavaScript などで扱う入力値や出力値といった動的要素の処理に気をつければ、あとは Apache や IIS のようなウェブサーバ、PHP の処理系、それ以外の通信系のコマンドや OS の動作に関わる機能に問題がない限りは、対策としてはひとまず一定のセキュリティ・レベルを維持できるでしょう。更に、ウェブページへアクセスするたびに DBMS サーバへアクセスするのはサイトが重くなるので嫌だという場合には、コーポレートサイトの場合ならコンテンツが頻繁に書き換わることはありませんから、<body/> 内の要素を予めテンプレートと組み合わせてテキストファイルとして出力しておき、ウェブページへのリクエストに応じてコンテンツを読み込むという仕組みを導入してもよいでしょう。この場合は、管理サイトで記事を作成して publish したり update するたびにコンテンツ用のファイルを上書きで出力するような機能を組み込むことになります*3。そのようなコンテンツは外部からアクセスされても何か重要な情報が漏洩するわけでもなんでもありませんから(元々ウェブページの要素として表示するための内容なので)、公開サイトのどこに置くかは勝手に決められます(ただし検索エンジンのロボットにインデックスされるのは好ましくないでしょうから、.htaccess でアクセスを制限してもよいでしょう)。

*3 多くの方はご承知のように、これは普通は WordPress にキャッシュ機能を追加するプラグインで実現できます。しかしながら、フロントエンドを WordPress とは独立させているので、ここでご紹介している事例ではプラグインが使えません。

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Google+ Twitter Facebook