NGINX と NGINX Plus による SSL/TLS オフロード、暗号化、証明書

NGINX と NGINX Plus は、ほとんどの SSL/TLS 要件を処理できるようにするさまざまな機能を提供します。 OpenSSL と標準プロセッサ チップのパワーを使用して、コスト効率の高い SSL/TLS パフォーマンスを提供します。 標準プロセッサ チップの性能が向上し続け、チップ ベンダーが暗号化アクセラレーションのサポートを追加するにつれて、専用の SSL/TLS チップよりも標準プロセッサ チップを使用するコスト上の利点も拡大し続けます。

SSL/TLS を使用した NGINX およびNGINX Plusには、主に 3 つの使用例があります。

SSL/TLS オフロード

NGINX をプロキシとして使用すると、バックエンド サーバーから SSL 復号化処理をオフロードできます。 プロキシで復号化を行うことには、いくつかの利点があります。

• パフォーマンスの向上 – SSL 復号化を行う際にパフォーマンスに最も大きな影響を与えるのは、最初のハンドシェイクです。 パフォーマンスを向上させるために、復号化を実行するサーバーは SSL セッション ID をキャッシュし、TLS セッション チケットを管理します。 これをプロキシで実行すると、同じクライアントからのすべてのリクエストでキャッシュされた値を使用できます。 バックエンド サーバーで実行される場合、クライアントのリクエストが別のサーバーに送信されるたびに、クライアントは再認証する必要があります。 TLS チケットを使用するとこの問題を軽減できますが、すべてのクライアントでサポートされているわけではなく、構成と管理が困難な場合があります。
• バックエンド サーバーの使用率向上 – SSL/TLS 処理は CPU を大量に消費し、キー サイズが大きくなるにつれて CPU の消費量も増加します。 バックエンド サーバーからこの作業を取り除くことで、最も効率的な作業であるコンテンツの配信に集中できるようになります。
• インテリジェント ルーティング – トラフィックを復号化することで、プロキシはヘッダーや URI などのリクエスト コンテンツにアクセスできるようになり、このデータを使用してリクエストをルーティングできます。
• 証明書管理 – 証明書は、すべてのバックエンド サーバーではなく、プロキシ サーバーにのみ購入してインストールする必要があります。 これにより、時間とお金の両方が節約されます。
• セキュリティ パッチ – SSL/TLS スタックに脆弱性が発生した場合は、プロキシ サーバーにのみ適切なパッチを適用する必要があります。

詳細については、NGINX Plus 管理者ガイドの「NGINX SSL 終了」を参照してください。

オリジンサーバーへのSSL/TLS暗号化

バックエンド サーバーに送信するトラフィックを NGINX で暗号化する必要がある場合があります。 これらのリクエストは、プレーンテキストとして、またはルーティングの決定を行うために NGINX が復号化する必要がある暗号化されたトラフィックとして NGINX サーバーに到着する可能性があります。  バックエンド サーバーへのキープアライブ接続のプールを使用すると、SSL/TLS ハンドシェイクの数が最小限に抑えられ、SSL/TLS のパフォーマンスが最大化されます。 これは、NGINX を「https」にプロキシするように構成し、まだ暗号化されていないトラフィックを自動的に暗号化することで非常に簡単に実現できます。

エンドツーエンドの暗号化

NGINX は復号化と暗号化の両方を実行できるため、NGINX がレイヤー 7 のルーティング決定を行いながら、すべてのリクエストのエンドツーエンドの暗号化を実現できます。 この場合、クライアントは HTTPS 経由で NGINX と通信し、リクエストを復号化してから再暗号化してからバックエンド サーバーに送信します。 これは、プロキシ サーバーがバックエンド サーバーと同じデータ センターに配置されていない場合に望ましい場合があります。 クラウドに移行するサーバーが増えるにつれて、プロキシとバックエンド サーバーの間で HTTPS を使用する必要性が高まっています。

クライアント証明書

NGINX はSSL/TLS クライアント証明書を処理でき、証明書をオプションまたは必須にするように構成できます。 クライアント証明書は、パスワードを必要とせずに、事前に承認されたクライアントのみにシステムへのアクセスを制限する方法であり、失効した証明書を証明書失効リスト(CRL) に追加することで証明書を制御できます。NGINX は、クライアント証明書がまだ有効かどうかを判断するために、このリストをチェックします。

追加のセキュリティ機能

これらのユースケースをサポートする他の機能は、次のものを含みますが、これらに限定されません。

• 複数の証明書 – 単一の NGINX インスタンスは、さまざまなドメインの多数の証明書をサポートでき、数十万の証明書をサポートするように拡張できます。 1 つの NGINX インスタンスで多数の IP アドレスとドメインを処理し、各ドメインに独自の証明書を要求するのは一般的な使用例です。
• OCSP ステープリング– これを有効にすると、NGINX には、証明機関によって署名されたタイムスタンプ付きの OCSP 応答が含まれ、クライアントはこれを使用してサーバーの証明書を検証できるため、OCSP サーバーに直接接続することによるパフォーマンスの低下を回避できます。
• SSL/TLS 暗号– 有効にする暗号を指定できます。
• SSL/TLS プロトコル- SSLv2、SSLv3、TLSv1、TLSv1.1、TLSv1.2 など、有効にするプロトコルを指定できます。
• チェーン証明書 - NGINX は証明書チェーンをサポートします。これは、Web サイトの証明書が CA (証明機関) のルート証明書によって直接署名されておらず、一連の中間証明書によって署名されている場合に使用されます。 Web サーバーは中間証明書を含む「証明書チェーン」を提示し、Web クライアントが Web サイト証明書を信頼されたルート証明書にリンクする信頼チェーンを検証できるようにします。
• HTTPS サーバーの最適化- NGINX は、ワーカー プロセスの数を構成し、キープアライブ接続を使用し、SSL/TLS セッション キャッシュを使用することで、SSL/TLS パフォーマンスを最大限に高めるように調整できます。

詳細については、次のリソースを参照してください。

• NGINX Plus 管理者ガイドのNGINX SSL 終了
• nginx.org でのHTTPS サーバーの設定
• nginx.org のngx_http_ssl_moduleリファレンス ドキュメント

例

NGINX のセキュリティ機能の例をいくつか紹介します。 これらの例では、NGINX 構成の基本的な理解を前提としています。

次の構成は、 www.example.comの HTTP トラフィックを処理し、それをアップストリーム グループにプロキシします。

アップストリーム バックエンド {
サーバー 192.168.100.100:80;
サーバー 192.168.100.101:80;
}

サーバー {
listen 80;
server_name www.example.com;

location / {
proxy_pass http://backends;
}
}

ここで、HTTPS サポートを追加します。これにより、NGINX は証明書と秘密キーを使用してトラフィックを復号化し、HTTP 経由でバックエンド サーバーと通信します。

アップストリームバックエンド { server 192.168.100.100:80; server 192.168.100.101:80; } server { listen 80; listen 443 ssl ; # 'ssl' パラメータは NGINX にトラフィックを復号化するように指示します server_name www.example.com; ssl_certificate www.example.com.crt ; # 証明書ファイルssl_certificate_key www.example.com.key ; # 秘密鍵ファイルの場所 / { proxy_pass http://backends; } }

または、代わりに HTTP 経由でトラフィックを受信し、それを HTTPS 経由でバックエンド サーバーに送信する場合:

アップストリームバックエンド { server 192.168.100.100:443; server 192.168.100.101:443; } server { listen 80; server_name www.example.com; location / { proxy_pass https ://backends; # 'https' プレフィックスは NGINX にトラフィックを暗号化するように指示します } }

NGINX Plus をお試しいただくには、今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、使用事例についてご相談ください。