前回は、ビデオ会議のセキュリティに関して IP アドレス発着信の観点でコメントをさせていただきました。今回は、ビデオ会議で使われるプロトコル H.323 をセキュリティを切り口に取り上げます。結論を申し上げますと、インターネット上で使うのであれば、SIP – TLS（（Session Initiation Protocol – Transport Layer Security） または Cisco Spark などのHTTPS(Hypertext Transfer Protocol Secure) を利用したクラウド登録などを優先して検討すべきです。
まず、質問です。
ビデオ会議の通信 は暗号化されるから安全
こういった言葉を聞いたことがないでしょうか? Web や無線、 VPN などのコンテキストのなかで暗号化が出てくると、続いて「方式は？」「暗号化レベルは？」といった質問が出てきます。 ところが、「ビデオ会議は暗号化機能がある」というと、「じゃ、安心だね」で終わってしまいがちです。
残念ながら、H.323 は SIP と比較して、重要な情報が「相互接続性を維持したまま」暗号化することができません。ビデオ会議には「呼制御」と「メディア」の2つのプロコトルがあります。テレビで言いますと、チャンネルを選ぶ操作が「呼制御」で、実際に流れる番組が「メディア」になります。テレビの場合、チャンネル操作は手元のリモコンで実施しますが、ビデオ会議の場合はそれをネットワークを介して相手に伝える必要があります。
この操作、つまり呼制御が “H.323” の一般的な実装では暗号化できません。 メディアは暗号化可能なので、一般的に暗号化可能はこちらを指しています。
「チャンネル操作」が暗号化されていないとどのようなことが起きるのでしょうか。まず、誰と誰が通話をしているかがネットワーク上で一目瞭然になってしまいます（SIP TLS であれば暗号化されているため、そういった情報を見ることはできません）。さらに暗号化する仕組みがないということは、通話相手が正しい相手かどうかわからないという弱点もあります。 Web サイトを閲覧中、あるいは迷惑メールから偽物のサイトに誘導されそうになったことはないでしょうか？ H.323 はこの誘導から守るすべがないです。また、通話中の番号入力（DTMF）も同様です。H.323 ビデオ会議端末から会議装置に入力した パスワードは残念ながら暗号化されていません。もしその番号を誰かが盗んで使い始めたらと考えるとぞっとします。
セキュリティの観点だけではなく、SIP と違い、 H.323 ではパケットロスや遅延に強い最新の音声コーデック OPUS や、帯域圧縮に優れている H.265 が「実装の観点」で 動作しません。そして、 UTF-8 に対応していないため、相互接続性を維持したまま日本語を扱えないという困った問題もあります。
こういった弱点があるにもかかわらず H.323 が使い続けられているのには、過去の資産との相互接続性の問題があります。シスコからは Cisco Expressway が、古い H.323 と新規に導入する SIP との接続性の問題を解決し、段階的な移行をサポートします。インフラが入れられない場合には、 Cisco Spark にクラウドで登録したビデオ会議端末と、H.323 にも対応する Cisco WebEx で接続する手段もあります。
ビデオ会議端末が、東京と大阪の会議室だけをつなぐだけであれば固定 IP アドレスを使い、インフラで徹底的に守ればセキュアな環境は作れます。しかしながら、その展開は働き方改革で言われているような「だれでも、どこからでも参加できる会議」にはなりません。ビデオ会議を検討されているお客様だけではなく、お客様に提案する側も、「拠点の会議室をつなげて出張費を削減する」という考えから脱却する必要があります。そして理想の環境を実現するために前回、今回話した「セキュリティ」の考慮事項は重要な懸念点です。過去の資産を優先するのではなく、未来の働き方に向けてビデオ会議が何ができるか考えてみませんか？
なお、相互接続性の観点から、シスコでは CE Software と呼ばれるソフトウェアを搭載した新製品を含むビデオ会議端末製品に H.323 の実装を残し続けます。この点は誤解なきよう書き加えておきます。
Authors
