2020年も引き続きお付き合いいただきます様お願い申し上げます。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、2020年最初の記事は『WordPress』に関しての投稿からスタートしたいと思います。

昨年12月の記事、『PHPの最新版PHP7.4リリース』にて『PHP』の最新バージョン『PHP 7.4』に関して触れましたが、『WordPress』における対応状況はどうなっているのか？

今日はそれについてです。

WordPressのPHP7.4対応状況は？

『WordPress 5.3 “Kirk（カーク）”』がリリースされたのが2019年11月12日、『PHP 7.4』がリリースされたのが2019年11月28日ではありますが、現在の『WordPress 5.3系』は『PHP 7.4』で正常動作するレベルにはあります。

『wordpress.org』のニュース記事を見ても、『WordPress 5.3はPHP 7.4を完全にサポートすることを目指しており、非推奨機能を削除し、互換性を確保するための複数の変更が含まれている。』とされています。

ただし、細かいところでは未だ完全ではないところもあるようですが、それは『将来的にはエラーになる』とか、『非推奨』への対応が残っているといった程度で、動作する上では全く問題ないと言えるレベルにはあります。

これは『プラグイン』にも言えることで、一部のプラグインにおいても同程度の状態にあります。

（これらは単純に、『デバッグモード』で動作させてみればわかります。）

私の場合、幸いなことにサーバーが早い段階で『PHP 7.4』に対応してくれたこともあり、年末年始の休暇中にテスト環境にて『PHP 7.4』を試すことができました。

（最近は面倒なのでローカル環境を構築していません。。。）

現在の『WordPress』の推奨ホスティング環境は『PHP 7.3以上』ですから、無理に『PHP 7.4』に変更する必要性はないとは思いますが、今後、『PHP』はさらにパフォーマンス改善を図っていきますので、WEBにおいてパフォーマンスがある程度重視される昨今においてはプラス材料にはなるでしょう。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いた『HSTS Preload List Submission』は登録できなかったとしても特別問題はないのですが、『共用サーバ』を使っている場合には登録できないケースがあったりします。

HSTSのPreload Listが登録できない

『共用サーバ』の場合、全く知らない個人や事業者が同一のサーバに同居していますが、そのすべてのユーザーが適切に『HTTPS化』できているとは限りません。

その場合にホスティング会社はどのようなセッティングをするか？

『HSTS』は使えても『includeSubDomains』や『Preload』を無効にすることがあります。

理由として、『HTTPS化』への対応が適切にされていなかったりすることで表示上の問題が発生するケースがあるからです。

その場合、『HSTS Preload List Submission』の要件にある『includeSubDomains』と『Preload』が満たせないために登録できないということになります。

これを何とかしたい場合には以下の内容を『.htaccess』に記述してみて下さい。

<IfModule mod_headers.c>

Header always unset Strict-Transport-Security
Header set Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
</IfModule>

これで何とかなるケースがあります。

また、『www』サブドメインで正規化している場合、『.htaccess』でのリダイレクトではなくhtmlの『meta refresh』を使ったリダイレクトでないとうまく行かないことがありますので、苦肉の策ではありますがそれを使います。

（Googleは『meta refresh』を推奨していませんが、『やむを得ない場合』にはNGとはしていないので問題ないかと思います。）

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

私もここ最近で気づかされたことがあります。

Webサーバーの『Apache』が『Apache 2.4』からアクセス制御の記述方法が大きく変わっていることを。

Apache2.4におけるアクセス制御

『.htaccess』などに記述するアクセス制御ですが、『Apache 2.2』と『Apache 2.4』では記述方法が異なります。

例えば、すべての要求を拒否する場合に『Apache 2.2』では

Order deny,allow
Deny from all

と記述していましたが、『Apache 2.4』では

Require all denied

と記述します。

ただし、多くのホスティング会社では従来の『Apache 2.2』の記述方法でアクセス制御が可能となるよう、『Apache』に『モジュール』を追加して対応していると思われます。

それならば問題はないのでは？

となるところですが、

サーバーの高負荷などが原因でその『モジュール』が正常に動作しないことが発生すれば別です。

『500 Internal Server Error』となりWebサイトが表示されなくなります。

つまり、そういったエラーの要因を一つでも減らしておくには『Apache 2.4』の記述に変更すべきと言えるわけです。

明日に続く。。。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

昨今、DNS（Domain Name System）インフラを狙った攻撃が増加していることを受け、ICANN（Internet Corporation for Assigned Names and Numbers/アイキャン）が『DNSSEC（Domain Name System Security Extensions）』の導入を呼び掛けています。

では、『DNSSEC』を導入することで何が変わるのでしょうか？

DNSSEC導入で防げるリスク

このDNSインフラの改ざん被害、米国土安全保障省も全省庁に警戒と緊急対策を指示しているほど深刻な問題です。

ではDNS情報の改ざんは検知できないのか？

『DNSSEC』を導入すればそういった改ざんは検知できます。

『DNSSEC』はデータに対してデジタル署名を行うことで改ざんを防ぐ技術ですから、その導入が進めば多くのDNS情報の改ざんが検知できることになります。

（※　すべての攻撃を防げるわけではありません。）

つまり、リスクを減らすことができるわけです。

この『DNSSEC』、日本においてはさらに遅れた状態になっています。

『DNSSEC』はドメインのレジストラとホスト、両方がそれに対応している必要があり、一部のレジストラにおいては有償オプションとして対応しているものの、ホスト側においてはなかなか対応に踏み切っているところは少ない状態にあります。

また、ユーザー側の認知度も低い状態です。

それらを考えると日本における普及はまだまだ時間がかかりそうですが、少しでも多くのレジストラやホスティング会社の対応、そしてユーザーの利用が進むことを願うばかりです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

最近、ウェブサイトのパフォーマンスが微妙に落ちているように思えたこともあり、改めてCDN（content delivery network）を使った実証実験をしてみました。

CDNが効果的か否かの追求

約1年前に投稿した『CDNが速度的に逆効果となる時』という記事では、昨今のホスティング会社がサーバの仕様を大幅にパワーアップさせていることなどから『CDN』がパフォーマンス的に逆効果になるケースもあることを書きましたが、あれから1年、他のウェブサイトとの比較検証結果もあり、再度テストを行ってみることにしました。

結果、CDNを使用した時の方がわずかにパフォーマンスが良かったと言えます。

ただし、私の場合はCDN側にある機能のわずかな部分しか使用していません。

幸い、契約しているサーバがある程度活躍してくれているため、CDN側にて新たに追加された機能のみをプラスαする程度しか必要なかったのです。

つまり、元からあった機能は使用していないということです。

このように、CDNも進化していますので、たまにはCDN側の機能もチェックし、機能追加などがされているようであれば何パターンかテストしてみるのも良いと思います。

そして、CDNを使用した時のパフォーマンスが使用していない時と比べて同等以上と判断できればCDNの使用もありと言えます。

セキュリティ面でのメリットもありますから。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

ホームページサイトなどにWordPressを使われている方、プラグインはどれくらい使われていますか？

それは何のために使われていますか？

WordPressのプラグインが不要な場合

昨今、ホスティング会社もハードウェアの仕様をかなりパワーアップさせています。

例えば、最新のCPU、大容量メモリ、SSDなどを採用するなどし、サーバのパフォーマンスアップを行ったりしています。

また、WordPressユーザーなどのためにPHP7系統への対応も積極的に行われるようになっています。

これらのことから言えるのは、従来、WordPressなどのツールを使ってホームページサイトなどを構築していた場合、パフォーマンス改善のために使われていたCDNやキャッシュ系のプラグインが不要とも言える環境が整ってきていることです。

つまり、それらのプラグインを使わなくても従来プラグインを使っていた時以上のパフォーマンスが得られるということです。

逆に言えば、パフォーマンス改善を目的としたプラグインを継続して使ったとしても思うほどの効果は得らない可能性があるとも言えます。

これらのことを含め、米国のあるホスティング会社ではこういったプラグインを自動的に削除したりもしているようです。

WordPress本体と同様に、プラグインはリスクを伴います。

そのプラグインに脆弱性があれば攻撃を受ける可能性もありますし、無駄にプラグインを多用していても高負荷になるだけの場合もありますから、効果が見られないのであれば使わない方が良い選択とも言えます。

一度自社（自店）の環境をチェックし、効果がなさそうなものは外してみるのも良いのではないでしょうか。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

昨日、米国のあるドメインレジストラ（指定事業者）からメールが届きました。

それによると、以前から延期となっていた『ルートゾーン情報の電子署名鍵（KSK：Key Signing Key）の更新（ロールオーバー）』が承認されたとなっています。

ICANNのロールオーバー承認による影響

今年の夏の時点では2018年10月11日の実施を予定していることにはなっていたものの、それはICANN（The Internet Corporation for Assigned Names and Numbers）理事会の承認待ちという状態でした。

しかし、レジストラからのメールによるとそれが最近承認されたとなっており、予定通り今月11日にKSKのロールオーバーが実施されることになります。

これによって影響を受けるのは、基本的には『DNSSEC（Domain Name System Security Extensions）』が有効になっているドメインに限りますが、以前の記事にも書いた通り、KSKロールオーバーによってDNS応答のパケットサイズが通常の倍以上になってしまった場合、ホスティング会社においてDNSキャッシュサーバへの対応がなされていなければDNSSECが有効になっていなくても影響を受ける可能性があります。

つまり、その場合は名前解決ができなくなり、ウェブサイトが閲覧できない状態になる可能性を秘めています。

行える対応策としては、

１．DNSSECが有効になっている場合、それを一度無効にする。それでも解決しない場合はISP（インターネットサービスプロバイダ）から新しい鍵を取得し、レジストラ側の更新を行う。

２．DNSSECが無効になっている場合、前述の通りホスティング会社のDNSキャッシュサーバへの対応によると思われますので、契約のホスティング会社に問い合わせてみることになります。

来週は自社（自店）運営サイトなどに注意です。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

『Meltdown（メルトダウン）』と『Spectre（スペクター）』のCPU脆弱性問題を受けて、1月上旬にメーカーなどを通じて順次修正パッチがリリースされていたものが、その後に、このパッチが原因でリブート（再起動）が増える不具合が報告されていました。

この不具合を受けて、Intelは脆弱性対応パッチの導入を中止するよう、メーカーやエンドユーザーに呼び掛けていまいしたが、これも概ね不具合修正が完了しているようです。

CPUの脆弱性対応パッチの適用を

1月の終わりにCPUの脆弱性対応パッチの導入中止の呼び掛けから1ヶ月半ほど経過しましたが、2月の終わり頃からこの不具合に対する修正版が順次パソコンメーカーなどに提供が始まり、その後、順次パソコンメーカーなどがファームウェアのリリースを再開しています。

かなり古いCPUを搭載した機種のファームウェアは未だ調査中のところも残っていたりしますが、ここ数年のパソコンに関してはそろそろ脆弱性対応パッチを適用しても良さそうなタイミングになってきました。

これに関してはホスティング業者なども様子見をしていたようで、順次セキュリティメンテナンスの予定を発表しているところも出てきています。

各パソコンメーカーでは、『Meltdown（メルトダウン）』と『Spectre（スペクター）』に対する情報をホームページ上に掲載していますので、それらを確認の上、早い段階で計画を立て、順次ファームウェアのアップデートを行うことをお勧めします。

また、同様にWindowsなどもそれに対応した最新のパッチを適用する必要があります。

参考：https://meltdownattack.com/ or https://spectreattack.com/

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

以前、このブログでもCDN（content delivery network）の活用をお勧めしたこともありますが、必ずしもそれが良いわけではないケースも存在します。

では、それはどのようなケースなのでしょうか？

CDNが速度的に逆効果となるケース

インターネットの普及に伴い、ウェブサイトによっては大量のアクセスが集中し、反応の遅延などが多く見受けられ、時には反応しないケースもあります。

そんなケースにおいては今でもCDNは有効的なものであると言えます。

また、それほど大量のアクセスが集中していなくても、元々のオリジナルサーバの処理能力がそれほど高くない場合においてはそれをカバーしてくれるものとしても有効的です。

しかし、ここ最近のホスティングサービス各社の状況を見てみると、処理能力の高いCPUに大容量メモリ、ストレージにはSSDを採用するなどし、ホスティング会社自身も設備をリニューアルさせたりしています。

そのようなケースにおいては逆にCDN経由にしていることが速度低下につながることもあります。

では、どのように判断するか？

単純に、CDN経由にした場合とそうでない場合とで速度測定などをしてみて比較し、判断すると良いでしょう。

ただし、セキュリティ性や安定性を優先して求めるのであればCDNを活用した方が良いとも言えますので、優先事項が何であるかによってCDNの活用を考えるべきでしょう。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

今回の『CPUの脆弱性問題』は、WindowsパソコンやMacのみならず、世の中の多くのIoT機器に影響を及ぼしています。

脆弱性の問題は修正パッチを適用することで一応対処できますが、問題はそれだけでは終わりません。

※　現在、修正パッチの適用は中止するようアナウンスが出ていますのでご注意ください。

CPUの脆弱性による隠れた影響とは

今回のCPUの脆弱性問題は、それに対応した修正パッチを適用することによってCPUの処理能力に影響が出ます。

最近購入したハードウェアであれば気づくほどの影響はなさそうですが、2年前や3年前、それ以前に購入したハードウェアの場合にはかなりの影響があるとされています。

最大で25%程度も処理能力が低下するものすらあるようです。

CPUの脆弱性による処理能力の影響範囲

前述の通り、影響は多くのIoT機器に影響を及ぼすわけですから、当然サーバー関連にも影響は及びます。

つまり、社内サーバー、クラウドサービス、ホスティングサービスなどにも影響が出るわけです。

実際問題、米Intel（インテル）がCPUの脆弱性対応パッチの適用の中止を呼び掛ける前にそれを適用してしまったところで影響が出ています。

これらのことを受け、アメリカではIntel社に対して複数の集団訴訟にまで発展していることが報じられています。

現状リリースされている同一のCPUにおいてこの問題が解消されることはないのかもしれません。

しかし、セキュリティとパフォーマンスなどの問題を比較した場合、セキュリティを優先せざるを得ないことは言うまでもありません。