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

河本孝之(Takayuki Kawamoto)

Contact: takayuki.kawamoto (at) gmail.com.

ORCID iD iconORCID, Google Scholar, PhilPapers, about.me.

First appeared: 2019-04-11 17:08:18,
Modified: [BLANK],
Last modified: [BLANK].

はじめに

本稿は、2016年の2月に更新を終了した「WordPress のセキュリティ対策」という記事の二つ目の補遺です。一つ目の補遺だけでも既にかなり長いウェブページとなっているのに加えて、今回は IPA の『安全なウェブサイトの作り方』というガイドラインに付属しているチェック・シートの項目を全て取り上げるため、新しく起稿してページを分けることとしました。そのため、当サイトで掲載している文書で議論した論点の幾つかについては、既に読者がご存知のこととします。

それから、このページの議論を適切に理解して利用するためには、プロダクション用途(つまり業務)でのプログラミング経験とサーバ構築の経験が3年以上はあることが望ましく、特に PHP と WordPress については独特の用語(“the Pages” など)や取り回しの手順について知識が必要であり、レンタルサーバで自動インストールした経験しかない方には難しい内容だと思います(ただし、そういう方にもできるセキュリティ対策はあります)。また、本稿は僕自身がナショナル・クライアント案件(具体例は NDA があるので挙げられませんが、要するに電通グループ、博報堂DYグループ、JR西日本コミュニケーションズといった広告代理店さんが手がける上場企業や大企業のウェブサイト制作・構築)で実装した経験がある技術者であると同時に、本来は望ましいことではありませんが、その実装状況を監査する情報セキュリティ部門の役職者でもあるため、コピペで終わるような小手先の対策だけではなく、情報資産やパーソナルデータの保護、あるいはシステム全体のライフサイクルという観点でも議論します*1

*1まず強調しておきたいポイントは、『安全なウェブサイトの作り方』の基準を満たしていても情報セキュリティ対策としてぜんぜん十分ではないということです。特に、情報セキュリティマネジメントの実務家として強調しておきたいのは、このようなチェック・シートだけが独り歩きして納品時の保険であるかのように扱われてしまっては、重大なリスクを放置しかねないということです。なぜなら、このシートの項目は情報セキュリティマネジメントで必要とされる四つの対策のうち、「技術的対策」と呼ばれる一種類(しかも僅かな一部分)の対策にしか対応していないからです。たとえば、FTP アカウントの管理はどうでしょうか。ステージング環境(テストサーバ)を別につくるとき、アクセス制御はどういう方針で組み込みますか。『安全なウェブサイトの作り方』には、そういう別の種類の対策が他にたくさんある(技術的対策としてすら他にも膨大にある)という示唆すら満足に説明されていません。『安全なウェブサイトの作り方』は、技術的対策の中でも重要なポイントをしっかり取り上げているという理由で高く評価できるガイダンスですが、情報セキュリティの対策としては、しょせん一部でしかないということも事実なのです。

このように書くと出てきやすい反論として、次のようなものがあるでしょう。「それでも、いまだにパスワードをテキスト形式で保存したり、個人情報を HTTPS 通信なしで取得するフォームを実装するような業者がいるのだから、まずこれだけでも普及させることが重要だ。仮に『安全なウェブサイトの作り方』で書かれた対策が一部だとしても、そもそも情報セキュリティ対策の『全体』を知っている人間などいないのだから(「シュナイアーの法則」のバリエーション)、できることから始めるべきであり、体系的な話を強調するだけでは実効性がない。」その反論の前提については、確かにそうです。「ウェブ業界はどこを向いているのか」という文書でも議論しましたが、僕の見立てでは、まず 99.9% のウェブ制作会社や開発会社の「エンジニア」や「ディレクター」を自称している人々は情報セキュリティについての(技術的対策についてすら)リテラシーが全くありません。それどころか、セキュリティの知識だけではなく、プログラマやサーバ技術者としてすら疑問を感じるような人も数多く見かけます。すると、そういう人々でも何かの案件で働いてしまっているからには、簡単にすぐ利用できる実践的な業務や手順を教えて実行させることが重要だと言えるかもしれません。

しかし、だからといって体系的な知識や見取り図のようなものをもつことが無駄だという話にはなりませんし、後回しでいいとすら思いません。どれほど「実践的」と言えようと、僕は目先の処理や対処に偏向した考え方は間違っていると思いますし、そんなものを「現場主義」などと言って正当化する人々は単なる無知無教養を考え方や方針の違いであるかのようにミスリードする夜郎自大にすぎません(これは僕が哲学者として考えていることですが、いわゆる「理論と実践」などという対比そのものが何らかの思惑による偽の対比なのです。僕ら自身が実例であるように、有能な人間はどちらもできます)。そして、実は情報セキュリティだろうとマーケティングだろうとビジネス英語だろうと、「実践的」などと称してばら撒かれてきた本や雑誌記事は、既に何十年も多くの人々に利用されてきています。つまり、日本のウェブ制作や開発という業界の現状は、既に「実践的」なシステム開発やコーディングや情報セキュリティ対策やビジュアルデザインを20年ほど続けてきた末の結果なのです。したがって、「実践的」なノウハウが必要だといま言っている人たちは、それまでに「実践的」なことだけしかやってこなかった人々の結果として、「実践的」なノウハウがいまだに必要とされるという、殆ど向上も改善もしなかった業界という現状を正しく理解していないと言えます。こういう人々は、僕に言わせれば「おなかへった」という子供と同じです。

僕は、これは学校の勉強にも言えることだと思いますが、要するに原理・原則という知識を体系的に学ばず小手先のテクニックやノウハウだけを次から次へと消化していくような人々には、そういう「実践的」と称する場当たり的なルーチンワークというレベルを超えた仕事はできないのです。もちろんブルーカラーとして作業していればいいという人には、それを超える知識も発想も必要ありませんが、僕らが本稿で議論しているのは、他人様に成果物の責任を負える立場の人が何をどう考えて実行すればいいか(すべきか)という話であって、企業において責任を負えない役割の人が WordPress を使って何をどうしたいかなど知ったことではありません。

冒頭に戻る

『安全なウェブサイトの作り方』について

国内でウェブ・アプリケーションを受託開発している事業者の多くが既にご存知のとおり、独立行政法人情報処理推進機構(IPA:Information-technology Promotion Agency, Japan)という団体があります。多くのプログラマが取得している「基本情報技術者」とか「応用情報技術者」とか「情報処理安全確保支援士」のような国家資格の認定制度を運営していたり、情報セキュリティ施策に関する研究や啓発活動や人材育成など、多くの活動内容で知られている組織です。この IPA から2006年に初めて公表されたのが『安全なウェブサイトの作り方』というガイダンスです。その後も改訂が続けられていて、最新は第7版(2016年1月、第3刷)となっています。本稿では第7版第3刷の内容に沿って議論します。(PDF ファイルの表紙には「2015年3月」とありますが、これは第7版として初めて公表された時期つまり第7版第1刷が発行された時期を指しています。)

『安全なウェブサイトの作り方』は、オンラインでは情報セキュリティの研究者、実務家、技術者、あるいは啓蒙家として知られている、高木浩光さんや徳丸 浩さんといった方々が中心となって執筆しており、もちろんその手の有名人だけではなく、開発ベンダーやセキュリティ企業等で実務に携わっている方々も協力して作成されたガイダンスです。対策としての厳格さには色々と議論の余地はあるかもしれませんが、最低限度の対策を集めたガイダンスとして「標準的」と言ってよい内容だと言えます。もちろん、他にも OWASP という団体が発行している “OWASP Application Security Verification Standard”(JPCERT による日本語訳)やデータベース・セキュリティ・コンソーシアム(DBSC: DataBase Security Consortium)が発行している「DB 内部不正対策ガイドライン」(2016)や経済産業省のマネジメント系のガイドライン類、他にも法令や規格など数多くの指標があります。その中でも、特にウェブ・アプリケーションの開発において留意すべきポイントを押さえてあり、具体的な対策の方針も提案しているガイダンスとして、『安全なウェブサイトの作り方』は既に多くの開発ベンダーやウェブ制作会社で導入されており、実際に弊社でも大手の広告代理店さんから『安全なウェブサイトの作り方』に付属するチェック・シートをもとに作成された文書への記入・提出が求められることがあります。(もちろん、まったくの使いまわしではありませんが、項目は用語法も含めてほぼ同じです。)

さて、納品物としてのウェブサイトや CMS について一定の業務を遂行した結果につき、受託企業がしかるべき範囲の動作品質を保証するべきことは言うまでもありません。厳密には、スタイルシートや動画といった「アプリケーション」とは呼べないコンテンツについても、受託している制作会社は事前に合意した範囲の成果物について、一定の「契約内容不適合責任」(改正民法第562条, 第566条, 第636条)を負っている場合があります(旧民法で「瑕疵担保責任」と呼ばれていたものです)。法律で規定されている「責任」の範囲は、もちろん「成果物」や「品質」を契約でどう定めるかによって決まりますので、善管注意義務の範囲と言えるような業務上の責任はともかく、本来は制作業務に着手する前にどこまでが制作会社の責任なのかを決めておくべきです。ビジュアル・デザインのように前もって売り手と買い手で「品質」として同意できる客観的な基準が存在しない場合もありますが、WordPress を使ったウェブサイトの構築といった案件の場合には、「『安全なウェブサイトの作り方』に付属しているチェック・シートの項目を満たさなくてはならない」などと具体的な基準を定める事前の合意は可能ですし、当社も外部の会社に委託する際は、取引を開始するかどうかの与信判断において「情報セキュリティベンチマーク」というチェック・シートへの記入を求めたり、開発業務を委託する場合は『安全なウェブサイトの作り方』で示されている対策へ準拠することを求めています*2

*2このような基準を(それこそセキュリティ対策から内部統制どころか法令すら)軽視するような主旨の発言を繰り返す起業家や投資家は後を絶ちませんし、東京とか言われる東アジアの僻地では上場企業の取締役ですら、脱法的なマーケティングやサービス展開を推奨する愚かな発言を繰り返す人物がいるようですが、僕のような事務方のジジイですら大企業案件レベルに対応できるセキュリティ品質で片手間に WordPress のサイトを構築できるというのに、ウェブ・アプリケーションの開発で食べている専任の人たちが、「クリエーティブ」でもなく「イノベーション」でもなく「ものづくり」でもないレベルの受託業務であろうと、対応できない筈はありません。僕がいくら有能な人材だからといって、別に有能さに見合う給与を得ているわけでもなし、特別に厳格な基準で仕事をしているわけではないのです。そういう、語弊はあるでしょうが、僕の尺度で言えば手抜きで達成できるような品質すら満たせない「エンジニア」って、いったい会社で何をやっているんでしょうね。

冒頭に戻る

ウェブ制作会社は WordPress サイト全体の挙動に責任を負えるのか

まず結論から言うと、WordPress で構築したサイトは『安全なウェブサイトの作り方』で示されている基準を全て満たせるとは限りませんし、全て満たすべきかどうかも自明ではありません。なぜなら、WordPress で構築したサイトの全体(つまり自社で制作したテーマのテンプレートや画像だけではなく、/wp-admin や /wp-includes など WordPress のコア・システムも含む)を適用範囲にすると、恐らくウェブ制作会社は『安全なウェブサイトの作り方』の基準を満たすために莫大な費用を使うことになる筈だからです。そしてその最大の元凶は、やはりオープンソースとして無料で手に入るソフトウェアを使うから案件の予算が安くつくと短絡してしまう、発注企業、広告代理店、ウェブ制作会社のディレクター、それどころかコーダやプログラマですら、そう思っているかもしれないということです。しかし、まじめに『安全なウェブサイトの作り方』の基準を WordPress 全体、とりわけコア・システムの監査にも向けるとすれば、誰がその挙動の品質を保証できるほど自力でコードを把握したり検査しているのでしょうか。ウェブ制作会社で WordPress のコア・システムの PHP ソースを具体的にソースコードとして読んだことがあり、隅から隅までどう書かれているかを把握している人など殆どいないでしょう(恐らく、情報セキュリティ会社の人々や、WordPress 専門のホスティング・サービスを提供している会社の技術者、それどころか WordPress について本を書いている人々ですら、そんな人は殆どいないと思います)。そして、もし『安全なウェブサイトの作り方』を画一的に全ての納品コードへ適用するというのであれば、WordPress 全体のソースコードにもセキュリティ監査が必要となり、それを自社では実施できないと言って外部の情報セキュリティ監査の会社へ委託したとすれば、そんな監査を本当にやった会社さんがあるかどうかは知りませんが、WordPress という CMS を監査する委託費用だけで数千万円になると僕は想定しています*3。そして、その費用は WordPress という CMS の脆弱性を検査するだけの費用であって、httpd や php のようなミドルウェアの検査費用は含まれていませんが、『安全なウェブサイトの作り方』ではそれらのミドルウェアについても脆弱性へ対策するよう求めているわけです。

*3「数千万円」という言い方で、単純に驚かしているわけではないという根拠を述べておきます。ウェブ・アプリケーションの監査には、以下のとおり、おおよそ三つのパターンがあります。ウェブ・アプリケーションの監査では、リモート・アクセスというクライアント・サーバ・システム(C/S)の特性を前提にした実務が想定されるので、スタンドアロンのデスクトップ・アプリケーションや C++ で書いたプログラムのような条件とは違って、ふつうは監査する側がソースコードに全くアクセスできません(脆弱性によってアクセスできてしまうことはありますが)。最後の三つ目のような監査は、相当な予算のある企業や地方公共団体や行政のプロジェクトか、あるいは監査する側が大きな責任を負える特殊な状況(例えば監査先の子会社など何らかの資本関係がある場合)だけで行えるものです。ウェブの制作会社が何の担保もなしに請負契約と同等の責任で受託するのは、端的に言って愚かでしかありません。WordPress のようなオープンソースのアプリケーションを使ってウェブサイトを制作・構築する場合は、それを委託者の代わりに使ってサイトを仕上げるという業務委託契約が当たり前であって、請負契約になると一定の基準で安全と言えるウェブサイトを完成させるという結果を保証しなくてはならず、単なるウェブの制作会社にそんな能力などまずありません

上から順番に費用が上がっていくのはお分かりだと思います。最初のツールを使った検証なら、Tenable Nessus, Burp, Nikto といった脆弱性検査ツールの多くは無料で使えるため、勉強するつもりがあれば誰でも自分でウェブサイトの監査ができるでしょう。また、独自のツールを開発している企業も多く、そういうところへ委託すればツールの使い方を自力で勉強しなくても済みます。ただし、自動化されたサービスやツールは対応できる範囲に限りがあり、手動で実施するペネトレーション・テストのようなものはできないと考えた方がいいでしょう。

次に、そのペネトレーション・テストは、その技能だけで特別な国際資格があるほどのスキルが要求されるものであり、簡単に言えば自社のサイトを監査の名目で攻撃してもらうわけです。詳しく分類するとホワイトボックス試験など幾つかありますが、どれであれ技術者が専門知識と高度なスキルで精密に監査することに違いはありません。もちろん、実装しているアプリケーションがあまりにも愚かな設計やコーディングで動いている場合、自動化された監査にも言えますが、その監査用のリクエストを処理することによってウェブサイトのデータが破壊されたり大きく書き換わってしまう可能性があるため、もちろんこのような監査はウェブサイトを公開する前に実施しなくてはなりません。そして、httpd などミドルウェアの挙動にも影響を与えてしまう結果が生じるリスクもあるので、このようなテストは他社との共有で使っているレンタルサーバなどでは実施するべきではありません。ペネトレーション・テストの費用は、例えば大手の株式会社ラックさんの解説にもあるとおり、専任の技術者が数か月もかかる工数で丁寧に検査するのが標準的なので、おおよそ2,000万円弱というのが妥当な費用だと思います。弊社でもディレクターやデザイナーを代理店あるいは個別の案件について専任で貼り付けている場合は、最低でも数千万円のオーダーで売り上げをコミットしてもらうのが当たり前です。

最後に、サーバの root 権限も渡したり、あるいは自社の事業所に設置されていたり他社のデータセンターにハウジングされているコンピュータを直に使ってもらうような前提で、OS レベルの検証から依頼するような非常に高度な監査を依頼するのであれば、これは監査だけではなく「コンサルティング」に近い業務となりますし、そこまでコミットしているからには結果に対して監査する側の企業は大きな責任を負うことになるので、当然ですが何かが起きて責任問題へ発展した場合の保険として多額の費用を求めます。これは IT コンサルや経営コンサルでも同じことです。このような事例では、公に受発注の事実すら出てこないことが多いため、費用の見積もりは推定になりますが、ペネトレーション・テストの工数を遥かに超える工数が現実に必要となるため、最低でも四桁の後半、アプリケーションの規模によっては億単位の費用になる可能性もあります。WordPress は、いまやウェブ・アプリケーションとしては、さすがに EC サイトなどオンラインでのビジネスを扱うほどの規模ではなくても、個人が開発して公開できるような規模を超えています。したがって、最後の監査方法でも数千万円はかかると思った方がよいでしょう。

WordPress のコア・システムを監査する場合、最後のコンサルティングまでは必要ないと言えるでしょう。確かに『安全なウェブサイトの作り方』には、DNS サーバの管理や SSL サーバ証明書の運用など、ウェブ制作会社が担当しているとは限らない項目も含まれていますし、ポートの開放状況などという項目に至っては root 権限を持っていない場合が多い受託の制作会社には対応不能と言えます。よって、せいぜい自社で実装したテーマやプラグインの挙動についてペネトレーション・テストを実施して品質を保証するていどのことができるにとどまるでしょう。しかし、それでも上記のとおり数百万円では済まない追加費用がかかります。

したがって、まずは WordPress の実装案件について、最低でも以下のような区分を設けて、責任分界を明確にしておくべきでしょう*4。ただし、以下で列挙した区分は、あくまでもウェブサイトの制作・構築を行って納品した時点までの業務という範囲に限られており、サイトを公開した後の定期的な監視やメンテナンスとして必要な業務は含んでいません。今回は『安全なウェブサイトの作り方』の基準に制作会社が制作・構築の業務でどこまで対応できる(すべき)かを議論しているからです。とは言え、監視やメンテナンス業務はウェブサイトのライフサイクルから言えば最も長期にわたって必要となるはずなので、本来はウェブサイトの制作・構築という業務とは別にメンテナンス契約を結ぶなどして体制や手順を決めておいた方が良い筈です*5

  1. ドメインや SSL サーバ証明書の取得
  2. ウェブ・サーバやデータベース・サーバ(ハウジングか IaaS なら OS のセットアップも含める)
  3. 各サーバのミドルウェア(Apache, Nginx, IIS, MySQL, MariaDB, PHP, あるいは関連するアクセラレータ等)
  4. ネットワーク(特に IaaS でバランサや VPS 接続の特別経路などを導入している場合)
  5. WordPress のコア・システム
  6. /plugins 以下にインストールする、サード・パーティのプラグイン
  7. /themes 以下に実装するテーマ一式
  8. /plugins 以下に実装するプラグイン
  9. それ以外の自社で制作した納品物(WordPress 関係のディレクトリ以外に置く静的ファイルなど)
  10. ウェブサイトで公開するファイルやコンテンツ
  11. ウェブサイトで公開しないファイルやコンテンツ

*4僕が携わっている受託案件でも、WordPress を使ったサイト制作・構築については、『安全なウェブサイトの作り方』で対策が求められている項目の多くは受託側の制作会社に保証を求められるものではないという理解が発注側の広告代理店さんにも共有されつつあり、WordPress のコア・システムに脆弱性が見つかったという報道が広まった場合でも、トップクライアントから「瑕疵」だと責められるようなことにはなっていません。もちろん、中小零細企業を相手にした直接取引の場面では、こうした WordPress のコア・システムに見つかったような脆弱性を「瑕疵」だと称して、受託側から賠償だ何だと金銭をせしめてやろうとか、あるいは分割払いにしている制作費の残金支払いを拒否するような「剛腕」経営者や「辣腕」担当者なるチンピラがいてもおかしくありません。そうした金銭にかかわる法的な問題は本稿の範囲を超えますし、ここで何らかの対策を示して責任を負うつもりもありませんので(そもそも中小零細企業や個人事業主を相手にビジネスをするなら、こういうリスクは想定するべきでもあります)、具体的な事案については法律家に相談してください。

*5ただし、このようなメンテナンス契約という名目の「ホームページ詐欺」が横行したこともあったため、発注する側に不安を抱かせないよう工夫する必要はあるでしょう。現在では WordPress のコア・システムは自動アップデートが働くので、自社から納品したオリジナルのコードがアップデートに追随して正しく動作するかどうかをメンテナンスすればいいだけの筈ですから、サイトの規模にもよりますが大した作業でもなければ高額にもならないはずです。)

まず、1. ~ 4. については、WordPress を利用する案件に限った話ではありません。ウェブサイトを構築して納品するのであれば、どういう案件でも必要な管理項目です。大手広告代理店の案件では、コーポレート・サイトだと 1. ~ 4. はトップクライアント企業の情報システム部門などが管轄していることが多いので、責任どころか制作会社が全く関与できない事例もあります。『安全なウェブサイトの作り方』のチェックリストには HTTPS プロトコルによる通信を前提にしたチェック項目(たとえば 4-(iii))がありますから、このような項目については管理する責任がどこにあるかを明確にしておきましょう。

あるいは、クラウド・サービスを利用して期間限定のキャンペーンで公開するサイトを構築するといった事案では、ドメインや SSL サーバ証明書の取得・管理からネットワーク管理(機器や帯域の管理というよりも、アクセス数に伴う負荷のモニタリングや、必要に応じた負荷分散や契約内容の更新)にいたるまでを、ウェブサイトの制作側が全て担当することもあります。こういう場合は、それぞれの利用サービスで設定されている「サービスレベル合意書(SLA: Service Level Agreement)」を参考に、受託側がどこまで対応できるかを事前にクライアントと協議しておくべきです。WordPress という CMS についても同様ですが、受託制作側はそれらのサービスを利用しているだけですから、現実には何かが起きたときに対応できる範囲も責任も限られているということを発注側と合意しておく必要があります。負荷が上がってサイトの表示が重くなってきたときに、新しいインスタンスとロードバランサを作成して負荷を分散させるという作業がスキルとしてできること、それからそういう対応ができる IaaS を利用していること、そして必要に応じて作業をどれくらいの時間で完了できるかという見込みなどを話し合っておいた方がよいでしょう。こういう状況を単純に「トラブル」として描いてしまうと、クライアントにしてみれば面倒な話でしかなくなるわけですが、他方でサーバが重くなるというのは数多くの人たちがサイトにやってきている証拠かもしれないのですから、必ずしも迷惑なことではありません。

次に、WordPress という CMS のコア・システム(5.)を本案件で利用するという採用の責任がどこにあるかを決めておかなくてはなりません。これは、もちろん WordPress を使う案件だけに限った話ではないので、それなりに経験がある広告代理店関係者やディレクターなら既にお判りだと思います。受託側が起案の責任を全て負う場合もありますし、発注側から「こんなサイトを作りたいので、こういう条件で提案してほしい」という提案の要望、あまりウェブ制作の案件では見かけませんが、「提案依頼書(RFP: Request for Proposal)」を出して起案を促したり見積もりを要求している場合は、当然ですが発注側にも与件を漏らさず正確に出す責任があるのですから、WordPress を CMS として採用する責任だけではなく、起案させる際の責任も負います。ともあれ、ウェブサイトの制作・構築において、仕様の最終決裁は発注側にある場合が多いので*6、発注側が何も責任を負わなくていいというわけにはいきません。なお、本稿で言う「コア・システム」とは、オープンソース・ソフトウェアとして WordPress.org から無料でダウンロードできるソフトウェア一式(コミュニティ版)のことです。.zip ファイルか .tar.gz ファイルとしてダウンロードできます。これらはアーカイブファイルなので、ウェブ・サーバへ展開して利用するのですが、いまでは夥しい数のファイルで構成されています。ウェブサイトのフロントエンド側(サイトのビジターがアクセスする側)だけでなく、管理システム側のプログラムも含みます。ちなみに、いまでは多くのレンタルサーバが契約者画面のボタン一つで WordPress を自動インストールするサービスを提供していますが、レンタルサーバによっては特殊なプラグインが同時にインストールされることがあるので(情報セキュリティ対策用のものが多い)、本稿ではレンタルサーバで自動インストールされる WordPress は対象外とします。

*6請負契約の場合は必ずしもそうではありません。発注側に全く制作実務の知識やスキルがなくて制作業務を代行してもらうどころか、ウェブサイトが何であるかを知らないとか、自分たちのやりたいことや KPI に照らして受け入れ検査する能力するスキルもない場合は、起案どころかサイト設計の与件まで制作会社が立てなくてはならない場合もあります。

6. の「サード・パーティのプラグイン(発注側でも受託側でもない、それどころか WordPress のコア・システムを開発している Automattic 社でもない者が開発した、WordPress 用のプログラム)」は、そのサイトで何をしたいかというクライアント(あるいはディレクターや IA などウェブサイトの UX を設計している人)の要件に応じて、ウェブサイトを制作したり構築する側が数多くの中から選択しています。たとえば、WordPress の管理システムへログインするときに HTTPS 通信を強制するプラグインが幾つかあります(本来は .htaccess で mod_rewrite の命令を書くだけでも対応できます)。同じ目的に応じて使えるプラグインは複数ありますから、そのどれを使うかは誰かの責任で吟味して選ばなくてはなりません。たいていの場合は、発注企業側にプラグインの是非を検討して決められるようなスキルをもった人物はいないので、受託側が必要かどうかを決めて、使えそうなプラグインを探して、吟味し、提案・採用します。なお、ディレクターの方々に助言として書いておくと、先ほど書いたように、管理システムへのアクセスを HTTPS 通信に強制するなどということは、プラグインなど使わなくても実現できます。また、プラグインを気軽に使っている人たちの中には、PHP で開発できるスキルさえあればどうにでもできることを、わざわざプラグインに頼って実装しているウェブ制作会社もあるわけです*7。したがって、サード・パーティのプラグインについても、発注側としては動作の保証くらいはしてほしいところだと思いますが、現実には自社で動作検証して保証の範囲に含められるウェブ制作会社は非常に少ないと言えます。得てして、プラグインをたくさん使いたがるコーダやプログラマに限ってスキルがないからです。おおよそ、僕が経験してきたキャンペーンサイトやコーポレートサイトの制作・構築業務では、WordPress のプラグインなど三つか四つも使えば多い方だと言えます。

*7ということで、たいていのウェブ制作会社のコーダやデザイナーには、プラグインを自力で開発したり、他人が書いたプラグインのコードを検証するようなスキルはありません。というか、PHP を扱える社員が全くいなくても WordPress のサイトを構築しているウェブ制作会社は山ほどあります(彼ら自身がレンタルサーバで、ワンクリックで WordPress をインストールしているだけだったりするからです)。

したがって、基本的には上記の一覧で 1. ~ 6. は納品時の品質あるいは動作保証など現実にはできるものではないので、メンテナンス契約を交わすのが妥当だと思います。そしてメンテナンスの対応範囲にセキュリティ・インシデントの発生やサーバの負荷上昇等を想定しておいて、WordPress のコア・システムやプラグインの脆弱性が報告された場合やサーバの負荷が上がってきた場合などに、所定の手順で対応をとる約束にしておけばいいでしょう。WordPress をはじめとするオープンソースのアプリケーションを使うような事案では、そのアプリケーションの提供元、WordPress なら Automattic 社や、サード・パーティのプラグインの開発者にすら何の品質保証もできないわけなので(それは何も無料だからではありません)、それらをユーザとして利用しているだけの制作会社にアプリケーションの動作品質保証にかかわる契約内容不適合責任があるかのような契約を負わせるのは現実的ではないと言えます。長年にわたってウェブ制作の案件に携わってきた当事者として言わせてもらえば、もし安いというだけで WordPress を提案したり導入するのであれば、手抜きや低予算という理由だけでオープンソースのアプリケーションを選択してしまうという愚かさの責任を受発注者が共同で負うべきなのです。

そして、残りの 7. ~ 11. にあたる項目をみましょう。7.(/themes 以下に実装するテーマ一式)については、もちろんディフォールトで入っている幾つかのテーマは除外します。それらのライセンスや著作権や責任は制作会社にありません。ただ、ディフォールトのテーマを使って WordPress のサイトを制作したり構築する場合は、それがいかにディフォールトのテーマであっても、制作会社には採用した責任くらいはあると思います(ナショナル・クライアント案件では殆どありえない状況ですが、個人事業主のサイトを制作する案件ではよくある話です。テーマは出来合いのものを使って、コンテンツだけ制作会社に写真をレタッチしてもらったりページの文章を書いてもらうというわけです)。そして、いったん他人のテーマを使って構築した場合は、テーマもアップデートという措置の対象となる場合がありますから(もちろん、テーマファイルも PHP として動作しうるからです)それを自動でアップデートさせるに任せるか、それともアップデートで不具合が生じないかどうか、メンテナンス契約を交わして制作会社に検証してもらってからアップデートするか、決めておく方がよいでしょう。もちろん、アップデートしてテーマの表示が崩れたり記事が表示できなくなるような現象は起きていませんが、今後もずっと起きないという保証はありません。

8.(/plugins 以下に実装するプラグイン)は、自社で開発したプラグインを実装するのであれば、情報セキュリティ監査や動作品質の保証範囲とするのは当然のことです。もちろん、WordPress 用のプラグインの大半は WordPress と同じライセンスである GPL によって公開されるのが原則ですから、どういうプラグインのソースコードでも、それを改変して案件に利用できます(ただし、改変したソースコードをライセンスに従って適正に公表している会社は少ない)。ただし、他人の書いたプログラムを自分で改変して商用のサイトへ実装した場合は、それがいかにオープンソースのライセンス(“WITHOUT ANY WARRANTY”)に従うプログラムだとは言え、それを現に書いて実装までした制作会社の責任が、WordPress のコア・システムと同じようになくなるかと言えば、そんなことはありません。当該のウェブサイトを制作・構築するにあたって CMS を使うとか、WordPress を採用するという決裁に受発注双方の責任があるのと同じく、改変しただけのプラグインであろうと、元になるプラグインを選んだり、改変したプラグインを提案し採用した責任は残ります。

残る項目、つまり 9.(それ以外の自社で制作した納品物(WordPress 関係のディレクトリ以外に置くプログラムなど))、10.(ウェブサイトで公開するファイルやコンテンツ)、11.(ウェブサイトで公開しないファイルやコンテンツ)については、色々なファイルが想定できるので、一概にどういう状況で考慮しなければいけないかは難しい判断となります。さしあたって思いついたものを列挙してみると、以下のようになります。

これらについては、もし追加コンテンツがあれば監査の対象になりますし、サイトを制作するのであれば当然ながら多くの静的ファイルもサーバへアップロードして利用すると思うので、それらも監査の対象です(スタイルシートや JavaScript のコードを監査しない事例は非常に多いので困惑しているところですが)。また、アップロードした画像や PDF については、どちらかと言えばそれらのアップロードしたファイルと言うよりも、アップロードする先のディレクトリに設定されているパーミッションや所有権の確認をした方がよいわけですが、ともかく監査の対象になります。そして、テスト時点でアップロードしたファイルをウェブサーバに放置するのはたいていの制作会社では違反行為なので、そういうものは置いてあるものを監査の対象にするということではなく、不要なファイルがないかどうかを監査して、もし放置していれば削除するべきです。もちろん、それ以外に非公開のファイルがサーバに置かれているという正当な事情はたくさんあります。たとえば、サーバのログファイルはたいていのウェブサーバで所定のディレクトリに貯まるでしょう(そのディレクトリになくてはいけないのかという点は、もちろん厳密には吟味できます。そのディレクトリが FTP アカウントでもアクセスできるなら、その是非を議論する意味はあります)。また、問い合わせフォームの開発では、問い合わせ内容をサイト運営側へ通知するメールを配信すると同時に、サーバへログファイルにして問い合わせ内容を保存するように開発する場合もあります(あるいはデータベースに登録することもあります)。そうした、非公開のファイルがウェブサーバで保存・管理されていることもありますから、どういう仕様によってサイトを制作・構築するかという全体の事情を考慮して、監査の対象を設定しなくてはなりません。そして、そうした受託側の立てた仕様にもとづいてサーバに生成・保存されるファイルについては、その多くを受託側が責任を負うでしょう。(納品してから後は発注側の担当者が WordPress の管理画面から記事を公開したりファイルをアップロードするというのであれば、それらのコンテンツについては、当然ですが発注側が負います。今回は、納品時の監査に絞っているので、納品した後のリスクや責任の所在は議論しません。)

冒頭に戻る

「後編」として、『安全なウェブサイトの作り方』に付属しているチェック・シートの各項目を取り上げて、WordPress サイトの制作・構築で制作会社が対応できる(すべき)範囲がどこまでなのかを議論する予定です。しばらくお待ちください。


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

Twitter Facebook