製品進化とマネジメント風景 第56話 ＷＥＢ通信の進化とセキュリティーマネジメント
第55話では、企業にとって情報セキュリティーの重要性が増していること、防御システムとして、伝統型の境界型の防御システム型だけでは限界が来ており、ゼロトラスト型が提案されるようになってきたことを述べました。
このゼロトラスト型防御システムの採用について一点だけ、この時点で指摘しておきたいことがあります。それは、ゼロトラスト型のサービスを提供する会社で目立つのは大手クラウドサービス会社だということです。手っ取り早くゼロトラスト化するために、全面的にクラウドサービスに移行し、会社の重要データも全てクラウドに置こうとするならば注意が必要です。
クラウドサービスでは、ユーザーは、データの入ったサーバを置く場所を指定できません。決めるのはクラウド会社です。データが日本国に置かれたサーバに保存されているならば問題ありません。しかし、LINEやZOOMで問題化したように、データが他国に設置されたサーバに保存されている場合が多々あります。大抵の国では、政府命令があれば、サーバに保存されたデータを当局に提供しなければなりません。国によっては恣意的に情報提供を求める場合もあり、データがどこの国に保存されるかが重要な問題となります。
ゼロトラスト型防御システムの長所、短所を適切に理解するためには、まず、従来型の境界型防御システムを理解しておくことが肝要です。また、ゼロトラスト型が主流になっても、境界型の重要機能は残ると考えられます。よって、前回に続き、今回も境界型防御システムに関する情報セキュリティーの要素を議論していきます。
今日のビジネス通信では、人と人、人と機械、機械と機械の3つのコミュニケーションパターンが存在します。前回は、最も基本的な電子メールのセキュリティーを議論しました。今回は、まず、人と機械あるいは機械と機械の間のコミュニケーションとして、最も多用されているWEB通信を扱います。WEB通信については、丁度、HTTP2からHTTP3にアップグレードされるタイミングでもあります。次に、このWEB通信を応用した音声通信であるIP電話と、コロナ禍で一躍スター的な存在となった感のあるオンライン会議通信について述べます。
WEB通信では通信プロトコルとしてはHTTPが使用されています。HTTPでは接続相手の情報や状態を保持しません。単純にリクエストとレスポンスという2つのやり取りを行うだけのプロトコルであり、相手先を認識している電子メールのプロトコル(SMTP, POP)とは異なります。そのため、本質的になりすましに弱いプロトコルと見なすことが出来ます。
この問題を解決するために導入されたのがCookieです。これはサーバが発行する一種の会員証であり、クライアントがこの会員証を添付して通信すると、サーバは相手を特定の誰であると認識します。このCookieにはクライアントの情報が書き込まれています。逆にいえば、このCookieを盗むと、サーバに簡単にアクセスできる場合が多いということです。新聞によれば、最近、このCookie情報が闇サイトで売り買いされているということでした。この危険性は以前から認識されていたので、クレジットカード情報などを扱うショッピングサイトでは多段階認証をして防いでいる場合が多いですね。
HTTPは1996年にバージョン1.0の使用が開始されました。バージョン1.0では、リクエスト／レスポンス毎にTCPコネクションを確立してデータをやり取りしていたため、通信負荷が上がり、WEBサイトの情報量が増えると処理が終了するなど不都合が起こりました。この欠点を改良するためにバージョン1.1が作られました。TCPコネクションを維持したまま、複数のリクエストとレスポンスを実行できるようになり、容量の大きなWEBサイトでも快適に見られるようになりました。
ここでTCPについて少し説明します。HTTPが進化し、後にTCPと性格を異にするUDPによる通信を使うようになるので、その違いを認識するための前提となるからです。TCPはTransport Control Protocolの略であり、自分自身の情報と相手先のＩＰアドレスだけから信頼性の高い通信を行うことを目的に作られたプロトコルです。データは通常、複数のパケットに分けて送信されますが、ＴＣＰでは回線速度に依らず、信頼性の高い通信を担保するため、念入りに相手の特定した上で、相手がパケットを受領したという信号を受け取るまで一定時間を空けて繰り返しパケットを送信し続けます。今日では、データ通信インフラの信頼性が向上したため、逆に通信負荷が高いプロトコルと見なされるようになってきました。
TCPを使ったHTTPの通信は、そのままでは盗聴が可能であるため、セキュリティーを維持するためのTLS (Transport Layer Security)が使用されています。HTTPのバージョン2では、TLSで暗号化された仮想的な通信路を構築し、複数のリクエスト／レスポンスを同時に通信できるようになりました。また、TLSによる暗号化方式も進化し、今日の標準はバージョン1.2ですが、近いうちにバージョン1.3にアップグレードされます。バージョンアップにより暗号が高度化され、解読が難しくなりました。TLS1.3についてはコラム55話に少し詳しく記載したので興味のある方は参照ください。
HTTPについては既にバージョン3が出始めました。まだ主流ではありませんが、いずれ全面的にこれに変わるのでしょう。バージョン2との違いは、通信量をさらに増やせることです。通信量を増やすために、通信プロトコルを信頼性の高いTCPからUDPに変更しました。UDPはUser Datagram Protocolの略です。UDPは、TCPとは異なり相手を特定するための念入りなハンドシェークプロセスを行いません。返答が無くてもデータを送りつける方式です。通信内容以外の余剰情報が少ないので通信量を半分くらいにすることが可能です。
HTTPバージョン3では、このUDPをQUICという新たな通信プロトコロルの下で動かします。一言で言えば、HPPT2をTLSのセキュリティーレベルを維持しつつ、UDP上に実装できるようにした、ということになるでしょう。これは、音声電話や動画、オンライン会議などのセキュリティー向上に繋がります。逆に言えば、現状の音声電話やオンライン会議のセキュリティーは、電子メールやWEB通信と比べるとセキュリティーレベルが一段落ちるということです。これについては後述します。
QUICは、ハンドシェークや一時鍵交換を行う部分においてTLS1.3を使います。しかし、パケットの暗号化はQUICが行います。とはいえ暗号化はTLS1.3を踏襲し、認証付き暗号のみを使用します。TCPと異なる大きな特徴は、メッセージだけでなく初期ベクトルⅣを含めてヘッダ－部分も暗号化されることです。これにより、初期ベクトルⅣに関連した脆弱性を低減できました。これまでUDP上でのデータ通信はセキュリティー面が脆弱といわれていましたが、QUICはこの問題を解決するソリューションとなるでしょう。
QUICの適用では、ChaCha20とPoly1305を組み合わせた認証付き暗号が主役の1人になると考えています。この暗号化スイートはTLS1.3でも公式に採用されました。ChaCha20はストリーム暗号の一種です。256ビットの鍵、96ビットのナンス（一度しか使用しない数）および32ビットのカウンタから構成される512ビットの鍵ストリームを20回かき混ぜ、メッセージの平文と組み合わせて暗号化します。ちなみにPoly1305は、2の135乗－5（2^135-5）の素数に基づいた一種のハッシュ関数です。
今日、コンピュータによる暗号解読能力が向上し、安心できる暗号化はブロック暗号のAESだけとなってしまいました。これは、もしAESが解読されたら安全なインターネット通信ができなくなってしまうということを意味しています。そこで、AESとは全くコンセプトが異なり、しかも、解読が同程度に難解な暗号化を必要と考える専門家が増え、その結果、ChaCha20が採用されたと言われています。今後、少しずつ、ChaCha20の暗号化に触れる機会が増えてくるだろうと思います。
さて、ここからＩＰ電話とオンライン会議におけるセキュリティーの話に入ります。IP電話はインターネットを使って電話を出来るようにした技術であり、電話料金を大幅に下げることを可能にしました。しかし、公衆回線上に音声情報を乗せるので、当然、盗聴されるリスクが高まります。ＩＰ電話が出たばかりの頃は、盗聴リスクが盛んに指摘されていました。その後に出てきたオンライン会議も同様であり、やはり盗聴リスクが話題となりました。
音声だけの通信も、映像と音声の同時通信も、通信方法は本質的に同じであり、しかもその基本は従来の電話の仕組みを踏襲しています。電話における交換機の代りを務めるのがSIPサーバです。SIPはSession Initiation Protocolの略です。通話をするには、まず、HTTPにより発信元と着信先のSIPサーバ同士を繋ぎます。そして回線が通じると、通話や動画を見て顔を見ながら話が出来るようになります。そこで用いられている通信プロトコルはRTP, UDPおよびRTCPの3つであり、これらを組み合わせてリアルタイム通信を実現しています。
RTPはReal-time Transport Protocolの略です。UDP (User Datagram Protocol)上でリアルタイムにデータを転送する機能を担います。UDPは、TCPの反対の性格を持つ通信プロトコルであり、通信の信頼性は落ちますが、通信負荷が低いので動画などの大量の情報通信に適しています。1対1の通信ではTCPとの差はそれ程ありませんが、1対多や多対多の通信になるとTCPに対して圧倒的に優位になります。UDPにおける通信の品質を上げるためにRTCP (Real-time Transport Control Protocol) がデータの制御を行います。
RTPは単にリアルタイムにデータを転送するだけなので、そのままではセキュアーな通信になりません。そこで、SRTP (Secure Real-time Transport Protocol)が作られました。何がセキュアーかと言えば、通信の暗号化を行います。当社が常用しているCisco Webexでは、暗号化は128ビット鍵長のAESを使用し、暗号利用モードとしてCTRを使った認証付き暗号です。電子メールの暗号化と比べると少し劣りますが、通信効率とセキュリティーとを両立させた結果だと認識しています。この暗号ならば、2030年頃までは安全性を確保できると考えられています。なお、録画されたファイルには現在の最高レベルの暗号化がされています。具体的には、第55話で述べましたが、マイクロソフトのoutlook.comで採用されているAES_256_GCMが採用されています。
オンライン会議といえばこの2年くらいはZOOMの勢いがすさまじいですが、一時セキュリティー等でいくつか問題を起こしました。例えば、ZOOMは、「256ビットAESの暗号化とCBCモードを組み合わせ、End-to-endで暗号化されていて極めて安全」とかつてHP上で説明していました。しかし、実は、128ビットAESであり、しかも、暗号利用モードには解読されやすいEBCモードを使用しており、誇大宣伝だったことが暴露されました。EBCモードは今日では殆ど役に立ちません。画像に適用した場合には、輪郭が残ってしまうので何の画像を送ったかが分かってしまいます。
加えて、利用者が急増したことによりデータサーバを中国に設置したことが判明しました。ご存じのように各国政府は自国に設置されたサーバの情報を法的根拠に基づいて提供させる権限を持っています。中には恣意的に提供させる国もあります。この情報を受け、2020年4月には米国政府は政府関係機関にZOOMの使用禁止を通知しました。ZOOM社は誤りを認めて真摯に改善努力をしてきたので、2021年現在ではおそらく問題は解消していることでしょう。当社は、通信暗号規格が更新されるとすぐに対応し、しかも誇大な宣伝をしないCisco社の方に信用を置いています。
以上、WEB通信のセキュリティーについて概観してきました。一見難しく見えるかもしれませんが、枝葉末節を除いて幹を整理すると全体像が見えてきます。専門家でなくても8割方は理解できます。残りの2割は難解なので専門家の領域です。ただ、専門家も細分化が進んでタコツボ化している場合があります。今後起こりうるリスクを察知するには、タコツボ化した専門人材よりも広く全体像を把握するシステム思考型マネジャの方が正しい判断が下せる場合が多くあります。これは情報セキュリティーに限った話でなく、どの技術分野にも当てはまる話です。これからの時代は、多様な専門技術とシステム思考型マネジメントの共創が顧客価値を生み出す時代だと私は考えています。