Vonage Video API を使用するアプリのセキュリティ対策

アプリのセキュリティを維持するためのベストプラクティスに従ってください。

Vonageは、ウェブサイト、アプリ、またはサービスにリアルタイム通信機能を統合しようとするあらゆる企業にとって、セキュリティが不可欠な要素であることを認識しています。OpenTokプラットフォームは、信頼性が高く安全なプラットフォームであり、貴社、業界、あるいは顧客のセキュリティ要件を満たすApplicationsを構築することができます。

このページには以下のセクションがあります：

セキュリティFAQ
セキュリティのベストプラクティス

セキュリティFAQ

WebRTC上のOpenTokセッションでは、音声およびビデオのトラフィックは暗号化されていますか？

はい、使用するエンドポイント（Webまたはモバイル）や選択するセッション設定（P2Pまたはマルチパーティ）にかかわらず、すべてのメディアトラフィックは暗号化されます。つまり、公開されている公共のホットスポットでOpenTokソリューションを利用する場合でも、安全に利用できます。

また、ウェブアプリでは、公開はHTTPSページでのみサポートされています。

独自のソリューションに基づいているのか？

いいえ、セキュリティに関しては、独自仕様のソリューションには賛同していません。OpenTokは、実績のある標準規格に完全に基づいており、業界の専門家によって開発され、長年にわたり商用製品で採用されてきました。WebRTC OpenTokのセキュリティを支える中核となるプロトコルは、メディアトラフィックの暗号化に用いられるSRTPと、鍵ネゴシエーションに用いられるDTLS-SRTPであり、これらはIETFによって定義されています。

使用されている暗号化アルゴリズムと鍵の強度は？

OpenTokのWebRTC対応エンドポイントは、音声および映像の暗号化に128ビット鍵のAES暗号を使用し、データの完全性VerifyにはHMAC-SHA1を使用しています。

AES-256 暗号化は、対応しているクライアント上でアドオン機能.

暗号化に使われている鍵は？

エンドポイントはセッション開始時にランダムなキーを生成し、さらに安全性を高めるために会話中に定期的に変更する。

ユーザーとの対話は必要ですか？

いや、すべてはユーザーとのインタラクションなしに、フードの下で起こっている。

OpenTok ベースの Applications に変更を加える必要はありますか？

いいえ、OpenTok APIに変更はありません。OpenTok APIでは、こうした低レベルの詳細は開発者に公開されていません。

それは、ビデオ会議の帯域幅や画質に影響を与えますか？

確かに影響はありますが、ごくわずかです。各オーディオおよびビデオパケットの長さが8バイト増加しますが、これはOpenTokセッションの一般的なビットレートの1%未満です。遅延に関しては、SRTP暗号化フレームワークはリアルタイムアプリケーション向けに特別に設計されているため、その影響はまったく気にならない程度です。

CPUやバッテリーの消費に影響はありますか？

しかし、オーディオとビデオのエンコードとデコードのコストは、暗号化と復号化のコストよりもかなり高い。

セキュリティのベストプラクティス

OpenTokプラットフォームを初めてご利用になる方でも、長年の経験をお持ちの方でも、OpenTokを使用した開発において、安全なApplicationsを構築するために活用できる、役立つベストプラクティスを以下にご紹介します。

HTTPS URLを使用してコンテンツを配信する

Webアプリでは、動画の公開はHTTPSページでのみサポートされています。

個人情報

APIキーとシークレットをプライベートかつ安全に保つ

API キーとシークレットは、セッションへのアクセスを許可するトークンの作成、アーカイブメタデータの取得、アーカイブストレージ資格情報の変更、およびアカウントのその他の管理操作に使用されます。

認証情報の漏洩を避けるため、APIの秘密は常に秘密にしておくべきである。いくつかの重要な対策があります：

決してAPIシークレットを公開ソースコードリポジトリに保存しないでください。
クライアント側のライブラリやコンパイル済みのモバイルSDKにも、決してAPIシークレットを保存しないでください。
OpenTokサーバーへのREST呼び出しには、HTTPS URLのみを使用してください。

通話ごとに一意のセッションIDを生成し、参加者ごとにトークンを生成する。

呼を開始するには、セッションIDを生成する必要がある。参加者を参加させるトークンは、セッションIDに固有である。トークンには有効期限がありますが、通話時間よりも長い場合があります。したがって、同じセッションIDを使用して連続したミーティングを開催した場合、以前のユーザーは新しいミーティングに接続できる可能性があります。

これを避けるためだ：

新しい会議ごとに一意のセッションIDを生成する
その会議の参加者ごとに一意のトークンを生成する。

以下のバージョンの OpenTok サーバー SDK では、セキュリティ強化のため、SHA-256 で署名されたトークンが生成されることにご注意ください：

OpenTok Node SDK v2.20.0 以降
OpenTok Java SDK v4.15.0 以降
OpenTok Ruby SDK v4.11.0 以降
OpenTok PHP SDK v4.15.0 以降
OpenTok Python SDK v3.10.0 以降
OpenTok .NET SDK v3.15.2 以降

参照本題セッションの作成方法について。参照本題トークンの生成方法について

トークンを生成するサーバーが認証されたエンドポイントの背後にあることを確認する。

トークンを生成するサーバーは、認証済みエンドポイントの背後に配置することが重要です。なぜなら、そのサーバーにアクセスできる者であれば誰でも新しいトークンを生成できてしまい、アプリを悪用して利用回数を水増しする可能性があるからです。

トークンデータやパブリッシャーの「name」フィールドには、個人情報を使用しないでください。

トークン・データこれは、Server SDK における接続を記述するメタデータを含む文字列であり、パブリッシャー名は Client SDK でパブリッシャーを作成する際に設定されます。これらのフィールドは、セッション内の他の参加者に公開される可能性があり、また、Inspector Tool や Vonage の内部ログを通じて読み取られる可能性もあります。

つまり、暗号化されていない機密情報や個人情報をこれらのフィールドに使用してはならないということです。

ストリームにユーザーIDを関連付ける必要がある場合は、Video APIフィールドに個人データを埋め込むのではなく、アプリケーションレベルの識別子（ユーザーIDなど）を使用し、独自のアプリケーション内で解決する。

中継モードとルーティング・モード

エンド・ツー・エンドのメディア暗号化

ルーティングセッション中、メディアストリームはOpenTok Platformのクラウドサーバー内では一時的に復号化され、その後、インターネットを経由して加入クライアントに送信される前に直ちに再暗号化されます。ただし、エンドツーエンドの暗号化機能を使用します。この復号化は、グループ・セッションの管理、インテリジェントな品質管理、メディア復号化を必要とする機能（アーカイブ、ライブ・ストリーミング放送、エクスペリエンス・コンポーザー、オーディオ・コネクター、SIP相互接続（使用されている場合）など）に必要です。ルーティングされたセッションを使用することで、メディアストリームが暗号化されずにオープンインターネット上に送信されることはありません。

を使うことができる。エンドツーエンドの暗号化 OpenTok Media Router がルーティングされたセッション内のメディアにアクセスできないようにするためです。エンドツーエンド暗号化を使用する場合、メディアのデコードを必要とする機能（アーカイブなど）はサポートされません。

また、すべてのメディアをエンドツーエンドで暗号化する必要があるアプリケーションでは、中継セッションを使用することもできます。メディアのデコードを必要とする機能（アーカイブなど）が使用できなくなり、低帯域幅/高パケットロスのネットワークやグループでのパフォーマンスがうまく管理できなくなることに注意してください。

アラートとコントロール

セッションの最大ユーザー数を制限する

セッションに参加する人数をより細かく管理するために、アプリケーションではセッションあたりの最大ユーザー数を制限する必要があります。これは、利用を制限したい場合に役立ちます。

加入者数の表示

また、アプリケーションに表示する購読者数を設定することもできます。これは、接続がサブスクライブしているにもかかわらず、パブリッシュしていないことを知るための便利な方法です。

強制的に切断するためにモデレーターの権限を設定する

OpenTokプラットフォームでは、セッションからユーザーを排除する機能を提供しています。たとえば、利用規約に違反した場合などには、セッションのモデレーターが、強制切断または強制非公開機能を使用して、違反した参加者をセッションから排除できるようになります。詳細については、以下を参照してください。本題をご覧ください。

公開する必要のない購読者のみにパーミッションを割り当てる

用途によっては、セッション内で投稿できる人数を制限したい場合もあるでしょう。これは、すべての参加者に投稿権限を付与しないようにすることで、簡単に実現できます。

参照本題適切な役割を持つトークンを生成するため。

地域サーバーへのトラフィックを制限する

を使用することができます。地域メディアゾーン機能は、すべてのメディアストリームを指定された地域内のメディアサーバーにルーティングする。

メディアトラフィックの制限に加えて EUプロキシを制限する機能です。 ノンメディア トラフィックはEU内のサーバーを使用する。

セキュリティ＆トランスポート層

TLS暗号化

Vonage Video APIは、すべてのAPI通信でTLS 1.3とTLS 1.2をサポートするようになり、ビデオセッションのセキュリティとパフォーマンスが強化されました。このアップデートにより、最新の暗号化標準との互換性が保証され、転送中のデータが保護されます。

主なメリット

セキュリティの強化： TLS 1.3による暗号アルゴリズムの強化と前方秘匿性の向上
より良いパフォーマンス： 合理化されたハンドシェイク・プロセスによる接続待ち時間の短縮
自動交渉： クライアントは自動的にサポートされている最も高いTLSバージョンを使用します。

すべてのAPIエンドポイント接続は、デフォルトでTLSで保護されています。最新のSDKとHTTPクライアントは、自動的にサポートされている最も高いTLSバージョン（TLS 1.3または1.2）を優先するので、コードを変更する必要はありません。ただし、最新のセキュリティとパフォーマンスの向上の恩恵を受けるには、常に最新のSDKリリースを使用することをお勧めします。