皆さん、こんにちは。

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

冒頭に書いた内容、知名度の高い企業などではあり得ない話ではありますが、そうではないローカルな事業者のサイトなどにおいては当り前のように存在します。

では何故そのような状態のままなのでしょうか？

アドレスバーが見られていない

いくつか理由はあると思いますが、商品などを購入するショッピングサイト以外、多くのWebサイトにおいてはあまり気にされていない気がします。

特に、現在主要なブラウザで『HTTPサイト』に表示されている『安全ではありません』や『保護されていない通信』などの警告表示は『アドレスバー』の先頭部分に表示されますが、そこはあまり気にされていないのではないでしょうか。

気にされていないというよりも目に入ってきていない気もします。

ただし、それは訪問するユーザー側の話です。

運営者側からすると、『コストをかけてまで．．．』といった、あまりユーザー保護を意識していない運営者が多いことも事実でしょう。

では、これがもっと極端なん施策がとられていたらどうでしょうか？

そのサイトにアクセスした途端、ページ全面に『安全ではありません』や『保護されていない通信』などの警告表示が出た場合です。

流石にそれ以上先へ進もうとはしないはずです。

これは極端な施策ではありますが、ユーザー保護を目的とするならばもう少し極端な施策を半ば強制的にでも行わせるくらいのことが必要なのかもしれません。

皆さん、こんにちは。

業務改善を行う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・業務コンサルタント、高橋です。

既に大半のブラウザで対応が打ち切られている『SHA-1証明書』ですが、先日Apple（アップル）も無効とする方針を表明しています。

AppleもSHA-1証明書を無効化表明

最近では当り前になっている『Webの暗号化（HTTPS化）』において『SSL/TLS証明書』というものが必要になります。

その『SSL/TLS証明書』において『SHA-1』というハッシュアルゴリズムが使われたものがある（あった）のですが、今回、Appleはそれを無効化するというものです。

これに関しては『Google Chrome』、『Mozilla Firefox』、『Microsoft Edge』、『Internet Explorer』においては既に対応が打ち切られており、大手のブラウザの中ではAppleが最後になったという感じです。

Appleの対応としては、『iOS 13』と『macOS 10.15』において『SHA-1』で署名された証明書を信頼できないものとし、『SHA-2』のハッシュアルゴリズムを使用しなければならない規定を発表しています。

もし『SHA-1』の『SSL/TLS証明書』がそのまま使われていた場合、同OSのSafariiブラウザでのWebサイトの読み込みには失敗する可能性があるとしています。

この『SHA-1証明書』問題に関しては既に『Google Chrome』、『Mozilla Firefox』、『Microsoft Edge』、『Internet Explorer』においてWebサイトをブロックする対応がされていますので問題はないかと思いますが、古いバージョンのブラウザを使っている方は要注意であることと、万が一まだ『SHA-1証明書』を使っているのであれば即切り替えを行うことが必要です。

正式に『Chrome 70』がリリースされたということです。

皆さん、こんにちは。

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

とうとうGoogle Chrome 70がリリースになりました。

これにより、HTTPS化（常時SSL化）されていないWebサイト（ページ）ではさらに注意が必要となります。

Chrome70リリースで赤色警告始まる

今回のChrome 70で気をつけたいのは、ノーマル色（グレー）の『！保護されていない通信』に加えてフォームなどへのデータ入力においては『！保護されていない通信』のように赤色の警告表示に変わるようになることです。

ノーマルなグレーであれば気づかない可能性もありますが、フォームなどにデータを入力したと同時に赤色の警告表示に変わりますのでさすがに目立ちます。

これが意味するものは『信頼性の低下』、つまり『イメージダウン』です。

安全性以外にも心理的な要素がありますので、人によっては問い合わせなどを止めてしまう可能性も秘めています。

ユーザーが不安を覚え、Webサイトから離脱してしまい、問い合わせや商品購入の減少を招く可能性があるとしたらどうしますか？

この段階においてもHTTPS化（常時SSL化）を行わないことにメリットはありません。

早急に対応を行うべきです。

また、ほとんどが対応済みかと思いますが、2016年6月1日以前にシマンテック、GeoTrust、RapidSSLが発行したSSL/TLSサーバ証明書はChrome 70より完全に信頼が停止されます。

証明書の再発行費用は発生しないため、まだ再発行を受けていない方は早急に対応されることをお勧めします。

警告対象であるかが不明な場合は以下のサイトからチェックしてみてください。

『Google Chromeによる警告をチェックする』

これにより、非HTTPSサイト（ページ）への影響が見込まれます。

皆さん、こんにちは。

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

以前より申し上げてきた通り、とうとうChromeブラウザにて警告表示が始まりました。

今日はその話題を少しだけ。

Chrome68リリースで警告表示始まる

今回のChrome 68では、暗号化されていないサイト（ページ）、つまりHTTPSではない、HTTPのままのサイト（ページ）に対して以下のように警告を表示します。

『！保護されていません｜www.example.com』

この警告はアドレスバーの先頭に表示されます。

さらに、10月にリリース予定の『Chrome 70』では、HTTPのままのサイト（ページ）でユーザーがパスワードを入力しようとした際、もっと目立つように色付きの警告表示になる予定です。

『！保護されていません｜www.example.com』

このような感じにです。

これらの警告表示による訪問者の離脱は避けたいところですので、まだ『HTTPS化』をされていない方、早急に対応されることをお勧めします。

PS：Firefoxではもっと影響度の高い警告表示になる可能性があります。

皆さん、こんにちは。

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

このブログでも何度となく取り上げてきた『WebのHTTPS化』に関して、2月にもお伝えした通り、Googleのブラウザ『Chrome』では全面的な警告が行われるようになります。

しかし、これに対する認識が不足している事業者もまだまだ残っているため、再度お伝えすることにします。

Chrome68では全面的な警告になる

以前からお伝えしている通り、Googleのブラウザ『Chrome』の『バージョン68』からは『非HTTPS』サイト（ページ）に対して全面的な警告表示を出します。

そのようになってしまう『Chrome 68』は来週の7月24日にリリース予定となっています。

現時点では、お問い合わせフォームなどのフォームに文字入力をした時に『！保護されていません』と警告するにとどまっていますが、来週リリース予定のバージョンではそうはいきません。

お問い合わせなどのフォームに文字入力するか否かは関係なくなり、シンプルに『非HTTPS』サイト（ページ）すべてに警告表示をするようになります。

これはGoogleのブラウザ『Chrome』に限った話しではなく、Mozillaのブラウザ『Firefox』においても同じ方向へ切り替わります。

あなたがそのウェブサイト（ウェブページ）を閲覧しようとするユーザー（訪問者）であった場合、それはどのように感じるでしょうか？

おそらく、大半の方は『危険』とか、『怪しい』とかのマイナスのイメージを持ってしまい、直ぐにそのサイト（ページ）から離れてしまうことでしょう。

それが自社や自店のサイト（ページ）にて起こってしまう。

つまり、『イメージダウン』、『信用低下』といったことを招くことになってしまいます。

それを回避する方法は1つしかありません。

ウェブサイト（ページ）を全面的に『HTTPS化（暗号化）』することです。

余談ですが、このような話しを何度お伝えしても理解を示さない方がおられるのも事実です。

おそらく、実際に何かが起きてみないと実感がわかないのだろうと思います。

その際、表示されたのは暗号化されていない『www.nta.go.jp』でした。

皆さん、こんにちは。

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

さて、WebサイトのHTTPS化は結構進んできたということは間違いないのですが、そのHTPPS化が中途半端な状態で行われていることがよくあります。

では、実際にどのような状態になっているのでしょうか？

WebサイトのHTTPS化での不備とは

まず、この国税庁のサイトを例にあげると、検索結果に表示されるリンク先が『HTTP』のものと『HTTPS』のものと混在しているようです。

今年の3月末、国税庁のホームページはリニューアルされたわけですが、その際、各ページのサイトマップはHTTPSに書き換えを行っているはずです。

ここから推察すると、まずは検索エンジン側のインデックスが間に合っていない可能性が高いと言えます。

しかし、これに関しては簡単に対処できます。

HTTPでのアクセスをHTTPSにリダイレクトすれば問題は起きません。

例えば、以下のようなルールを.htaccessに記述しておけば防げます。

RewriteEngine on

RewriteCond %{SERVER_PORT} !^443$ [OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

この他にも、せっかくHTTPS接続で読み込まれたHTMLでも、中に含まれているコンテンツのURLが『HTTP』となっている場合には『mixed content』となってしまい、『保護された通信』とはなりません。

これらのことにも気を配り、何度が表示確認をした上で、日々問題が発生している部分は改修していくことも重要です。

皆さん、こんにちは。

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

昨日の記事を読んでいただければお分かり頂けると思いますが、2017年5月30日施行の『改正個人情報保護法』の施行により、事業用のホームページサイトにて個人情報を取得する場合（お問い合わせフォームなど）、その個人情報の利用目的をサイト内にて公表する必要性があることをお話ししました。

これとは別に、個人情報保護法上のガイドラインにある、『安全管理措置』という観点から考えた場合、個人情報取得時における施策は何もなくて良いのでしょうか？

個人情報保護法上のガイドライン

以前、『改正個人情報保護法施行日迫る』という記事でも触れましたが、今回の『改正個人情報保護法』において『5,000人要件』が撤廃されましたので、5,000人以下の個人情報を取り扱う事業者であっても『個人情報取扱事業者』となります。

そのため、個人情報を保護するための『安全管理措置』は必要です。

ただし、個人情報保護法上のガイドラインにて示されているのはあくまでも手法の例示であり、個別具体的に何が必要であるかは明記されているわけではありません。

※　安全管理措置が何もされておらずに問題が発生した場合は行政指導が入ることがあるでしょう。

個人情報保護法とWEBのhttps化（暗号化）

前述の通り、個人情報保護法上の『安全管理措置』に対して事業者のホームページサイトにおける個人情報の取得にWEBの暗号化が必須条件となっているわけではありません。

しかし、これは今回の個人情報保護法改正以前の問題であり、ホームページサイトなどにおいて個人情報を取得する場合、最低限そのページが暗号化されているのは当り前の話しです。

万が一それが原因で問題が発生した場合（それがなされていれば問題が発生しなかった場合）、そのホームページサイトの運営事業者は民事的に訴えられることもあり得ます。

もし未だWEBのhttps化（暗号化）がされていないのであれば、これを機にSSL証明書を取得してWEBを安全な状態で運営することです。

各ブラウザにおいても、httpsではない、httpのままの非暗号化ページに対しては警告を出しはじめており、近い将来においてユーザーからの信頼を失墜するものにもなり得てしまいます。

それを避けるためにも、このような改正を機に、ホームページサイトに対する『安全管理措置』に対しても考えるべきでしょう。

皆さん、こんにちは。

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

昨年、このブログにおいてもいくつか記事を書かせていただきましたが、昨年のGoogleの発表から、Webサイトの暗号化に関する動きが加速しています。

※　Webサイトの暗号化＝http://www.example.com/ ⇒ https://www.example.com/

しかし、Webサイトを暗号化（HTTPS化）するとなると費用がかかること、直ぐにはすべてがそうなるわけではないと高を括っていることなど、未だ日本においては浸透度合いが薄い状態にあります。

HTTPS化に費用がかかる理由

Webサイトを暗号化（HTTPS化）することに費用がかかる理由として、2つの理由があります。

１．認証局が発行するSSL証明書の取得・設定に費用がかかる

２．HTTPS化に対応させるための改修に費用がかかる

これらは自社において完結できるのであれば抑えることはできますが、Webサイトの管理を外部委託されている場合においては相応の費用がかかります。

企業イメージを損なわないために

本来の理由は訪問者（閲覧者）であるユーザーを守ることが趣旨ですが、事業者として企業のイメージも重要です。

『あそこの会社はセキュリティに対する意識が低い！』などとマイナスのイメージをもてれることは先々のビジネスにおいても影響する可能性があります。

そして、まずは発想を変えてください。

ご自身がセキュリティ的に守られていないWebサイトに対して安心感がもてるかどうかです。

おそらく大半の方は『安心感がもてない』と回答するはずです。

となれば、訪問者（閲覧者）であるユーザーも同じ心理が働いているはずで、それに関連して、Webサイトが安全な状態に保たれていれば企業イメージもマイナスには作用しないことになります。

また、これらは中小・零細企業、小規模事業者も例外ではありません。

むしろ、中小・零細企業、小規模事業者の方がそれらに対する意識を高めていただく必要性が今はあります。