人間の存在を前提としないセキュリティ対策は無意味なのです
結構、IT系の話ってハードルが低く感じるのか「PCが得意な人」レベルの方がSNSで簡単に発信しがちなので、実は私の観測範囲の中では「半数以上の投稿で内容に誤りがある」事が判っています。
そこで、長年（約29年間）PHPを使って（構築・開発・保守・運用）きた事で得た知識をベースに整理しておきたいと思います。
目次
読んでいただくための前提知識
そもそもPHPとは何か？
PHP（PHP: Hypertext Preprocessor）とはコミュニティベースで開発されているオープンソースの汎用プログラミング言語で、実はウェブベースのアプリケーションの多くで使われているほか、スマホアプリのバックエンド（サーバー側処理部分）でも多く使われております。私自身も、自分のウェブサイトを自力で構築していた時代にはPHPで開発していましたし、その後、スマートフォンのアプリ開発を行っていた時代にはバックエンドをPHPで開発していました。今では弊社や弊社の御客様のサイトで使っているWordPressやEC-CUBEというCMS（Content Management System）で使われております。
弊社での運用体制について
参考になるかどうかは判りませんが、参考までに弊社での運用体制を御紹介いたします。
弊社では公開サーバー上で動いている全てのプログラム（OSからミドルウェア、アプリケーションまで含む）を随時メンテナンスしております。基本的には毎週木曜日の0時から実施しております。脆弱性などについても「脆弱性の緊急性に応じて」判断しており、原則としては定期保守のタイミングで適用しています。が、今回みたいに緊急度が高いものに関しては対応バージョンがリリースされてから速やかに保守を行います。
ただ、今回の場合は偶然にも定期保守の日にぶつかったので纏めて処理しました。
定期保守はアップデート適用からサーバー上に置かれている各サイトの動作確認まで含めて30分程度で終えています。ですので、弊社にとっては保守は「日常」の作業であると言えますし、逆に、日常の作業とするために実施の時間や、やり方などを工夫はしています。
ちなみにPHP自体の脆弱性修正などのアップデートは年に数回くらいあるので、ある意味「日常」です。決して特別なものではないですし、作業負担も大きくありません。
誤情報（WordPressガー）
今回の騒ぎで多いのがWordPressが悪であるように、騒動に便乗して投稿する方が多いことです。
曰く「脆弱性が多い」だから「危険である」
曰く「保守コストが高い」
先ずは「脆弱性が多い」だから「危険である」という投稿についてですが、WordPress本体の脆弱性は決して多いわけではありません。多く見えるのは「数多あるプラグインの個々の脆弱性の積み重ね」であるからですね。実際、運用してみると判るんですけどプラグインを多めに使っていても「弊社的日常の保守」で十分対応可能です。しかも9サイトまとめて作業して開始から終了まで30分程度で済みますし。そして「弊社的日常の保守」でも安全な運用が十分出来ております。そもそも、「脆弱性が多いから危険」なので使うなと言うなら、何故、皆さんはWindowsを使い続けるのでしょうか？不思議です。
そして「保守コストが高い」は「弊社的日常の保守」をやっている限りは「そんな事はありません」です。実際、今回も（保守契約しているのに）業者から高い見積が出てきたとかいう投稿も見かけましたが、そうなる理由は簡単なんですね。それは「弊社的日常の保守」を行わず長期に渡って放置してきたから作業量が大きくなってしまうためなのです。要するに保守料を受け取っている業者がサボったツケをユーザーに押し付けているだけなのです。実際、弊社で調査したサイトの多くでは脆弱性が山盛りあるサイトが放置されているのを確認していますし、そういう所でも、業者とはしっかり保守契約を結んでいたりするんですよね。保守契約を結んでいるのに脆弱性が山盛りあるってウソでしょ？って思うかもしれませんが、全ての業者ではないものの少なくない数の業者では保守料を受け取っていても日常の保守を行っていないのが実態だったりします。そして、そういうサイトが目立たないように改竄されていたりするんですよね。残念ながら。
誤情報（WordPressを使っていなければ対応不要）
この手の誤情報が一番無責任で凶悪なんですよね。
何故なら「PHPを使っているのはWordPressだけではない」からです。なんなら、自分でOSを選んでインストールするタイプのレンタルサーバー（VPS＝Virtual Private Server）では標準でPHPがインストールされ使える状態になるものもあります。そうなると「WordPressを使っていないから今回の対応をしない」という選択肢はあり得ません。また、PHPで構築されたアプリケーションって意外と多いので、使っている全アプリケーションの調査をした上で判断することが必要です。
もし、これを読んでいる方で「騙された！」と思った方は今一度確認をしてくださいね。
誤情報（静的なサイトにすれば今回の対応は不要）
静的なサイトと言うのはHTML（Hyper Text Markup Language）とCSS（Cascading Style Sheets）だけで作られたサイトですけど、確かにサイト自体は脆弱性を産み出すことはないので安全ではあります。ただ、中には勘違いしてJavaScriptを使っちゃう人がいるみたいなんですが、それをしちゃうと途端に脆弱性を産み出してしまう可能性が出てきますので危険です。
でも、先にも書いた通り「サーバーに標準でインストールされ使える状態になってしまう場合もある」ので、静的サイトだから対応不要とはならないんです。必ず「自分の所のサーバーは何が入っているのか」調べてから判断することが必要です。本当に使っていないのならばサーバー上から削除することも選択肢として考えた方が良いです。「標準で入っているものは削除できない」と言うわけではないので。但し、削除するのならば「本当に使っていない」事を慎重に調査されることをオススメ致します。
そもそも（大変重要なポイント）
弊社での運用体制でも御紹介したように「日常の保守」をしっかりやっていれば、今回の対応も日常の延長線上にあるので騒ぐ話ではないんですよね。
では、何で騒ぎになったのかというと…
その前に
オープンソースソフトウェアを使う上で守るべきルールというのがありまして、それがオープンソースソフトウェアを安全に使うために重要なポイントであったりします。
それは、脆弱性に関連した情報は安易に表に出してはいけないという事なんですね。一部のオープンソースソフトウェアでは「セキュリティ対応のバージョンがリリースされる前に登録者に通知を行う」という仕組みが運用されているものがあります。その場合には「通知内容を外部に漏らしてはいけない」という条件が付いた形で通知をもらえたりします。ある程度、修正バージョンへのアップデート等が進むまでの2〜3日は脆弱性の内容を発表しないことで攻撃が始まる前に対応が進むように配慮した結果ですね。そういった内容を安易に外部に漏らせば対応が進む前に攻撃が始まってしまいますので被害を拡大してしまう可能性が高くなります。結果としてオープンソースソフトウェアの信頼性を揺るがしかねない事態となってしまいます。
実は…
今回は、その情報漏洩が起こってしまったんですね。世界的に「バカ」と批判されていますけど、その結果として「概念実証コード（Proof of Concept Code：PoC）が複数流通してしまい、実際に攻撃の痕跡も観測されたそうです。弊社管理のサーバーでは幸い観測されませんでしたが。
あと、実際に攻撃を掛けると何が出来るのかを収録した動画が誤って公開されてしまったのも火に油を注ぎ、攻撃が急増したとも言われています。そのため、世界中に多数あるPHPがインストールされたサーバーが実質的にゼロデイ攻撃に晒される事態になってしまいました。
しかも、その事態に対応して対策等を周知した内容が「非セキュリティ関係者」によって内容が不正確に解釈されて拡散されてしまったことも大きかったと認識しています。
今後、同じ騒ぎを起こさないためには
「日常の保守」をしっかり行いましょう。
僅かな手間を省くから大事になるのです。大事にならないように日頃から世話をしていれば良いだけです。
「不正確な情報」に振り回されないようにしましょう。
末席ながら専門家の私でさえ、信頼できる情報セキュリティの大家の皆さんをSNSでフォローして正確な情報把握に努めております。もちろん、一次情報も確認しています。
「保守範囲」を明確にしましょう。
今回のPHPの脆弱性はウェブ制作会社が不得意とする「サーバー側」の問題なので、CMSを含むコンテンツ側のみが保守範囲の場合は保守対象外となります。その為、別途見積となり高額な料金と、日程的に大幅な遅れが発生することが多いのです。
資料請求/御相談等は
弊社サイトからどうぞ！
または右側にある「仕事の相談・依頼」からでも結構です！
