「Web サイトのセキュリティ」を問われる場面が増えています
最近、取引先から届くセキュリティチェックシートに、コーポレートサイトについての項目が含まれるケースが増えているのではないでしょうか？ サイバー攻撃の増加に加え、サプライチェーン全体でセキュリティ対策を求める流れが強まっているためです。
デジタルキューブの相談会でも、「取引先の外部公開資産のスキャンで、サーバのポートが開いていると指摘された」「80ページを超えるセキュリティ基準に沿って回答を求められた」といったご相談をいただくようになりました。中には、1項目でも満たせなければ取引できない、という基準もあります。
この記事では、WordPress で運用しているサイトについて、チェックシートでよく問われる項目と、答えられる体制のつくり方を整理します。
目次
よく問われる項目と、答えるために必要なもの
チェックシートの書式は会社ごとに違いますが、問われる内容はおおむね次の6つに分けられます。
| 分野 | よくある質問 | 答えるために必要なもの |
|---|---|---|
| ネットワーク・インフラ | WAF を導入しているか。DDoS 対策はあるか。不要なポートは閉じているか | 構成の説明と、利用しているサービスの仕様 |
| 脆弱性対策 | 脆弱性診断をいつ、誰が実施したか。パッチはどのくらいの期間で適用しているか | 診断の報告書、アップデートの実施記録 |
| アクセス管理 | 管理画面へのアクセスを制限しているか。多要素認証や SSO を使っているか。パスワードの管理方法は | 設定内容と運用ルール |
| ログ・証跡 | 誰が、いつ、何を変更したかを記録しているか。何日分保存しているか | 変更履歴とアクセスログ、保存期間の定め |
| 可用性・復旧 | 稼働率の目標はあるか。障害時、どのくらいの時間で、どの時点まで戻せるか | 稼働率の保証（SLA）、復旧目標（RTO/RPO）、バックアップの仕組み |
| 委託先の管理 | 運用を委託している先とどんな契約をしているか。委託先は第三者認証を持っているか | 契約書、責任分界の文書、委託先の認証情報 |
見てわかるとおり、「対策をしているか」だけでなく、「それを文書や記録で示せるか」が問われます。実際に対策していても、報告書や契約の形で残っていなければ、回答欄を埋めることはできません。
ログは記録する場所が3つに分かれる
なかでも答えにくいのが「ログ・証跡」です。WordPress サイトのログは、どこで記録するかによって3種類に分かれます。
サーバやネットワークの操作ログは、ホスティング事業者が取得します。
テーマやプラグインのコード変更は、Git などのバージョン管理を使うと「誰が・いつ・何を変えたか」を残せ、問題があれば元に戻すこともできます。
記事の編集など管理画面での操作は、アクティビティログ系のプラグインで記録します。
ただし、管理画面の操作ログは、保存期間を決めずに貯め続けるとデータが肥大化し、サイトの動作が重くなることがあります。何日分を残すかを先に決めておけば、チェックシートの「保存期間」にもそのまま回答できます。
標準の仕様と求められる水準を突き合わせる
もうひとつ大切なのは、利用しているサービスの標準仕様と、取引先の要件を突き合わせることです。たとえば、バックアップの保存期間が標準で3日のところ、要件が7日であれば、延長の手配が必要になります。
逆に、多要素認証や SSO を求められても、運用の負担を考えて管理画面への IP 制限で要件を満たす、という判断もあります。仕組みを足すことだけが答えではありません。
WordPress サイトで回答が詰まりやすい理由
WordPress 本体は、脆弱性が見つかれば修正版が公開され、更新を適用すれば対処できます。リスクになるのは、その更新が止まったまま運用されている状態や、メンテナンスされていないプラグイン・テーマです。回答が詰まる原因も、多くの場合は CMS の選択よりも運用体制にあります。相談会でお話を伺うと、いくつか共通点が見えてきます。
共用のレンタルサーバなので設定を変えられない
一般的なレンタルサーバは、複数のサイトが同じサーバに同居しています。ポートの開け閉めや WAF の細かな設定、ログの取得範囲は事業者が決めているため、利用者側では変えられません。指摘を受けても「構造的に直せない」という状況になりがちです。
公開後、誰も保守を担当していない
サイトを公開したあと、制作会社はデザインやコンテンツの更新だけを担当し、PHP や WordPress 本体のバージョンは誰も見ていない、というケースは少なくありません。数年放置された結果、PHP も WordPress も更新できない状態になっていることもあります。また、この状態では「パッチをどのくらいの期間で適用しているか」という問いに答えられません。
専用のクラウド環境を使っていても同じです。OS が古いままだと、PHP のバージョンを上げる前にサーバそのものの入れ替えが必要になり、脆弱性が公表されてもすぐに手が打てません。保守会社に設定の変更を頼んでも、見積りが出るまでに数か月かかった、というお話を伺ったこともあります。
対策が担当者の頭の中にしかない
社内の詳しい担当者が個別に対策をしていても、手順や記録が残っていなければ、チェックシートには書けません。担当者が異動や退職をすると、何をしていたのかもわからなくなります。
自社と委託先の守備範囲が決まっていない
サーバは事業者、WordPress は制作会社、コンテンツは自社、と関わる人が多いのに、どこまでを誰が担うかを決めていないことがあります。すると、チェックシートの項目について誰に聞けばよいのかがわからず、回答が止まってしまいます。
よくあるのが、インフラの保守会社と WordPress の保守会社が別々で、不具合が起きるたびに原因の切り分けが進まないケースです。双方から「自社の範囲外」と言われ、どちらにも属さない独自のフォームなどは、結局社内で抱えることになります。
まず回答者を層ごとに切り分ける
チェックシートを受け取ったら、最初に各項目を「誰が答えるべきか」で分けると、作業が進めやすくなります。サイトは大きく3つの層でできているからです。
| 層 | 主な対象 | 答える人 |
|---|---|---|
| プラットフォーム | ネットワーク、OS、ミドルウェア、WAF や CDN などの配信基盤 | ホスティング事業者 |
| アプリケーション | WordPress 本体の設定、テーマ、プラグイン、管理画面のログイン方式 | サイトを構築・保守している会社（または自社） |
| 外部サービス | お問い合わせフォーム、検索、MA ツールなど | 各サービスの提供事業者 |
たとえば「管理画面のログイン方式」や「パスワードの定期変更」は、SSO を使うのか、IP 制限をかけるのかといった実装の方針で答えが変わります。これはプラットフォームではなく、アプリケーション層の担当者が答える項目です。
この切り分けをせずにホスティング事業者が先回りして答えると、実装を担う側の方針と食い違い、あとで手戻りが起きることがあります。逆に言えば、層ごとに「この範囲は委託先が答える」と決まっていれば、自社で抱える項目はかなり減ります。
ホスティング事業者を選ぶときは、責任の範囲を文書で示しているか（責任共有モデル）、セキュリティチェックシートへの回答に対応しているかを確認しておくとよいと思います。
答えられる体制をつくる3つの選択肢
回答に詰まった項目を埋めるには、大きく3つの方法があります。サイトの性質、そして社内でどこまで担えるかで選ぶのが現実的です。
| 自社で整える | 公開側を静的化する（Shifter） | 統制まで契約で担保する（Amimoto Governance Plan） | |
|---|---|---|---|
| 考え方 | 専用の環境を用意し、保守・監視・記録を自社で回す | 公開サイトから WordPress と PHP をなくし、攻撃される対象そのものを減らす | 保守・監視・証跡・報告を、委託先との契約と文書で示す |
| 向いている サイト | インフラと WordPress に詳しい人材が社内にいる | 更新頻度が高くなく、フォームや検索を外部サービスに置き換えられる | フォームや会員機能など動的な処理が必要で、監査や取引先への説明が求められる |
| チェックシートへの効き方 | 回答の材料はそろうが、体制の維持と記録づくりに人手がかかる | 公開側は静的ファイルだけになるため、診断の範囲がシンプルになる | 稼働率保証、脆弱性検査の報告書、ログ、チェックシート回答までを委託先が用意する |
| 注意点 | 担当者に依存しやすく、異動や退職で体制が崩れやすい | 公開側で PHP が動かないため、使えない機能がある | 費用は上がる。必要な水準に合わせてプランを選ぶ |
静的化できるサイトなら、まず Shifter を検討
コーポレートサイトのように更新頻度が高くないサイトなら、公開側を静的化するのがいちばん手軽です。公開されるのは HTML や CSS などの静的ファイルだけになるため、WordPress を狙った攻撃は成立せず、脆弱性診断の対象もシンプルになります。
動的な機能が必要で説明責任も問われるなら Governance Plan
一方で、フォームや会員機能をサイト上で動かす必要があり、取引先や監査法人に体制を示す必要がある場合は、WordPress をそのまま運用しながら統制を固めることになります。
Amimoto Governance Plan は、こうした企業向けの WordPress 運用基盤です。AWS WAF や AWS Shield Advanced を含むインフラ、ステージング環境で検証したうえでのアップデート代行、管理画面の IP 制限、変更履歴とアクセスログの記録、定期的な脆弱性検査、24時間365日の監視をひとつの契約にまとめています。インフラから WordPress までを一社で見るため、不具合が起きたときも原因の切り分けから対応まで窓口はひとつです。
セキュリティパッチは確認を待たずに速やかに適用し、メジャーアップデートはステージング環境で検証してから本番に反映します。脆弱性の公表から数時間で攻撃が始まる例もあるため、「確認待ち」の時間をつくらない運用です。
稼働率や復旧目標（RTO/RPO）は契約書の別紙で定義され、セキュリティチェックリストへの回答も標準で含まれます。チェックシートの「委託先とどんな契約をしているか」という問いに、契約書そのものを示して答えられる形です。なお、社内の方針で自社の AWS アカウント上に環境を持ちたい場合は、同等の運用を自社アカウント上に構築する形（エンタープライズプラン）にも対応しています。
インフラと保守を別々に契約する「2階建て」との違い
Amimoto の通常プランでインフラを任せ、WordPress のアップデート代行を別に契約する「2階建て」の構成もあります。必要最低限のアップデート対応はこれでカバーできます。
ただしこの構成では、24時間365日の有人監視、詳細なレポート、SLA はオプション扱いになります。監査や取引先への説明まで求められる場合は、これらをひとつの契約にまとめた Governance Plan のほうが、回答の材料をそろえやすくなります。
サイトごとに選び分けることもできる
3つの選択肢は、会社でひとつに決める必要はありません。たとえば、まず複数のサイトを Amimoto にまとめて移し、更新頻度の低いコーポレートサイトや英語サイトから順に Shifter へ移す、という段階的な進め方もあります。保守の対象が減るほど、費用も運用の負担も軽くなります。
まずは「どこが空白になっているのか」を確かめるところから
セキュリティチェックシートで問われるのは、対策の有無に加えて「それを示せるかどうか」です。回答に詰まる項目は、自社の運用体制の空白を映していると考えることもできます。
まずは手元のチェックシートを、プラットフォーム・アプリケーション・外部サービスの3つの層に分けてみてください。そのうえで、自社では答えられない項目がどの層に集中しているかを見ると、どの選択肢が合うかが見えてきます。
デジタルキューブは、WordPress 専業で約20年、上場企業を中心に構築から運用保守までを手がけてきました。私たち自身も TOKYO PRO Market 上場企業として、監査で何を問われるかを同じ立場で経験しています。
「今の体制で、どの項目に答えられないか」を整理するところから、個別相談会でお手伝いできます。
関連リンク
- Amimoto Governance Plan の詳細を見る
- Governance Plan の資料をダウンロードする
- Amimoto の個別相談会を予約する
- WordPress サイトを静的化、高速・安全・メンテナンスフリー Shifter
当社へご興味をお持ちいただきありがとうございます。
「こんなことやってみたい！」と、ぜひ気軽にご相談ください。
担当者よりご連絡差し上げます。