TLSアクセラレーター

読み：てぃーえるえすあくせられーたー　／　英語表記：TLS Accelerator

• セキュリティ
• サーバ・ストレージ

TLS通信で必要な暗号処理を専用回路などへ任せ、サーバのCPUの負荷を軽減する機能または装置である。HTTPS通信をサーバの手前で受け持つ構成のほか、サーバ内部で計算を支援する構成もあり、通信処理の性能向上に用いる。

イマシルちゃんの解説

HTTPSでWebサイトを使うと、サーバはページを作るだけでなく通信を守るための計算も行うんだ。
接続が増えると、その計算が大きな負担になることがあるよ。
TLSアクセラレーターは、暗号に関する計算を専用の回路などで助ける機能や装置なんだ。
例えばWebサーバの手前に置き、利用者との暗号化された通信を代わりに受け持つ構成があるの。
サーバが本来の仕事に使える余裕を増やして、多くの接続を処理しやすくするよ。
ただし装置からサーバまでの通信も守るかは、別に設定する必要があるんだ。

より深い解説

どの計算を速くするのか

HTTPSではWebアプリケーションの処理に加え、通信相手の確認やデータの保護を行う。接続開始時のハンドシェイクでは、暗号方式の合意や鍵交換、証明書に対応する鍵を使った署名などを行う。実際のデータ転送では主に共通鍵暗号による暗号化と完全性の保護を繰り返すため、新しい接続を大量に受ける場合と大きなデータを送り続ける場合では負荷の内訳が異なる。

アクセラレーターはこうした計算を支援する。実装には専用チップや拡張カードなどがあり、対応する暗号ライブラリやソフトウェアとの組合せが必要になる。Intel QATは接続開始時とデータ転送時の両方の暗号計算を支援できるが、実際にどの処理を任せられるかは利用するソフトウェアによって異なる。Intelの技術資料では、この二つの処理段階を区別している。

一方、ソフトウェア側の連携が特定の署名処理だけを対象としている場合、機器を搭載しただけで通信全体が速くなるわけではない。専用回路の処理完了を確認する間隔などによって待ち時間も変わるため、利用率や応答時間を実際の負荷で測る必要がある。このような実装上の違いはIntelのEnvoy向け資料で確認できる。

計算を任せることと通信相手になること

サーバが担っていた処理を別の機器や回路へ移すことをオフロードという。これに対し、TLS接続の相手となって通信を復号することをTLSの終端という。前者は負担をどこへ移すか、後者は暗号化された接続がどこまで続くかという違いがある。

サーバ内部の拡張カードに計算を任せるだけなら、利用者から見た接続相手は引き続きそのサーバである。Webサーバの手前にあるロードバランサやリバースプロキシでTLS接続を受ける構成では、利用者の接続相手はその中継機器になる。中継機器の機能として高速化用の回路を備える製品もあるが、TLS接続を受けられることだけで専用回路の搭載や性能向上が保証されるわけではない。

Webサーバの手前で受け持つ構成

中継機器が利用者とのTLS接続を受ける場合、基本的な流れは次のようになる。

1. 利用者は公開サービス名に対応するアドレスへ接続する。
2. 中継機器がそのサービス名に合う証明書を提示し、TLS接続を確立する。
3. 中継機器が受信データを復号し、HTTPリクエストを取り出す。
4. 中継機器が別の接続でバックエンドのWebサーバへリクエストを送る。
5. Webサーバの応答を受け取り、利用者との接続で暗号化して返す。

この構成では中継機器が通信内容を扱えるため、同じ場所でWAFによる検査やURLに応じた振分けを行える。反面、中継機器の内部では平文の内容を扱うことになる。管理権限やログの保存範囲を含めて保護する必要がある。

バックエンドまでの区間を設計する

利用者側がHTTPSであっても、バックエンド側まで同じ接続が続くとは限らない。代表的な構成を区別すると次のようになる。

バックエンドもHTTPSにする構成では、中継機器がいったん復号した内容を再暗号化する。TLS接続は利用者側とバックエンド側で別々になるため、暗号方式や証明書の検証も区間ごとに設定する。Webサーバ側にも計算が残るが、中継機器との接続を使い回すことで接続開始時の負荷を抑えられる場合がある。

暗号化されたデータを復号せずに転送する方式はTLSパススルーと呼ばれる。この構成だけではWebサーバの暗号計算を肩代わりできず、HTTPの本文を読む検査も中継機器では行えない。各区間をどの機器が受け持つかという構成例はNGINXの構成移行ガイドに示されている。

鍵と証明書の管理が必要になる

中継機器が公開サービスの接続を受ける場合、証明書だけでなく対応する秘密鍵による処理が必要になる。鍵を機器内に置く方式と外部の保護装置で鍵の演算を行う方式などがあるため、鍵の保管場所と操作権限を確認する。証明書の有効期限、対象のサービス名、中間証明書の提示も接続の成否に関わる。

一つのアドレスで複数のサービスを扱う場合、接続開始時に送られるSNIという拡張情報を利用して提示する証明書を選択できる。HTTPのHostヘッダーはTLS接続を確立した後に読み取る情報なので、通常はこれだけで最初の証明書を選べない。NGINXの証明書設定資料では、証明書のチェーンとサービス名による選択を説明している。

また、TLS 1.3では古いRSA鍵配送方式が廃止されている。「サーバの長期鍵があれば、途中で収集したTLS通信を常に後から復号できる」とは考えない。例えば一時的な鍵を用いるECDHEの接続では、その接続で合意した鍵が必要になる。ここで説明している中継構成のアクセラレーターは、通信相手として接続時の計算に参加する。RFC 8446がTLS 1.3の仕様を定めている。

利用者をクライアント証明書で認証する場合も、中継機器がどこまで認証するかを決める。利用者が中継機器に証明書を示した事実は、別に作ったバックエンド側の接続へ自動では引き継がれない。認証済みの利用者情報をアプリケーションへ渡すなら、信頼できる中継機器からの情報だけを受け入れ、外部から同名のヘッダーを送って偽装できないようにする。

内部区間でも接続相手を確かめる

バックエンド側をHTTPSにしても、接続先の証明書検証を無効にしていれば意図したサーバと通信しているかを十分に確認できない。信頼する認証局と検証対象の名前を設定し、証明書の有効期限やチェーンを確かめる必要がある。

例えばNGINXでTLS接続を受け、定義済みのバックエンド群app_poolへHTTPSで転送する場合、次の設定は接続先を検証する部分の一例になる。

location / {
    proxy_pass https://app_pool;
    proxy_ssl_server_name on;
    proxy_ssl_name app.internal.example;
    proxy_ssl_trusted_certificate /etc/nginx/backend-ca.pem;
    proxy_ssl_verify on;
}

ここではバックエンドの証明書に合う名前をapp.internal.exampleとしている。実際には信頼する認証局のファイルと証明書のチェーンを環境に合わせて用意し、必要な検証の深さも設定する。これは転送時の設定の抜粋であり、利用者側の待受け設定や専用回路による高速化の設定は含まない。

NGINXでは接続先の検証が既定で無効なので、https://を指定するだけで検証も有効になると考えない。各項目の役割はNGINXの転送機能の仕様とバックエンド通信の保護手順で確認できる。

性能を三つの観点で測る

「何Gbps処理できるか」だけでは必要な能力を判断できない。サービスの負荷に合わせて次の指標を使い分ける。

既に確立した接続で複数のリクエストを送ることと、新しい接続で以前の情報を利用するセッション再開は別の仕組みである。どちらも処理量に影響するため、測定時には新規接続と再利用される接続の割合を実際のサービスへ近づける。試験結果の数値だけを比較せず、その測定条件まで確認する。

改善前にはCPU使用率の内訳や待ち時間を調べる。データベースの遅延や回線の混雑がボトルネックなら、暗号計算を速くしてもページ全体の応答時間はあまり縮まらない。利用者の接続開始、中継機器での処理、バックエンドの応答という段階ごとに測ることが重要である。

障害と更新を想定する

処理を一か所へ集めると、その機器の停止がサービス全体に影響しやすくなる。冗長化する場合は台数を増やすだけでなく、証明書や鍵、振分け設定の同期方法を確認する。切替え時に既存の接続を継続できるかは製品と構成によって異なり、利用者の再接続が必要になる場合もある。

証明書の更新やセキュリティパッチの適用も運用に含める。片系だけ証明書が古い状態では、通常時に見えていなかった問題が切替え後に発生し得る。両系の接続試験と更新後の反映確認までを手順にする。

構成問題で確認すること

例えば「外部からHTTPS接続が増え、Webサーバが暗号計算に多くの時間を使っている」という問題では、その計算を手前の機器で受け持つ構成が候補になる。ただし内部区間も暗号化する要件があれば、バックエンドへの接続と検証も設計する必要がある。

答案や設計書では、処理を任せる対象、TLS接続の両端、バックエンドまでの保護、証明書と鍵の管理場所を明示する。専用機器を置くこと自体を結論にせず、どの負荷を減らし、どの区間の安全性を確保するかまで説明すると構成の妥当性を判断しやすい。