Voice Gateway の保護

IBM® Voice Gateway を保護して、サービス妨害攻撃など、脆弱性への暴露を低減できます。 Voice Gateway をパブリック・クラウドにデプロイすると、SIP 電話を使用して誰もがそれにアクセスできるようになるため、セキュリティーを構成することが特に重要になります。

フォワード・プロキシー・サーバーを介した接続

セキュリティーを強化するため、ユーザーの組織は、HTTP 要求がフォワード・プロキシー・サーバーを通過する必要がある環境に Voice Gateway をデプロイできます。 この環境では、プロキシー・サーバー経由で Watson™ サービスに接続するよう Voice Gateway を構成する必要があります。

制限事項: HTTPS プロトコルは、Media Relay コンテナーでのみサポートされます。 SIP Orchestrator コンテナーでは、プロキシー・サーバーへの HTTP 接続のみを指定できます。

SIP Orchestrator および Media Relay の構成ファイルで、以下の例に示すように、フォワード・プロキシー・サーバーの詳細を指定します。

# Proxy configuration
- PROXY_TYPE=http #Can be omitted because it's the default
- PROXY_HOST=app.proxy.com
- PROXY_PORT=8080

# Basic authentication credentials
- PROXY_USERNAME=johndoe
- PROXY_PASSWORD=password1
表 1. プロキシー・サーバーを構成するための環境変数
環境変数 デフォルト値 説明
PROXY_TYPE http プロキシー接続で使用するプロトコルを定義します (http または https のいずれか)。 Media Relay でのみサポートされます。
PROXY_HOST なし フォワード・プロキシー・サーバーのホスト。
PROXY_PORT なし フォワード・プロキシー・サーバーのポート。
PROXY_USERNAME なし プロキシー認証のユーザー名。
PROXY_PASSWORD なし プロキシー認証のパスワード。

バージョン 1.0.0.1a 以降でプロキシーを構成すると、プロキシーは、Watson の Speech to Text サービスおよび Text to Speech サービスには有効になりますが、API で定義した保留音 (MOH) URL またはワンタイム音声 URL には有効になりません。 これらの各項目のプロキシーは、以下の環境変数の設定で有効または無効にすることができます。

表 2. プロキシーを有効にするための環境変数
環境変数 デフォルト値 説明
WATSON_STT_ENABLE_PROXY true Watson Speech to Text サービスへの接続が、構成済みのプロキシーを通じてルーティングされるかどうかを示します。 バージョン 1.0.0.1a 以降。
WATSON_TTS_ENABLE_PROXY true Watson Text to Speech サービスへの接続が、構成済みのプロキシーを通じてルーティングされるかどうかを示します。 バージョン 1.0.0.1a 以降。
MUSIC_ON_HOLD_ENABLE_PROXY false 保留音 URL またはワンタイム音声 URL への接続が、構成済みのプロキシーを通じてルーティングされることを示します。 バージョン 1.0.0.1a 以降。

SSL および TLS 暗号化の構成

デフォルトでは、Watson サービスへの接続は、接続が直接であるか、フォワード・プロキシー・サーバーを介している場合、TLS 暗号化を使用して保護されるため、追加構成は不要です。 中継サーバー (サービス・オーケストレーション・エンジン、SMS Gateway、リバース・プロキシーなど) を介した Watson サービスへの接続やその他の接続は、SSL および TLS 暗号化を構成することによって保護する必要があります。

Voice Gateway 用に SSL 暗号化や TLS 暗号化を構成するには、Docker データ・ボリュームにマウントされ、各コンテナーの構成で参照される PEM ファイルおよび PKCS #12 ファイルが必要です。

PKCS #12 ファイルの生成に必要なファイルは、PEM フォーマットでなければなりません。 認証局で提供されているファイルが PEM フォーマットでない場合は、OpenSSL などのツールを使用して、必要な PEM フォーマットにファイルを変換できます。 OpenSSL は、リストされている証明書および秘密鍵から PKCS #12 ファイルを生成するためにも使用できます。

Docker での鍵ストア・ファイルおよびトラストストア・ファイルの構成

デフォルトでは、Voice Gateway は、公開されている REST API を保護するために、自己署名証明書を使用します。 デフォルトの鍵ストアとトラストストアを変更する場合は、以下の手順を使用します。 SIP Orchestrator の構成では、Docker ボリューム上にそれらのファイルをマウントします。 ボリュームについて詳しくは、Docker 資料を参照してください。 以下の例では、$PWD は現行作業ディレクトリーに解決され、コンテナーの /sslConf/ パスにマウントされます。

    volumes:
      - $PWD:/sslConf/
      # $PWD resolves to the working directory and
      # mounts it to the /sslConf/ path on the container

トラストストアと鍵ストアの両方について、ファイルの場所、ファイル・タイプ、および対応するパスフレーズを以下の環境変数に指定します。 1 つのファイルに鍵ストアとトラストストアを生成した場合は、両方の環境変数セットで同じファイルを指定します。

services:
  sip.orchestrator:
 ...
    environment:
 ...
 # Trust store
 - SSL_KEY_TRUST_STORE_FILE=/sslConf/myTrustJKSFile.jks
 - SSL_FILE_TYPE=JKS
 - SSL_PASSPHRASE=myPassphrase

  # Key store
  - SSL_KEY_STORE_FILE=/sslConf/myKeyJKSFile.jks
  - SSL_KEY_FILE_TYPE=JKS
  - SSL_KEY_PASSPHRASE=myPassphrase

変更を有効にするために Voice Gateway を再デプロイします。

トラステッド認証局および自己署名証明書の追加

暗号化接続では、トラステッド認証局 (CA) および自己署名証明書のセットを定義できます。これらは、接続に関与するパーティーの ID を検査するために使用されます。

これらのトラステッド証明書を定義する方法は、コンテナーごとに異なります。SIP Orchestrator では、JKS、JCEKS、または PKCS #12 ファイルが必要ですが、Media Relay では、任意の PEM フォーマットのファイルを使用できます。

SIP Orchestrator 用のトラステッド証明書の追加

トラステッド証明書を SIP Orchestrator に追加すると、Watson Assistant サービスへの接続が保護されます。 SIP Orchestrator 用のトラステッド証明書を定義するには、信頼する証明書が含まれたトラストストア・ファイルを生成します。 トラストストア・ファイルを生成するには、認証局 (CA) 証明書が必要です。この証明書は通常 .pem、.crt、.cer、または .cert ファイルです。

  1. 信頼する CA からの証明書が含まれた JKS、JCEKS、または PKCS #12 トラストストア・ファイルを生成します。 次の例では、Java™ keytool コマンドを使用して、PKCS #12 トラストストア・ファイルを生成します。

     keytool -importcert \
     -file <CA certificate to trust> \
     -alias <alias for the certificate> \
     -keystore <name of the trustore> \
     -storepass <password for the truststore> \
     -storetype pkcs12

  2. ファイルを Docker ボリュームにマウントします。 詳しくは、Docker 資料を参照してください。

     volumes:
   - $PWD:/sslConf/
   # $PWD resolves to the working directory and
   # mounts it to the /sslConf/ path on the container

  3. SIP Orchestrator 構成で、ファイルの場所、ファイル・タイプ、および対応するパスフレーズを以下の環境変数に指定します。

     environment:
   ...
   - SSL_KEY_TRUST_STORE_FILE=/sslConf/myPKCS12File.p12
   - SSL_FILE_TYPE=PKCS12
   - SSL_PASSPHRASE=myPassphrase

Media Relay 用のトラステッド証明書の追加

トラステッド証明書を Media Relay に追加すると、Watson Speech to Text サービスおよび Text to Speech サービスへの接続が保護されます。 Media Relay 用のトラステッド証明書を定義するには、信頼するすべてのルート認証局が含まれた PEM フォーマットのファイルを用意します。

  1. 信頼する証明書が含まれたファイルを PEM フォーマットで作成します。 通常、このファイルの構造は以下のとおりです。

     -----BEGIN CERTIFICATE-----
   ...
 -----END CERTIFICATE-----
 -----BEGIN CERTIFICATE-----
   ...
 -----END CERTIFICATE-----

    以下のように、cat コマンドを使用して証明書を連結できます。

     cat cert1.pem cert2.pem ... > ca-bundle.pem

  2. ファイルを Docker ボリュームにマウントします。 詳しくは、Docker 資料を参照してください。

     volumes:
   - $PWD:/sslConf/
   # $PWD resolves to the working directory and
   # mounts it to the /sslConf/ path on the container

  3. Media Relay の構成で、PEM ファイルの場所を SSL_CLIENT_CA_CERTIFICATE_FILE 環境変数に指定します。

     environment:
   ...
   # Assume the file containing the certificates is called ca-bundle.pem
   - SSL_CLIENT_CA_CERTIFICATE_FILE=/sslConf/ca-bundle.pem

相互認証の構成

相互認証を必要とするゲートウェイ・サーバーを介して Watson サービスに接続する場合は、Voice Gateway で相互認証を構成する必要があります。

相互認証を構成する最も簡単な方法は、単一の PKCS #12 ファイルを生成することです。そのファイルを SIP Orchestrator と Media Relay の両方に使用できます。 このファイルには、秘密鍵とその証明書、および信頼する認証局が含まれている必要があります。

PKCS #12 ファイルを生成するには、以下の PEM フォーマットのファイルが必要です。

注: この単一の PKCS #12 ファイルを使用できるのは、相互認証が構成されている場合のみです。 相互認証なしで SSL または TLS を構成した場合、『SSL および TLS 暗号化の構成』セクションで説明したように、SIP Orchestrator と Media Relay のそれぞれに別個のファイルが必要になります。

  1. 秘密鍵、その証明書、および証明書チェーンから PKCS #12 ファイルを生成します。 次の例では、OpenSSL ツールを使用してファイルを生成します。

    openssl pkcs12 -export \
 -in <certificate file> \
 -inkey <private key file> \
 -CAfile <certificate chain> \
 -chain -out <filename>.p12

  2. keytool コマンドで CA 証明書を指定して、トラステッド証明書を PKCS #12 ファイルに追加します。

    keytool -importcert \
 -file <CA certificate to trust> \
 -alias <alias for the certificate> \
 -keystore <name of the trustore> \
 -storepass <password for the truststore> \
 -storetype pkcs12

  3. ファイルを Docker ボリュームにマウントします。 詳しくは、Docker 資料を参照してください。

     volumes:
   - $PWD:/sslConf/
   # $PWD will resolve to the working directory and
   # will mount it to the /sslConf/ path on the container

  4. 各コンテナーの構成で、ファイルの場所、ファイル・タイプ、および対応するパスフレーズを以下の環境変数に指定します。

    • SIP Orchestrator の場合:
      environment:
...
- SSL_KEY_TRUST_STORE_FILE=/sslConf/myPKCS12File.p12
- SSL_FILE_TYPE=PKCS12
- SSL_PASSPHRASE=myPassphrase
    • Media Relay の場合:
      environment:
...
- SSL_CLIENT_PKCS12_FILE=/sslConf/myPKCS12File.p12
- SSL_CLIENT_PASSPHRASE=myPassphrase

Media Relay から Speech to Text Adapter への SSL および TLS 暗号化の構成

パブリック・インターネットを介して Media Relay から Speech to Text Adapter に接続する場合、マイクロサービス間でセキュア接続を確立することをお勧めします。 接続をセキュアにするために、Speech to Text Adapter の PKCS #12 ファイルを生成し、その証明書を Media Relay トラストストアに追加します。

PKCS #12 ファイルを生成するには、以下の PEM フォーマットのファイルが必要です。

  1. 秘密鍵、その証明書、および証明書チェーンから PKCS #12 ファイルを生成します。 次の例では、OpenSSL ツールを使用してファイルを生成します。

    openssl pkcs12 -export \
 -in <certificate file> \
 -inkey <private key file> \
 -CAfile <certificate chain> \
 -chain -out <filename>.p12

  2. ファイルを Docker ボリュームにマウントします。 詳しくは、Docker 資料を参照してください。

     volumes:
   - $PWD:/sslConf/
   # $PWD will resolve to the working directory and
   # will mount it to the /sslConf/ path on the container

  3. Speech to Text Adapter コンテナーの構成で、ファイルの場所とそれに対応するパスフレーズを以下の環境変数に指定します。

    environment:
  ...
  - SSL_SERVER_PKCS12_FILE=/sslConf/myPKCS12File.p12
  - SSL_SERVER_PASSPHRASE=myPassphrase

  4. Speech to Text Adapter および Text to Speech サービスの PEM 形式の CA 証明書を含む信頼証明書ファイルを作成します。 OpenSSL などのツールを使用して、Text to Speech サービスの証明書を抽出できます。

    単一の PEM 形式ファイルに証明書を連結するには、以下の構文を使用して cat コマンドを実行します。

     cat <stt-adapter ca certificate> <text-to-speech certificate> > <trusted certificates>

    例:

     cat stt-adapter-ca.pem DigiCertGlobalRootCa.pem > ca-bundle.pem

  5. ファイルを Docker ボリュームにマウントします。 詳しくは、Docker 資料を参照してください。

     volumes:
   - $PWD:/sslConf/
   # $PWD resolves to the working directory and
   # mounts it to the /sslConf/ path on the container

  6. Media Relay の構成で、PEM ファイルの場所を SSL_CLIENT_CA_CERTIFICATE_FILE 環境変数に指定します。 次の例では、PEM ファイルは ca-bundle.pem という名前です。

     environment:
   ...
   - SSL_CLIENT_CA_CERTIFICATE_FILE=/sslConf/ca-bundle.pem

Speech To Text Adapter の基本認証の構成

Speech To Text Adapter が Voice Gateway と同じネットワークにない場合、認証された要求のみを受け入れるために、Speech To Text Adapter で基本認証を有効にすることができます。

  1. STT_ADAPTER_USERNAME と STT_ADAPTER_PASSWORD を構成することにより、Speech To Text Adapter で基本認証を有効にします。

       environment:
     ...
     - STT_ADAPTER_USERNAME=myAdapterUsername
     - STT_ADAPTER_PASSWORD=myAdapterPassword

  2. Media Relay の構成で、WATSON_STT_USERNAME と WATSON_STT_PASSWORD でユーザー名とパスワードを指定します。

       environment:
     ...
     - WATSON_STT_USERNAME=myAdapterUsername
     - WATSON_STT_PASSWORD=myAdapterPassword

発信者および着信者のホワイトリスト登録

特定のアドレスを宛先または発信元とする通話をホワイトリストに登録できます。これにより、Voice Gateway は、定義されているアドレスを宛先または発信元とする通話のみを受け入れます。 ホワイトリスト登録が構成されている場合、明示的に許可されていないソースからの通話およびその他の通信はいっさい接続できません。 SIP Orchestrator の構成環境変数を定義することで、SIP URI または IP アドレスによって通話をホワイトリストに登録できます。

注: マルチテナント構成では、構成されたテナントへの通話のみが接続できて、構成されたテナントへの通話が効果的にホワイトリスト登録されます。

SIP URI によるホワイトリスト登録

発信者が Voice Gateway への接続を試みると、発信者の SIP URI が渡されます。これには、電話番号やホストなどの情報が以下のフォーマットで含まれます。

sip:番号またはユーザー名@ホストのドメインまたはIP[:ポート]

例:
sip:12345556789@myhost.com

特定の SIP URI を宛先または発信元とする通話をホワイトリストに登録するには、SIP Orchestrator の次の環境変数を定義します。

表 3. ホワイトリスト登録を構成するための環境変数
環境変数 デフォルト値 説明
WHITELIST_FROM_URI なし 定義されている場合、Voice Gateway は、SIP From URI 内に指定ストリング (電話番号など) が含まれている通話のみを受け入れます。 コンマ区切りリストで複数のストリングを定義できます。
WHITELIST_TO_URI なし これが定義された場合、Voice Gateway は、指定されたストリング (電話番号など) が SIP To URI に含まれている通話のみを受け入れます。 バージョン 1.0.0.3 以降では、To ヘッダー・フィールド内でストリングが見つからない場合、Voice Gateway は Request-URI 値を検索します。

例えば、以下の構成では、SIP To URI に 2345556789 が含まれている通話 (SIP トランクからの sip:12345556789@myhost.com の電話番号など) のみが許可されます。 バージョン 1.0.0.3 以降では、2345556789 が To URI で見つからない場合、Voice Gateway は次に Request-URI 値を確認して、そのフィールドに 2345556789 が含まれている通話を許可します。

- WHITELIST_TO_URI=2345556789

SIPREC メタデータ内のフィールドによるホワイトリスト登録

SIPREC メタデータ内のフィールドに基づいて SIPREC 通話をホワイトリストに登録するには、以下の SIP Orchestrator 環境変数を定義します。

環境変数 デフォルト値 説明
WHITELIST_SIPREC_ATTR_NAME なし 『Voice Gateway の環境変数の構成』を参照してください。
WHITELIST_SIPREC_ATTR_VALUE なし 『Voice Gateway の環境変数の構成』を参照してください。

例えば、以下の構成では、SIPREC メタデータに 111111111 と一致する値を持つ aor 属性が含まれている SIPREC 通話のみが許可されます。

- WHITELIST_SIPREC_ATTR_NAME=aor
- WHITELIST_SIPREC_ATTR_VALUE=111111111

<?xml version="1.0" encoding="UTF-8"?>
<tns:recording
    xmlns:tns='urn:ietf:params:xml:ns:recording'>
    <tns:datamode>complete</tns:datamode>
    <tns:group group_id="YTIyYWRmNjAtMGZhNi0xMA==">
        <tns:associate-time>2016-06-08T12:58:34Z</tns:associate-time>
        <callData
            xmlns='urn:ietf:params:xml:ns:callData'>
            <fromhdr>&lt;sip:111111111@115.110.121.1&gt;;tag=gK0c638f27</fromhdr>
            <tohdr>&lt;sip:222222222@10.0.0.6&gt;;tag=gK08ddd5f7</tohdr>
            <callid>1292673994_41860201@115.110.121.1</callid>
            <gcid>239610873</gcid>
        </callData>
    </tns:group>
    <tns:session session_id="YTIyYWRmNjEtMGZhNi0xMA==">
        <tns:group-ref>YTIyYWRmNjAtMGZhNi0xMA==</tns:group-ref>
        <tns:start-time>2016-06-08T12:58:34Z</tns:start-time>
    </tns:session>
    <tns:participant participant_id="YTIyYWRmNjItMGZhNi0xMA==">
        <tns:nameID aor="111111111@115.110.121.1">
            <tns:name xml:lang="en"></tns:name>
        </tns:nameID>
    </tns:participant>
    <tns:participant participant_id="YTIyYWRmNjMtMGZhNi0xMA==">
        <tns:nameID aor="222222222@10.0.0.6">
            <tns:name xml:lang="en"></tns:name>
        </tns:nameID>
    </tns:participant>
    <tns:stream stream_id="YTIyYWRmNjQtMGZhNi0xMA==" session_id="YTIyYWRmNjEtMGZhNi0xMA==">
        <tns:label>1</tns:label>
        <tns:associate-time>2016-06-08T12:58:34Z</tns:associate-time>
    </tns:stream>
    <tns:stream stream_id="YTIyYWRmNjUtMGZhNi0xMA==" session_id="YTIyYWRmNjEtMGZhNi0xMA==">
        <tns:label>2</tns:label>
        <tns:associate-time>2016-06-08T12:58:34Z</tns:associate-time>
    </tns:stream>
    <tns:sessionrecordingassoc session_id="YTIyYWRmNjEtMGZhNi0xMA==">
        <tns:associate-time>2016-06-08T12:58:34Z</tns:associate-time>
    </tns:sessionrecordingassoc>
    <tns:participantsessionassoc participant_id="YTIyYWRmNjItMGZhNi0xMA==" session_id="YTIyYWRmNjEtMGZhNi0xMA==">
        <tns:associate-time>2016-06-08T12:58:34Z</tns:associate-time>
    </tns:participantsessionassoc>
    <tns:participantsessionassoc participant_id="YTIyYWRmNjMtMGZhNi0xMA==" session_id="YTIyYWRmNjEtMGZhNi0xMA==">
        <tns:associate-time>2016-06-08T12:58:34Z</tns:associate-time>
    </tns:participantsessionassoc>
    <tns:participantstreamassoc participant_id="YTIyYWRmNjItMGZhNi0xMA==">
        <tns:send>YTIyYWRmNjUtMGZhNi0xMA==</tns:send>
        <tns:recv>YTIyYWRmNjQtMGZhNi0xMA==</tns:recv>
    </tns:participantstreamassoc>
    <tns:participantstreamassoc participant_id="YTIyYWRmNjMtMGZhNi0xMA==">
        <tns:send>YTIyYWRmNjQtMGZhNi0xMA==</tns:send>
        <tns:recv>YTIyYWRmNjUtMGZhNi0xMA==</tns:recv>
    </tns:participantstreamassoc>
</tns:recording>

IP アドレスによるホワイトリスト登録

特定の IP アドレスをホワイトリストに登録すると、Voice Gateway は、定義された IP からの通話のみを受け入れます。 他の IP アドレスからの通信はすべて拒否されます。これには、通話だけでなく、例えば Voice Gateway をモニターするために送信される OPTIONS メッセージも含まれます。

IP アドレスによるホワイトリスト登録を構成するには、SIP Orchestrator 構成の TRUSTED_IP_LIST 環境変数で IP アドレスのコンマ区切りリストを定義します。

- TRUSTED_IP_LIST=192.0.4.128,123.4.5.67,198.7.6.234

構成について詳しくは、『Voice Gateway の構成環境変数』を参照してください。

ボリュームのホスト・ディレクトリー権限の設定

注: 以下の説明は Linux にのみ適用されます。

セキュリティー上の理由から、バージョン 1.0.2 以降、コンテナーは root として実行されません。 代わりに、コンテナーは、UID が 1001 のユーザー default として実行されます。

コンテナーにマウントされたボリュームの場合は、ホスト・マシン上のマウントされたディレクトリーに適切な権限が適用されていることを確認してください。 Docker または Kubernetes/ICP (hostPath ボリューム) を使用してデプロイする場合は、ホスト上のボリュームがマウントされているディレクトリーにユーザーが書き込むことを許可する権限を適用します。

これを行うには、以下のコマンドを実行する必要があります。

chown -R 1001:0 <path to volume mounted dir on host>
chmod -R g+rw <path to volume mounted dir on host>

コンテナーを root として実行する必要がある場合は、デプロイメント・ファイル内に以下のように指定します。

Docker docker-compose.yaml の場合:

Kubernetes/ICP の場合:

注: 実稼働環境では、コンテナーを root ユーザーとして実行することは推奨されません。

1001 ユーザー ID: コンテナーは、デフォルトで、内部的に 1001 ユーザー ID として実行されます。 このユーザー ID は、クラスターに存在している必要はなく、ワーカー・ノードに存在している必要もありません。 永続ボリュームが機能するために、1001 ユーザー ID はディレクトリーを所有する必要があります。

コンテナーのユーザー ID を確認するには、ポッドに kubetcl exec コマンドを実行します。

kubectl exec -it <podName> bash

次に、以下のコマンドを実行して、コンテナーのユーザー ID を出力します。

id -u

出力には、以下のユーザー ID が表示されます。

1001