製品進化とマネジメント風景第96話常時TLS化と新しい基準によるセキュリティマネジメント

2023.09.17 コラム

日本で常時SSL化と言われ始めたのは、記憶が正しければ2015年頃だったと思います。そのように言われ始めたものの、多くの人は「公開された情報を暗号通信にする意味はないではないか」と考え、多くの企業が対処せずに放置しました。

おそらく、そのような企業は、SSL化が単なる暗号化でなく、インターネット上で認証された存在になるということの意味を理解できていなかったのでしょう。なぜなら、常時SSL化するということは、少なくともそのドメインについて、認証局に申請してインターネット上の登記が行われたことを意味するからです。

リアルな世界では登記という仕組みが適切に機能しており、誰もがその必要性、重要性を理解していました。しかし、インターネットのような仮想空間上での登記 という概念は、何か実体を伴わないものだとして重視されなかったのでしょう。

しかし、次第にホームページを入口とした情報のやり取りが増えて一般化しました。常時SSL化していないサイトとの交信は外から丸見えなので、そのサイトは、アクセスしている人のプライバシーを侵害していると言える状況になってしまいました。

とは言え、丸見えだということはある種のツールを使って監視しないと気付きません。おそらく自分達が悪いことをしているという実感がなかったのでしょう。この常時SSL化はゆっくりとしか進みませんでした。

このような状況を憂慮したGoogleは、2018年にChromeブラウザの設定を変え、SSL化されていないサイトは「安全ではない」とあえて表示するようにしました。「安全でない」と言われると「さすがに拙い」と考えたのでしょう。これを機会として、常時SSL化をする企業が増えました。

それでも2023年5月時点での調査結果では、日本の上場企業のホームページで常時SSL化をしているのは約9割に留まるという結果が公表されました。つまり、上場企業の１割が未対応ということです。非上場企業を含めれば、その比率はもっと高くなるだろうと推測できます。

おそらく、未だに「ホームページで情報をやり取りしなければいいんだ。やり取りは電子メールか電話を使えばいいんだ」とでも思っている人が多かったのでしょう。しかし、実は、常時SSL化されたブラウザのやり取りは、電子メールよりもずっとセキュリティが高いのです。

電子メールについても、MS365同士あるいはGmail同士という形でのウェブメールでやり取りをしていれば常時SSL化が効くので安全です。しかし、独自のメールサーバを経由して伝達される電子メールは、その経路上のメールサーバの１つでもSSL化していないものがあると、そこで盗み見みができてしまします。当然、悪意のある者たちはそこを狙って情報収集を行うことになります。

2022年時点にGoogleが調査した結果では、SSL化されていないメールサーバが約10%の比率でありました。これは北米を中心としたグローバルな数字です。別途、日本のある会社が行った調査では、2021年の調査結果ではありますが、日本企業の約25%でメールのSSL化が未対応だったと報告しています。

4本に1本のメールが盗み見できるというのは恐ろしい話ですね。当社のような小企業は信用が第１ですので、常時SSL化されたウェブ通信が可能なMS365に基盤を変えました。これにより、同じMS365を採用している会社との間ではウェブ通信はもちろん、電子メールについても常時SSL化が保たれるようになりました。

一方、自社で独自メールサーバを持つ企業との間のやり取りについては、経路上に脆弱なメールサーバがある可能性は残ります。この問題に対処するため、s/mineも用意していましたが、s/mineは相手もそれを用意していないと暗号化がされないため、不完全な方法です。

今ではメールよりも、同じ会社が運営するオンライン会議やオンラインチャットを使う方がずっとセキュリティが高いと言えます。もちろん、Webブラウザを最新バージョンにしていることが必要条件となりますが。

さて、ここからは、「常時SSL化」という言葉の大元であるSSLやTLSについて、その歴史を少し振り返ります。

まず、常時SSL化という言葉になったSSLですが、これはネットスケープ社が開発したものです。SSL1は仕様段階で脆弱性が見つかったため、実装は1995年のSSL2からです。しかし、これも１年も経過せずして脆弱性が見つかり、1996年からはSSL3となりました。

このSSLはネットスケープ社の自社規格であり、他社がこれをそのまま業界標準にすることを拒みました。その結果、中身は大差ないのですが、名称は変わってTLS1.0として業界標準となりました。よって、本来は常時TLS化というべきですが、いまだにSSLという言葉が残っているのです。ある種の慣性の法則なのでしょう。

さて、業界標準となったTLSは2006年にTLS1.1、2008年にTLS1.2、2018年にTLS1.3のバージョンアップがされました。このようにバージョンが出てくるのは、１つは暗号を破るための攻撃が高度化されたためですが、もう１つは暗号を解読するためのCPU性能が向上したためです。

以下、脆弱性が明らかとなった事例を紹介します。まず、2002年に暗号利用モードであるCBCの脆弱性が見つかりました。手間は掛かるのですが、数を打てばバイト単位で復号できることが判明したのです。それが2013年のLucky Thirteen攻撃、さらには2014年のPoodle攻撃として現実化しました。

この脆弱性は局所的なものではなく仕様に基づく話でした。ウェブ通信を開始する時には、双方で使用する暗号通信方法（暗号スイート）の相談をしますが、Poodle攻撃では、常に最も不安全な暗号通信方法を指定するというダウングレード攻撃を出来ることが判明し、2014年から2015年にかけてSSL2,SSL3は運用中止となりました。

TLS1.0以降は、前述のダウングレード攻撃はできなくなりましたが、CBCは使いつづけられたのでBeast攻撃は有効でした。この攻撃の原理は、暗号化通信の中で実行されるJavaScriptを利用して、暗号化通信の内容を観察し、暗号化鍵を推測していくというものです。TLS1.1では上記のBeast攻撃への対応策が加わりました。

TLS1.1までの対応は、とにかく常時SSL化の適用率を上げることを重視していたため、弱い暗号スイートの使用を許していました。実は、現在の主流であるTLS1.2もそれは同じです。ただし、TLS1.2では、「次のバージョンアップ（TLS1.3)では、本当に強い暗号スイートしか許さないぞ」というニュアンスを醸し出しています。

TLS1.0と1.1については、Amazon Web Services, Google Cloud Platform, MS365などのクラウドサービスのAPIでは使用を禁止しています。APIを使うのは事業者が多いので、事業では使うなというメッセージです。個人が接続するだけであれば、まだ、しばらくはTLS1.1で接続できるようです。

サーベイした限りですが、現在はまだ多くの上場企業がTLS1.2を使用しています。

では、TLS1.2からTLS1.3にアップグレードすると何が良くなるのでしょうか？大きく２つの違いがあります。1つは、TLS1.3を標準モードで使用すればTLS1.2よりも明らかに安全性が高いことです。これは大抵の方は予想していたと思います。詳しい理由は後述します。

もう１つですが、TLS1.3ではリスクを許容するならば、以前にアクセスしたサイトに再度アクセスするときは、相手の正当性を確認せずに接続するのです。これは俗にO-RTTと呼ばれています。両者の違いは次のように考えると分かりやすいでしょう。

標準モードは厳重な無人自動ドアのイメージです。例えば、証明書カードを提示しないと入れません。融通が利かないので、証明書を忘れたら決して入ることが出来ません。これに対して、0-RTTは守衛さんがいるゲートのようなものです。仮に証明書カードを忘れても、顔パスで入れるイメージです。後者だと、守衛さんが何かに気を取られていると、忍び込むことが可能ですよね。

0-RTTにもメリットはありますが、これを使うとTLS1.3にした意味がなくなってしまいます。従って、多くのサイトは使用を許可していません。さて、前述したTLS1.3がTLS1.2に対して安全性が高い理由ですが、それは、TLS1.3は『前方秘匿性』と『認証付き暗号利用モード』を必須事項として課しているからです。この言葉に見慣れない人もいるでしょうから説明を加えます。

『前方秘匿性』というのは、仮にTLSによる暗号通信を確立した後に使用する秘密鍵を交換する際に、仮にその鍵が盗まれたとしても、過去に暗号化したデータは解読されないことを保証した方法です。従来は、鍵交換をしたら同じ鍵を使い続けていたので、一度これが流出してしまうと、過去に遡ってやり取りがすべて漏洩してしまうのです。かなり危ないと思いませんか？

『認証付き暗号利用モード』は、相手に文字情報を送付する時にそれらを暗号文にするだけでなく、認証タグも生成して一緒に送付します。受け取った相手は、前述の鍵交換で入手した秘密鍵で復号しますが、暗号文が改ざんされていると、認証タグに相当するアウトプットがオリジナルの認証タグと異なるので、改ざんされたことを検知し、復号は失敗します。相当厳重です。

他方、認証付きでない暗号利用モードでは、秘密鍵を入手しさえすればメッセージを改ざんできますし、受領した方は改ざんされたことに気付けません。気付けないというのは危ないと思いませんか？

TLS1.3では、上記の２つを必ず課すことにより、野獣がうようよしているインターネット空間でも、高い安全性を保ちながら秘密情報のやり取りが可能になります。お分かりいただけたでしょうか。

前述したように、多くの企業がTLS1.2を使っていますが、当社はセキュリティを重視しているので既にTLS1.3に変更しました。これはホームページを検証してもらえば分かることです。

情報セキュリティの基礎ともいうべき常時TLS化の話をしてきましたが、これは本当に基礎的な事項です。視野を少し広げると、今、世界における情報セキュリティの基準が変わりつつあることに気付くでしょう。

従来、情報セキュリティ規格の標準といえばISO/IEC 27001でした。この標準に則って外部の審査を受けていたと思います。しかし、サイバー攻撃側が進化してきたため、それでは不足気味となり、NIST SP800-171を採用する企業が出始めているのです。では、この２つの規格は何が違うのでしょうか？

２つのセキュリティ規格の違いを簡潔に説明すると以下となります。従来のISO/IEC 27001は、サイバー攻撃の5つの段階のうち、リスクの「特定」と「防御」をカバーしています。しかし、高度化した攻撃に対しては完全に防ぎきれなくなってきました。そこで、NIST SP800-171では、上記2項目に「検知」、「対応」、「復旧」の3項目も加えたのです。

この規格を採用するのは防衛関連企業と思われるかもしれませんが、すでに防衛と無関係の企業も取り入れ始めています。例えば、多くの企業が使っているMS365ですが、このシステムはNIST SP800-171に対応しています。

実際に管理者としてMS365に触れた方は分かると思いますが、前述した「検知」、「対応」、「復旧」の仕組みを備えています。当社は小企業ですが、セイフティとセキュリティを重視しており、そのため、情報システム基盤を他のシステムからMS365に移行しました。

サイバーセキュリティ対策は、企業の規模を問わず、事業の大前提になりました。専門家だけでなく、一般の社員も一定のそのリテラシーが必要な時代に入りつつあると感じます。貴社社員のサイバーセキュリティ・リテラシーは上がっていますか？