皆さん、こんにちは。

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

さて、今日は過去にも一度触れ、かつ『PHP』で作られたアプリケーションや『WordPress』などの『PHP』を使ったツールを使用している方向けにはなりますが、『APCu』と『OPcache』に関してお伝えします。

APCuやOPcacheの導入で高速に

まずはおさらいです。

『APCu』も『OPcache』も『PHP』のアクセラレータで、『PHP』の処理を高速化してくれるものになり、『APCu』は『ユーザーデータのキャッシュ』、『OPcache』はコンパイルした『コードのキャッシュ』として活躍してくれます。

つまり、キャッシュに保存されたものを再利用する仕組みができあがりますのでパフォーマンス向上につながります。

以前は『PHP 5.6系』のパフォーマンスアップということでご紹介しましたが、当然ながら『PHP 7.x系』においてもパフォーマンスアップとして活躍します。

『PHP 7.x系』はパフォーマンス改善されているから不要と思うかもしれませんが、閲覧するユーザーからすればパフォーマンスがさらに良くなることは歓迎される話ですからメリットはあります。

実際に『PHP 7.x系』でそれらを使用した場合には体感できるほどパフォーマンスが改善されますので、使えるのであれば使わない手はないと言えます。

設定方法などは過去記事の『PHP5.6系パフォーマンスUp-2』を参考にしてみてください。

ただし、過去記事の『WordPressの更新が止まる訳』の最後に書いた通り、レアケースかとは思いますが『Opcache』が『WordPress』の更新に影響を与える可能性があるかもしれません。

そのような場合は『OPcache』を一時的にコメントアウトなどで外すか、『opcache_reset』を使ってキャッシュをリセットすれば問題は解消されます。

皆さん、こんにちは。

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

さて、ウェブブラウザにMozillaの『Firefox』を使われている方で、複数のエディションを並行して使われている方には朗報かもしれません。

プロファイルの仕様に変更があり、従来よりも楽なものになりました。

Firefoxのプロファイル仕様が変更に

先日リリースされた『Firefox 67』からプロファイルの仕様に変更があり、『Nightly』、『Beta』、『Developer』などの複数のエディションで共有する仕様になっていたプロファイルがそれぞれに独立します。

つまり、各エディションにおいて専用のプロファイルが用意されるようになったのです。

そのため、従来ではプロファイル管理用のコマンド『firefox.exe -p』を使って作成や管理を行わなければいけなかったものが不要になります。

『Nightly』、『Beta』、『Developer』だけであればあまり事業者的には関係のない話しになりそうですが、この仕様は法人向け長期サポート版である『Firefox ESR』においても変更が行われる予定になっています。

（現在は未対応のため、おそらく次のメジャーバージョンアップで対応されます。）

また、各エディション間でのユーザーデータは『Firefox Sync』を使えば同期させることもできるようです。

ご参考までに。

さて、この『Password Checkup』とは？

皆さん、こんにちは。

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

日本国内においてもウェブブラウザのシェアが半数を超える『Google Chrome』ですが、今回、スタンフォード大学の協力を得て『Password Checkup』というものを開発しました。

では、『Password Checkup』とは？

Password Checkupで漏えいチェック

さて、『Google Chrome』の拡張機能として登場した『Password Checkup』とは、名前の通りパスワードをチェックしてくれるものです。

Chromeブラウザでアクセスしているサイトへのログイン情報が第三者に漏えいしていないかをチェックしてくれ、入力したIDとパスワードが流出データと一致していれば警告を発するようになっています。

元々、Googleアカウントに限ってはパスワードの漏えいや悪用を検知するとパスワードが自動的にリセットされる仕組みになっており、その仕組みの効果もあってリスクは通常の1/10程度にまで抑えられているとされています。

今回リリースされた『Password Checkup』はこのGoogleアカウントの保護機能の仕組みを応用し、他のサイトにおけるログイン情報の漏えいなどを検知できるようにしたものです。

ログイン情報が流出したアカウントは40億以上もあるとされており、そういったアカウントの流出は自身ではなかなか気づかないものです。

そのため、今回リリースされた『Password Checkup』などを使うことで警告が発せられた時点で即座にパスワード変更などの対応を取ることができることから、不正利用などによるデータ侵害を未然に防ぐことが期待できそうです。

参考：『Google Security Blog “Protect your accounts from data breaches with Password Checkup”』

それにより、非常に多くの労力を強いられることになってしまったそうです。

皆さん、こんにちは。

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

ある方はSNSをはじめとするウェブサービスにおいて『2要素認証（Two Factor Authentication）』を使っていました。

そして、ある時スマートフォンの機種を変更した際に悲劇が起きてしまったそうです。

2要素認証は安全だがリスクもある

2要素認証（Two Factor Authentication）というのは、ウェブサービスにログインする際、ID・パスワードなどで認証させた後、さらにスマートフォンなどでワンタイムパスワードを使って認証させるといった、2つの要素で認証をすることですが、これは安全ではあるものの若干リスクを伴うとも言えます。

何がリスクか？

2要素目の認証部分はスマートフォンなどにQRコードを読み込ませて登録したり、アプリケーションを入れ、そのアプリケーションで認証させたりします。

そして、もしスマートフォンを機種変更したり、トラブルで初期化してバックアップから復元するようなことが起きた場合においてはそれは元に戻りません。

簡単に言えば、スマートフォンの機種変更やバックアップからの復元の際には『2要素認証を解除』しておく必要があるということです。

もし解除していなかった場合、『バックアップコード』などにてウェブサービスにログインすることは可能ですが、これも保管していなかったとしたら最悪なことが起きる場合があります。

ウェブサービスに完全にログイン不可能になります。

とは言え、救済方法が全くないわけではありません。

登録されている携帯電話番号宛にSMS（ショートメール）で認証コードを送って救済してくれるものもあります。

しかし、SMS（ショートメール）に認証コードを送って救済してくれるウェブサービスばかりではありません。

サポートセンターに連絡をし、そのウェブサービスに登録されている情報を細かく提示した上で完全に情報を一致させるなどしなければ解除してもらえないものも多くあります。

このように、最終的な解決までには非常に労力を要することにもなります。

もっと最悪な場合はアカウントが使えなくなる場合もあり得るでしょう。

2要素認証（Two Factor Authentication）を使われている方、くれぐれもお気を付けください。

注：2要素認証（Two Factor Authentication）と2段階認証（Two Step Verification）は厳密には異なるものですが、前述のような事例の場合にはどちらにおいても一時解除した方が良いと言えます。

皆さん、こんにちは。

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

Googleが今月導入を予定しているアルゴリズムはウェブページの表示速度に関わるもので、やはり、ユーザーにとってより良い状態にあるものが評価が高くなるとされています。

ウェブページの表示速度は速い方が高評価

ウェブページの表示速度は、ある程度ストレスのない範囲で表示されているのであれば問題ないと判断されている方、今回のアルゴリズムは少々違うようです。

シンプルに、表示速度は速ければ速いほど高評価になるアルゴリズムが導入されるようなのです。

今までの場合、論外的なページ速度でなければあまり影響はありませんでしたが、今回は別です。

逆に言えば、パフォーマンス改善にも力をいれてきた方にとってはそれが報われる時が来そうです。

そして、Googleのスタッフは質問に対してこのようにコメントしたようです。

Q：ページ速度が速くなればランキングに良い影響を与えるのか？

A：多少影響する。

ということは、極論、同じ評価を受けていた2つのページが存在したとします。

その際、AのページとBのページに若干であっても表示速度に違いがあった場合、表示速度の速い方がランキング的に上に位置することになります。

どの程度変化していくのかはわかりませんが、いくつかの情報を見ている限りでは、少しずつ変化していく（評価が上がっていく）感じのようです。

まずはページ内の情報の質などがあっての話しではありますが、それ以外の加点項目があるというのは非常に良いことだと感じます。

悪用された場合には管理者権限が取得され、デバイスに保存された情報が流出してしまう可能性があると警告されています。

皆さん、こんにちは。

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

人からスマートフォンやタブレットの選択を問われた場合、私は必ず『iPhone』や『iPad』と回答します。

仕事で使う業務用だけでなく、プライベート用のものであっても同じです。

それは何故だと思いますか？

iPhone・iPadを選択するのは確率論

iPhoneなどのiOSデバイスに脆弱性が全くないわけではありません。

しかし、Androidと比較した場合、iPhone・iPadの方がリスクが少ないと判断できます。

現に、iPhoneやiPad向けのセキュリティソフトは無いに等しく、あってもウェブアクセス保護用だけで、Android向けには内部も保護するものが多数出ています。

ここからも想像がつくように、確率的にiPhoneやiPadなどのiOSデバイスはAndroid OSに比べて被害にあう確率が低いと考えられます。

この世界に絶対という100%の話しはありませんので、絶対ではありませんが、単純に確率論としてはiOSデバイスを選択する方がリスクが低いということだけです。

仕事で使う業務用としてであれば、なおさらリスクの低い方を選択するということになるでしょう。

ある人がこのようなことを言っていました。

『出張した際、スマートフォンにトラブルが起きてもApple Storeは直ぐ近くにはほぼない。携帯キャリアであれば見つかる。だからAndroidを選択している。』と。

言いたいことはわかりますし、確かにその通りとも言えます。

しかし、携帯キャリアが見つかったとしても、その場でスマートフォンが直るとは限りませんし、逆に言えばそれほど簡単には壊れないとも言えます。

さて、あなたならばどちらを選択されますか？

皆さん、こんにちは。

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

昨日、IPAがとてもありがたいページをサイト上に公開してくれました。

今日はそれに関してお伝えします。

IPAのセキュリティ情報ページとは

IPAが公開した『セキュリティ情報』のページとは、ウェブサーバ上で動作しているサーバ用ソフトウェアのうち、日本で広く利用されているオープンソフトウェアを対象としてまとめてくれたものになります。

対象としているのはウェブサイト運営者、ウェブサイト・ウェブシステムを構築する事業者、システム管理者、ということになっています。

情報源はインターネット上で公開されている製品情報とセキュリティに関する情報にはなりますが、週1回程度の更新を予定しているため、定期的に当該ページをチェックすることである程度一括して情報把握ができます。

もちろん、従来の重要なセキュリティ情報は随時更新されます。

そして、このページでは以下のオープンソースソフトウェアに関する製品及びセキュリティ情報が掲載されます。

・Apache HTTP Server

・Apache Struts

・Apache Tomcat

・ISC Bind

・OpenSSL

・WordPress(日本語)

・Joomla!Japan

また、各オープンソースソフトウェアの掲載内容は以下のものが掲載されます。

・開発者情報（ウェブサイトへのリンク）

・ダウンロード情報

・セキュリティ情報

・最新バージョン情報

・脆弱性などに対する注意喚起情報などの参考情報

以上のような感じになっております。

ウェブ担当者の方などは是非活用されると良いです。

参考：『サーバ用オープンソースソフトウェアに関する製品情報およびセキュリティ情報』

これにより、あらゆるところに偽のメールが送りつけられるなどし、フィッシング詐欺などが多発しています。

皆さん、こんにちは。

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

さて、皆さんもご存知の通り、送られてきたメールの差出人が『rakuten.co.jp』であったり、『apple.com』であったりし、件名や本文も本物にそっくりの状態で作られているために本物と勘違いしてしまう偽装メール。

こういったものを防ぐ手立てはないものでしょうか？

ドメイン偽装は防ぎようがないのか？

まず、ドメインを偽装するというのは簡単にできてしまいます。

そして、これを完全に防ぐことはできません。

そのため、大手企業はもちろんのこと、中小企業などにおいてもドメインの名前解決に用いられるDNSというものに対してそれなりのものが書かれていたりします。

それによって本物であることを認証させたりしているわけですが、正直なところ、メールを受け取る側においても意識をしない限り、実際のところは役に立たないことも多いです。

例えば、常日頃からIT系の業務に携わっている人であったりセキュリティ意識の高い人であれば、疑わしいメールが送られてきた瞬間にメールのヘッダ情報を確認したりします。

しかし、そうでない人はそこまでのことは行いませんし、ヘッダー情報を見てもわからないという人が大半です。

ではどうすれば良いのか？

１．業務上、メールのやりとりを行う相手先とは一定のルールを設ける

例えば、双方においてSPF認証は必須とし、メールサーバーにおいては認証していないものを隔離するか削除する措置を取るというのも1つの手でしょう。

２．社内においてマニュアルを作成し、全体に周知徹底を図る

３．一般の消費者に対して偽装メールが届いてしまった場合、ウェブ上で確認方法や注意喚起などのアナウンスを行う

ただし、３に関しては受信者からの問い合わせ連絡などがない限り大半の企業では把握していないことも多いかと思います。

それを早期に把握するため、DNSにDMARCというものを記述し、レポートが受け取れる状態にしておくことがお勧めです。

これにより、以前お伝えした通りのものが破棄されます。

皆さん、こんにちは。

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

以前、『Symantec系SSL証明書の停止』という記事にてお伝えした通り、Symantec系の証明書に対する信頼が破棄されました。

Symantec系の証明書への信頼破棄

GoogleのウェブブラウザChromeが正式にChrome 66となりました。

以前の予告通り、Symantec CA（認証局）によって2016年6月1日より前に発行された証明書に対する信頼は破棄されます。

従って、Symantec CAによって2016年6月1日より前に発行された証明書を使用している場合、信頼される認証局から発行された新しい証明書に変更する必要があります。

（本来はChrome 66の正式リリースより前に変更しておくべきです。）

また、10月後半でリリース予定のChrome 70においては、Symantecルートに結びついている証明書すべてに対して信頼が破棄されます。

ただし、DigiCertがSymantecの証明書事業を買収した後にDigiCertから再発行された証明書は除外されます。

今一度証明書を見直し、該当する場合は直ちに証明書の置き換えが必要です。

以下、参考までに掲載しておきます。

サイト運営者向けの情報

Chrome 66 以降、Symantec によって 2016 年 6 月 1 日より前に発行された証明書に対する信頼が破棄されます。現時点では、Chrome 66 は Chrome ベータ版ユーザーに対して 2018 年 3 月 15 日に、安定版ユーザーに対して 2018 年 4 月 17 日頃にリリースされる予定です。

Symantec CA によって 2016 年 6 月 1 日より前に発行された証明書を使用しているサイト運営者は、Chrome 66 のリリースよりも前に、既存の証明書を Chrome が信頼する認証局から発行された新しい証明書に置き換える必要があります。

また、Symantec は 2017 年 12 月 1 日までに信頼できる公式の証明書の発行と運用を DigiCert インフラストラクチャに移行し、この日付以降に古い Symantec インフラストラクチャから発行された証明書は Chrome で信頼されなくなります。

Symantec の古いインフラストラクチャとそれらが発行したすべての証明書に対する信頼が完全に破棄される Chrome 70 は、2018 年 10 月 23 日の週前後にリリースされる予定です。これにより、Google に以前公開された独立して運用されている監査済みの下位 CA が発行した少数の証明書を除いて、Symantec ルートに結び付けられているすべての証明書が影響を受けます。

Symantec の既存のルート認証局および中間認証局から証明書を取得する必要のあるサイト運営者は 2017 年 12 月 1 日まで Symantec の古いインフラストラクチャから取得することができますが、これらの証明書は、Chrome 70 がリリースされる前に再度置き換える必要があります。また、Symantec のインフラストラクチャから発行された証明書は、有効期間が 13 か月に制限されます。代替策として、サイト運営者は Chrome が現在信頼している他の認証局から代替証明書を取得することができます。これらの証明書は、こうした信頼の破棄や有効期間の制限の影響を受けません。

by Google Developers Japan

しかし、『EC-CUBE2.13系』は高速化された『PHP7』には対応しておらず、昨今の『ウェブの高速化』へ今一歩進めない状況となっています。

皆さん、こんにちは。

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

今からEC-CUBEを使ったショッピングサイトを構築する方は『EC-CUBE3.0系』で構築すれば、それは『PHP7』に対応していますので問題ありませんが、『EC-CUBE2.13系』で構築されたものを何とか高速化したいと思ったことはありませんか？

これ、実は方法がないわけではありません。

EC-CUBE2.13系でPHP7に対応させる

昨年の9月、EC-CUBE2は開発者向けの『αバージョン』として、『EC-CUBE2.13系』の最新バージョンである『EC-CUBE2.13.5』をベースにした『EC-CUBE2.17.0α』というものをリリースしています。

これは、高速化された『PHP7』対応への要望が多かったことから、コミュニティへの参加者の協力を得て行われています。

ただし、正式版としてのリリースではないため、使用しているプラグインが対応していないことが想定されます。

特に、クレジットカード決済系のプラグインが対応していない場合には要注意です。

もしこの辺りがクリアできるのであれば、カスタマイズしている部分を修正するなどすれば『PHP7』対応の『EC-CUBE2』として動作させることが可能です。

※　プラグイン以外にもまだ多くの課題を抱えているため、テスト環境による慎重な検証が必要と思われます。

現在、これに関しての開発者情報は『GitHub』に移行しているようで、それらの入手は以下のURLからとなります。

EC-CUBE2.17.0αの入手：https://github.com/EC-CUBE/eccube-2_13/releases/tag/eccube-2.17.0-alpha

既知の課題：https://github.com/EC-CUBE/eccube-2_13/milestone/5

PS：安全優先で考えると正式リリースまで待った方が良いことは確かです。ご注意ください。