REST APIトラフィックの暗号化

このセクションでは、NTT CPaaSがパブリックトラフィックの暗号化をどのように処理し、当社のREST APIをご利用中の中断を発生させないよう、セキュリティ変更にどのように対応しているかについて説明します。

HTTPトラフィックのTLS暗号化

NTT CPaaSでは、ネットワーク上でデータを安全に転送するために、Secure Socket Layer (SSL) の後継として知られるTransport Layer Security (TLS) を採用しています。

また当社は、複数のバージョンが存在するTLSプロトコルの中で、最も安全なバージョンと暗号アルゴリズムを使用するよう徹底しています。

以下のリストには、対応してしているREST APIのTLSバージョンと暗号スイートが記載されています：

• TLSv1.3 (サーバー優先順のスイート付き)：

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_128_CCM_SHA256

• TLSv1.2 (サーバー優先順のスイート付き)：

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_CCM
  • TLS_DHE_RSA_WITH_AES_256_CCM
  • TLS_DHE_RSA_WITH_AES_128_CCM_8
  • TLS_DHE_RSA_WITH_AES_256_CCM_8
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

TLS/SSLの変更

当社は、お客様に最大限の透明性を提供するべく、以下のTLS変更ポリシーに準拠しています：

• TLSバージョンまたは暗号スイートの変更については、少なくとも6か月前にお客様に通知されます。
• TLS暗号スイートの変更については、少なくとも60日前にお客様に通知されます。
• SSL証明書の変更については、変更予定日の少なくとも60日前までに、信頼チェーンの変更に関する情報を含む通知が届きます。証明書は通知が発行される前に、当社のTLSテスト用エンドポイントにインストールされます。

すべての変更は、ステータス ページに掲載され、以下の3つのいずれかの状態で掲載されます：

1. Scheduled (予定済み) - 証明書の変更が告知され、テスト用エンドポイントで新しい証明書が利用可能になっています。
2. In progress (進行中) - 更新中です。
3. Completed (完了) - 証明書の置き換えが完了しています。

TLSプロトコルの脆弱性が判明した場合など、セキュリティ上の緊急事態が発生した際には、製品の安全性を確保するため、TLSに対する必要な調整を直ちに実施することにご留意ください。その後、これらの変更については、速やかにお客様に通知されます。

他にも何かご不明な点がある場合は、サポート までお問い合わせください。

TLS/SSL証明書の変更

TLSの暗号化には、最も広く利用されている認証局 (CA) の一つであるDigiCertの署名入りSSL証明書を使用しています。

パブリックREST APIエンドポイントには、有効期間が1年の証明書が設定されており、適宜更新されます。証明書をピン留めせず、トラストストアの自動更新を有効にしているお客様は、これらの変更の影響を受けません。

変更の影響を受けるケース [#cases-impacted-by-the-changes-tlsssl-certificate-changes]

リーフ証明書のピン留め [#leaf-certificate-pinning-tlsssl-certificate-changes]

この手法には高いアジリティコストと制約が伴うため、当社では推奨していません。それでもこの手法を採用する場合は、必ず以下の点に配慮しながら実施するようにしてください：

• ピン留めされた証明書を積極的に監視し、適時更新すること。
• NTT CPaaSの証明書切り替えポリシーに留意すること。

より安全な代替手段として、mTLS (クライアント証明書認証) を使用することをお勧めします。詳細については、サポート までお問い合わせください。

手動操作のトラストストア [#manually-operated-trust-store-tlsssl-certificate-changes]

殆どのトラストストアは自動的に更新されますが、中にはトラストストアを手動で操作することを選択されるお客様もおられます。当社では、DigiCertのPKIを採用しており、すべてのCAはルートCAのウェブサイト からダウンロードできます。

信頼するCAを特定の一つの局のみに限定する必要がない場合は、Mozillaが信頼する CAをPEM形式でインストールすることをお勧めします。

TLSテスト用エンドポイント

証明書の変更が予定されている場合、テスト用エンドポイントで新しい証明書を利用可能にします。TLSテスト用エンドポイントは、NTT CPaaSサービスにアクセスする本番環境から利用し、それらを連携するサービスと同じトラストストアを使用する必要があります。

テスト方法 [#how-to-test-tls-test-endpoints]

ワイルドカードではない証明書は、同じエンドポイントにインストールされ、curl コマンドを使用してテストできます。例えば、api.infobip.com の場合、172.201.176.225 がTLSテスト用エンドポイントのIPアドレスとなります：

次の例では、ワイルドカード証明書のテストに米国内のロケーションが使用されています：

以下は、TLSテスト用エンドポイントのJSONレスポンスが正常に返された成功例です：

レスポンスをより深く理解するためには、以下の項目をご確認ください：

• fingerprintSHA256hex - サーバーのSSL証明書を16進数形式で表した SHA256フィンガープリント。
• tlsVersion - https 暗号化に使用するTLSバージョン。
• usedCipher - SSLハンドシェイクに使用する暗号アルゴリズム。
• commonName - サーバー証明書に記載されるCN。
• sni - 適切なSSL証明書を選択するために使用するサーバー名表示 (SNI)。
• issuedBy - リーフ証明書に署名したCAのCN。
• expire - YYMMDDhhmmss[Z] 形式の文字列で表したSSL証明書の有効期限。

トラストストアを手動で操作したり、リーフ証明書や中間証明書をピン留めしたりしているお客様には、以下の行動を取ることを 強くお勧め します：

1. 変更に注意： ステータス ページをフォローして、最新情報を確認するようにします。
2. テスト： 変更が告知されたら、提供されているテスト用エンドポイントを使って、任意の http クライアントとの TLS接続をテストしてみます。
3. 構成の更新： TLS接続が失敗した場合は、ローカルのSSL構成を更新するようにします。
4. 検証： ローカル構成を変更するたびに、「TLSテスト用エンドポイントに接続」が正常に動作するかを検証するようにします。

備考： 準備が期限までに完了しなかった場合でも、変更が先送りされたり元に戻されたりすることはありません。その代わり、新しい変更をできるだけ早く導入できるよう、当社では技術サポートを積極的に提供する用意があります。詳細については、サポート までお問い合わせください。

考えられるTLS/SSLエラーとその解決方法

TLS/SSLに関する一般的なエラーは数多くありますが、当社ではそれらをできるだけ早く解決できるよう、最善のサポートを提供することに努めています。予定されている切り替えの前に、当社のテスト用エンドポイントを確認することで、発生しうる問題を事前に検出することができます。

より効率的に対処するには、以下に挙げるよくある問題点を確認し、対処可能な情報を当社までご提供ください。

TLSチェーンエラー [#tls-chain-errors-possible-tlsssl-errors-and-how-to-resolve-them]

TLSチェーンエラーは、ローカルシステムまたはクライアントにNTT CPaaSのCAが想定通りに構成されていないことを意味します：

Curlの不明CAエラー 例：

考えられる解決策：

1. クライアントのシステムに存在するCA証明書を確認し、Mozillaが信頼する のCAをPEM 形式でダウンロードしてインストールします。
2. クライアントが正しいディレクトリからCA証明書を読み込んでいることを確認するようにします。

SSLハンドシェイクエラー [#ssl-handshake-errors-possible-tlsssl-errors-and-how-to-resolve-them]

SSLハンドシェイクエラーは、プロトコルエラーや暗号スイートエラーとして現れることもよくあります。これらは、クライアントがTLSのバージョンや暗号スイートに対応していない場合に発生します。

Curlのプロトコルエラー 例：

サポートされていないクライアントの暗号スイートが原因で発生するCurlのハンドシェイクエラー 例：

考えられる解決策：

1. クライアントがファイアウォール、SSLインスペクションまたはVPNの背後にある場合は、NTT CPaaSが採用しているTLSや暗号スイートにそれらが対応しているかを確認します。
2. クライアントが利用可能なTLSバージョンや暗号スイートに対応しているかを確認します。
3. 可能であれば、最新のTLSバージョンを使用するようにクライアントを明示的に構成するようにします。