2019年06月27日に初出の投稿

Last modified: 2019-07-11

ZAP

最近、制作部署から何度か問い合わせや相談があるのは、会社としてどういう CMS に対応しているのかということと、逆に CMS を使いたくないのでどうすればいいかということだ。これらは、もちろん「リスク対策」という同じ目的なり動機からきている相談だと思うのだが、弊社はサーバ構築からプログラミングやセキュリティ監査まで、僕が一人で対応しているため、実質的に僕が何をやれるかという話になる。もちろん、委託すればいいのは確かだが、実際に使っていない CMS で実装されたシステムをテストしたり監査するには、やはり自分たちでもその CMS について一定の知識なり経験がないといけないので、外注を使うとしても必要な知識の量は大して違いがないと思う。 まず対応している CMS について書くと、僕が電通・博報堂案件で実装してきたコーポレート・サイトやキャンペーン・サイトでの実績から言うと、納品レベルで実装したり運用できる CMS と言えば、ほぼ WordPress と Movable Type の二つになる。他にもマイナーな CMS を幾つか使ったことはあるが、はっきりしているのは ERP と連動するようなゼネコンが提供する CMS は全く経験がないし、経験を積み上げたくもないということだ。VB で動く CMS とか、Oracle のデータベースしか使えない CMS など、いくら知識や経験を積み上げても無駄である。コンピュータ・サイエンスの観点で言ってもゴミ知識なのは言うまでもないし、ビジネスという点から言っても他の案件で使えない、学術的にも金銭的にも取り柄がない、バカみたいな学習工数がかかるだけの社内奴隷専用 CMS と言ってよい。よく、外資系のコンサルとかが面白がって導入するような、聞いたこともない会社の CMS がそれで、パッケージやサーバ単位で数百万くらいからのプランになっていたり、年間サポート費用だけで四桁に迫るようなものがたくさんあるが、はっきり言ってセキュリティとしてもどのていどのレベルなのか、実は誰も比較したことがないような代物である。攻撃されたことがいなければ、結果的に事故は起きないので「安全」ということになるが、そんなのは単なる結果論でしかない。 もちろん、BA さんが自前で作っている CMS のように、一定の実績がある(と言われているだけだが NDA もあるので証拠がなくても仕方がない)パッケージもあるにはある。しかし、それらは制作会社が独自に開発して実装しているため、まずもって知財だから他社が運用や実装技術をむやみに習得したり応用できるわけもない。したがって、そういうものがあるからといって、自前で開発した CMS の方が数多くの脆弱性が報告される WordPress よりも安全かと言うと、そういうわけでもない。結局は、証拠がないところで議論しても仕方がなく、結局はどこがどれだけ責任を負うか、そして何かが起きたときの対応や手順をどう決めておくかという話をした方が健全だと思う。 次に、WordPress は危ないので自前の CMS を運用したいという相談には、二つの考え方をディレクターに伝えてある。 一つは、危険なのは実装やコーディングであって、WordPress 本体の脆弱性は大して多くないということだ。当サイトでも幾つか書いているような、WordPress のセキュリティ対策とされるような措置を殆ど取っていない上場企業や大企業もある。8年前のバージョンを使い続けてるとか、パスワードが「クライアントの社名+実装した年」みたいな愚かな運用が幾らでもあるのだ。その理由の多くは、大きな会社に限って、責任逃れなのか無能なのかは知らないが、社内の情報システム部門が全く運用に関与しようとしないことである。古い大企業となると、本当に情報システム部門の大半の人員が VB か C++ しか使ったことがなく、ウェブのアプリケーション開発についても個人的に趣味の範囲で知ってるという人しかいないという事例もある。よって、WordPress を使うからといってただちに危ないとは限らず、僕らのような情報設計からサーバ構築やプログラミング、セキュリティ監査、そして非機能要件全般に対応する人材に実装させたら一定のセキュリティ・レベルは確保できると思う。まぁ、いくら出すか次第だがね。 そしてもう一つは、当サイトでも解説しているように、これまで多くのクライアントが WordPress を使いたがってきたのは、管理画面で記事やページを簡単に作ったり編集できるからなのだった。文字を一つ直したり画像を差し替えるだけで、制作会社に作業を依頼したりメンテナンス料金を払うのは、面倒だし勿体ないということらしい。そういう用途があるという前提を押さえておくと、要するに管理画面だけ WordPress で別のサーバなり別のサブドメインで運用しておき、フロント・エンドの実装は別のフレームワークか、自力で開発したプログラムで表示すればよい。表示するデータは、それらのプログラムから DBMS を叩けばいいのである。もちろん、僕らのようにセキュア・コーディングの知識と一定の実績がある人間が開発するという前提があっての話で、「プレースホルダってなんですか?」みたいな身の程知らずが口にするような提案ではない。これにより、管理画面は WordPress のままでも堅牢に設定して構わなくなるし(IP 制限をかけようと、厳重な FW のポリシーを設定しようと自由だ)、フロント・エンドの側でも WordPress に依存するような設定を引きずらなくてもよくなる。 そして、特に《それなりの予算》がある案件で大切なのは、まず誰がどう実装しようとセキュリティ監査の会社に監査を依頼するということだ。これも、当サイトで書いているように、CMS の機能を全て監査すると数か月もかかって数千万円の予算がかかるため、ポイントを押さえて監査するようセキュリティ監査の会社と相談して進めたい。そして第二に、脆弱性というものはプログラムだけの問題ではないので、サーバの構築や運用にもコストを向けていただきたいということだ。正直言って、当社で受託している案件の大半は、SAKURA のクラウドや専用サーバの構築とかメンテナンスは、初期費用の他には明確なメンテナンス費用として科目がなく、たいていは「サイトの運営費」としてグロス扱いになる。よって、なかなかディレクターもクライアントも広告代理店さんも、プログラムが動くおおもとのサーバやネットワークにも脆弱性はありうるということ、そしてサーバやネットワークの脆弱性にはサイトの運営にとって致命的な影響を及ぼすものが多いということを理解することが難しくなる(これはシステム開発やセキュリティを担当している人間にとって、《見えない成果》を提供する難しさという意味では永遠の課題だが)。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


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

Twitter Facebook