現在、Google ChromeをはじめとしたWebブラウザーで、WebサイトのHTTPS化を推奨する動きが強まっています。
2018年7月にリリースされたGoogle Chrome68では、HTTPS化されていないWebページのアドレスバーに「保護されていない通信」という警告が表示されるようになりました。
さらにその後のバージョンアップでもHTTPのWebページに対する警告表示は徐々に強まっており、Webサイト全体をHTTPS化する「常時SSL化(常時HTTPS化)」はWebサイト運営者にとっていち早く取り組むべき課題となっています。
このページでは、JPRSがどのように自社サイトの常時SSL化を進めたのか、実際の体験をもとにお伝え出来ればと思います。
(1)はじまり
現代では、多くの企業が自社のWebサイトを所有し運営しています。中にはコーポレートサイト以外にもリクルートサイトや商品別のサイトなど、沢山のWebサイトを持っている企業も珍しくありません。そしてそうしたWebサイトの中には、サーバー証明書が設定されておらず常時SSL化がなされていないものも沢山あるかと思います。このようなサイトは、Google Chrome68による警告表示実施後は視覚的に「危険なサイト」として印象づけられてしまうことになります。
JPRSではそうした業界的な動きにあわせ、自社サイトの常時SSL化への取り組みを開始しました。
(2)対策チームの結成と対応検討
プロジェクトを任された若手社員の悩み
さて、自社サイトを常時SSL化させようと意気込んだはいいもののはじめはわからないことだらけでした。
- 常時SSL化の方法は?
- そもそもどんなサイトが何件くらいあるの?
- サイトを管理してるのは誰?
こうした問題を1から解決するのはとても困難だったため、各部室から関係者を集めて対策チームを結成することにしました。チームには自社サイトの多くを管理している部室や、サーバーへの設定作業に関わるシステム系の部室など、社内の関係者が参加。そしてチームでの話し合いや情報共有の結果、自社サイトの管理状況が段々と明らかになってきました。
- 常時SSL化されていない自社サイトは約50件
- 自社サイトはそれぞれ、どこかの部室によって管理されている
- Webサイトの管理部室とは別に、そのサイトのコンテンツ編集権限を持った部室が定められている
常時SSL化の対象となるWebサイトの洗い出し
さて、自社サイトの管理に関する大まかな状況を把握し各サイトの管理部室を整理したところで、自社サイトの常時SSL化に関する対応検討が始まりました。
○検討その1:どのWebサイトを常時SSL化する?
50サイトの中にはコンテンツが更新されていない古いサイトなどもありました。そうしたサイトを存続させるかどうかという点も含め、常時SSL化の対象とするべきWebサイトを改めて検討しました。
○検討その2:サーバー証明書の種別や有効期間は?
サーバー証明書にはDV、OV、EVといった種別があり、有効期間は最大2年まで選択できます。
これらはサーバー証明書発行の際に必要な情報となりますので、基本となる判断基準を定め、今後発生するケースにも可能な限り適用できることを目指しました。
○検討その3:どんな手順で進める?
ひとくちに常時SSL化といっても、Webサイトにサーバー証明書を設定するには証明書の発行やサーバーの設定、コンテンツ自体の編集など様々なフローが必要になります。
対策チームでは、今後も全社的に利用できるような常時SSL化手順の作成を目指しました。その他様々な検討を経て、以下の方針で対応を進めていくことが決まりました。
プロジェクト方針
- 閉鎖するサイトは対応不要とし、外部への影響が少ないサイトについては後回しにする
- 優先度の高いサイトから何回かに分けてまとめて常時SSL化を実施する
- 基本的にはDV証明書(必要と判断した場合はOV証明書)を2年もので発行する
[2020年8月21日追記:2020年8月20日をもって、有効期間が2年の証明書の発行は終了しました。1年の証明書を発行ください。] - 常時SSL化に必要な社内手続きは各サイトの管理部室、サーバー証明書の発行は業務部門、サーバー証明書の設定はシステム部門が担当する
- 常時SSL化に伴うWebコンテンツの編集は、コンテンツ編集権限を持った部室によって行う
- 利用者への影響が大きい場合(※)を除き、常時SSL化前のURI(HTTP)から常時SSL化後のURI(HTTPS)へのリダイレクト設定を行う
※常時SSL化前のURIをプログラムに組み込んで利用している利用者がいる場合など
(3)常時SSL化の実行
対応手順
チーム内での検討のもと対応手順を決定し、いよいよ実際に常時SSL化を実施する段階まで辿り着きました。あとは各部で手順に従い、スケジュール通りに準備を進めていきます。
○自社サイト常時SSL化に関する手順
- 対象サイトの各管理部室にて、サーバー証明書発行に関する承認を得る
- サーバー証明書の発行を行う(業務部門がJPRSサーバー証明書を自社発行)
- 発行されたサーバー証明書をシステム部門に引き渡し、設定を依頼する
- サーバー証明書が設定されたら管理部室にてWebサイトの動作確認(警告が出ていないか、鍵マークは表示されているか、ページがちゃんと遷移するか等)を行う
- サーバー証明書が設定されたら管理部室にてWebサイトの動作確認
また、証明書の発行〜設定と並行してWebコンテンツの編集も行いました。コンテンツ編集が不十分だと、せっかく常時SSL化をしても鍵マークが表示されないなど、様々な問題が発生してしまう可能性があります。(参考:httpsで鍵マークが表示されない!?ブラウザーで原因箇所を見つける方法)
上記の手順を優先順位が高いものから順に行っていき、数カ月をかけて対象サイト全件の常時SSL化が完了しました。
(4)サーバー証明書の「更新」手順制定
更新管理が大事
自社サイトの常時SSL化はひとまず完了しましたが、まだまだ運用体制は不十分です。次なる課題として、対策チームではサーバー証明書「更新」の手順制定に取り組みました。サーバー証明書は一度発行したらずっと使えるというものではなく、決められたタイミングまでに更新しないと有効期限を迎え、使えなくなってしまいます。
つまり、Webサイトにサーバー証明書を設定した後は、有効期限が切れるまでに忘れず更新を繰り返す必要があるということになります。サーバー証明書の更新は、手順自体は基本的には新規発行と同じです。しかし新規発行の際とは違い、各管理部室がサーバー証明書の更新タイミングを漏れなく察知するための管理体制が必要になります。
そこで私たちは、JPRSサーバー証明書の自社発行を行っている業務部門と連携し、更新状況を一元管理することで、各管理部室に対し適切に有効期限のリマインドを行える体制を構築しました。
(5)最後に
Google Chromeによる警告表示の実施をはじめ、政府機関の全Webサイトの常時SSL化が義務化されるなど、Webサイトの常時SSL化は業界的にも当たり前になってきました。
今後HTTPサイトへの制限がさらに厳しくなっていく可能性も考慮すると、冒頭にも記載の通り、常時SSL化はWebサイトを運営する上で必要不可欠なものになってくるのではないでしょうか。
運営サイトの常時SSL化がお済でない方にとって、本コンテンツが少しでも参考になれますと幸いです。
本ページで使用している専門用語の解説
SSL(Secure Socket Layer)
通信データを暗号化し、盗聴や盗み見されないようにする技術です。パスワードの送受信をするようなページでは必須とされます。HTTPS通信は、SSLの後継バージョンであるTLS(Transport Layer Security)の技術を用いておりますが、一般的に広く知られているSSLと表記しています。
HSTS(HTTP Strict Transport Security)
HSTSは、利用者が常時SSL化されたWebサイトにHTTPでアクセスしてしまうことを、できるだけ減らすための仕組みです。
JPRSサーバー証明書について
「.jp」の登録管理を行うJPRS(株式会社日本レジストリサービス) が提供するSSL/TLSサーバー証明書です。
「.jp」は150万件以上の登録実績があり、JPRSは設立以来15年以上、JPDNSを無事故・無停止で運用しています。安心と信頼の品質をSSL/TLSサーバー証明書でも実現します。