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

NGINX | 2014年4月30日

Rick Nelsonソリューションエンジニアリング担当リージョナルバイスプレジデント

NGINXとNGINX Plusは、ほとんどのSSL/TLS要件に対応できるさまざまな機能を備えています。OpenSSLと汎用プロセッサチップの処理能力を活用し、コスト効率に優れたSSL/TLSパフォーマンスを実現します。汎用プロセッサチップの処理能力が向上し続け、チップベンダーによる暗号化アクセラレーションのサポートも進むにつれて、専用SSL/TLSチップに対する汎用プロセッサチップのコスト面での優位性はさらに拡大しています。

NGINXでHTTPSトラフィックを復号すると、多くのメリットが得られます

NGINXおよびNGINX PlusでSSL/TLSを使用する主なユースケースは3つあります。

SSL/TLSオフロード

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

パフォーマンスの向上 – SSL復号でパフォーマンスに最も大きな影響を与えるのは、最初のハンドシェイクです。パフォーマンスを向上させるため、復号を行うサーバーはSSLセッションIDをキャッシュし、TLSセッションチケットを管理します。これをプロキシで行うと、同じクライアントからのすべてのリクエストでキャッシュされた値を使用できます。バックエンドサーバーで行う場合、クライアントのリクエストが別のサーバーに送信されるたびに、クライアントで再認証が必要になります。TLSチケットを使用すると、この問題の軽減に役立ちますが、すべてのクライアントでサポートされているわけではなく、設定や管理が難しい場合があります。
バックエンドサーバーの利用効率向上 – SSL/TLS処理はCPUに非常に大きな負荷をかけ、鍵のサイズが大きくなるほど負荷も増加します。この処理をバックエンドサーバーから切り離すことで、バックエンドサーバーは最も効率よく実行できるコンテンツ配信に専念できます。
インテリジェントルーティング – トラフィックを復号することで、プロキシはヘッダーやURIなどのリクエスト内容にアクセスし、そのデータを使用してリクエストをルーティングできます。
証明書管理 – 証明書は、すべてのバックエンドサーバーではなく、プロキシサーバーにのみ購入してインストールすればよいため、時間とコストの両方を節約できます。
セキュリティパッチ – SSL/TLSスタックに脆弱性が生じた場合、該当するパッチはプロキシサーバーにのみ適用すれば済みます。

詳細については、NGINX Plus Admin Guideの「NGINX SSL Termination」を参照してください。

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

NGINXからバックエンドサーバーに送信するトラフィックを暗号化する必要がある場合があります。これらのリクエストは、プレーンテキストでNGINXサーバーに到達することもあれば、暗号化されたトラフィックとして到達し、ルーティングを決定するためにNGINXで復号する必要があることもあります。バックエンドサーバーへのキープアライブ接続をプールして使用すると、SSL/TLSハンドシェイクの回数を最小限に抑え、SSL/TLSのパフォーマンスを最大限に高めることができます。NGINXのプロキシ先を「https」に設定するだけで、まだ暗号化されていないトラフィックが自動的に暗号化されます。

エンドツーエンド暗号化

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

クライアント証明書

NGINXはSSL/TLSクライアント証明書を処理でき、証明書を任意または必須に設定できます。クライアント証明書を使用すると、パスワードを要求することなく、事前承認済みのクライアントのみにシステムへのアクセスを制限できます。また、失効した証明書を証明書失効リスト（CRL）に追加することで、証明書を管理できます。NGINXはCRLを確認し、クライアント証明書が引き続き有効かどうかを判定します。

その他のセキュリティ機能

これらのユースケースをサポートするその他の機能には、以下が含まれます（ただし、これらに限定されません）。

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

詳細については、以下のリソースをご覧ください。

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

例

以下に、NGINXのセキュリティ機能の例をいくつか示します。これらの例では、NGINXの設定に関する基本的な知識があることを前提としています。

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

upstream backends {
    server 192.168.100.100:80;
    server 192.168.100.101:80;
}

server {
    listen      80;
    server_name www.example.com;

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

次にHTTPS対応を追加し、NGINXが証明書と秘密鍵を使用してトラフィックを復号し、バックエンドサーバーとはHTTPで通信するようにします。

upstream backends {
    server 192.168.100.100:80;
    server 192.168.100.101:80;
}

server {
    listen              80;
    listen              443 ssl; # 'ssl' parameter tells NGINX to decrypt the traffic
    server_name         www.example.com;
    ssl_certificate www.example.com.crt; # The certificate file
    ssl_certificate_key www.example.com.key; # The private key file
  

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

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

upstream backends {
    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' prefix tells NGINX to encrypt the traffic
    }
}