71
第7章
セキュリティ コントロ ール
7.0 はじめに
セキュリティはレイヤーで行われ 、セキュリティモデルを真に強 化するには、セキュリテ
ィモデルに複数のレイヤーが必要です。本章では、NGINXおよび NGINX Plusを使用し
てWebアプリケーションを保護するためのさまざまな方法について説明します。これら
のセキュリティ対策の多くを組み合わせて使用すると、セキュリティを強化できます。
以 下 は 、ア プ リ ケ ー シ ョ ン の 強 化 に 役 立 つ NGINXおよびNGINX Plusの セキュリティ
機能について説明しているセクションです。本章では、NGINXの 最 大 の セキュリティ
機能の1つであるModSecurity 3.0 NGINXモジュールについて触れていないことに気付
くかもしれません 。これは、NGINXをWeb
アプリケーションファイアウォール
（WAF）
に変えるものです。WA F 機能の詳細については、ModSecurity 3.0 および NGINXをダ
ウ ン ロ ード してく だ さ い：ク イッ ク ス タ ート ガ イド 。
7.1 IPアドレスに 基づくアクセス
問題
クライアントの送信元に基づきアクセスをコントロールする必要があります。
解決法
HTTPまたはストリームアクセスモジュールを使 用して、保 護 対象のリソースへのアクセ
スをコントロールします。
location /admin/ {
deny 10.0.0.1;
allow 10.0.0.0/20;
allow 2001:0db8::/32;
deny all;
}
72
例示のロケーションブロックは、10.0.0.1を除く10.0.0.0/20の任意のIPv4アドレスからの
アクセスを許可し、20 01:0 d b 8::/32 サ ブネット のIPv6アドレスからのアクセスを 許 可し、
他 のアドレス から発 信 され た 要 求 に 対して403を返します。allowおよびdenyディレク
ティブは、HTTP、サーバー、ロケーションコンテキスト、また、TCP/UDPのストリームお
よびサーバーコンテキスト内で有効です。リモートアドレスに一致するものが見つかる
まで、ルールが順番にチェックされます。
解説
インターネット上の貴重なリソースとサービスの保護は、複数のレイヤーで行う必要があ
ります。NGINXの 機 能 は 、そ う し た レ イ ヤ ー の う ち の 1つになる機能を提供します。deny
ディレクティブは、特定のコンテキストへのアクセスをブロックする一方で、allowディレ
クティブは、ブロックされたアクセスのサブセットを許可するために使用できます。IPアド
レス、IPv4またはIPv6、ク ラ ス レ ス ド メ イ ン 間 ル ー テ ィ ン グ（ CIDR）ブ ロ ッ ク 範 囲 、キ ー
ワードall、お よ び Unixソ ケ ッ ト を 使 用 で き ま す 。 通 常 、リ ソ ー ス を 保 護 す る 場 合 、 内 部 IP
アドレスのブロックを許 可し、すべてからのアクセスを拒否する場合 があります。
7.2 クロスオリジンリソース共有の許可
問題
別 のドメイン か らリソースを提 供しており、ブ ラ ウ ザ がこ れ らのリソースを 利 用 で きる
ようにするには、クロスオリジンリソース共有（CORS）を許可する必要があります。
解決法
CORSを有効にするには、requestメソッドに 基づ いてヘッダー を変 更します。
map $request_method $cors_method {
OPTIONS 11;
GET 1;
POST 1;
default 0;
}
server {
# ...
location / {
if ($cors_method ~ '1') {
add_header 'Access-Control-Allow-Methods'
'GET,POST,OPTIONS';
add_header 'Access-Control-Allow-Origin'
'*.example.com';
add_header 'Access-Control-Allow-Headers'
'DNT,
Keep-Alive,
User-Agent,
X-Requested-With,
| 第7章：セキュリティコントロール
73
If-Modified-Since,
Cache-Control,
Content-Type';
}
if ($cors_method = '11') {
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=UTF-8';
add_header 'Content-Length' 0;
return 204;
}
}
}
この例ではたくさんのことが行われていますがmapを 使 用してGETメソッドとPOSTメソッ
ドをグループ化することで要約されています。OPTIONSリクエストメソッドは、このサー
バーのCORSル ール に関してpreflight リクエ ストをクライアントに 返します。CORSに基
づき、OPTIONS、GET、POSTメソッドは 許 可されています。Access-Control-Allow-Origin
ヘッダーを設定すると、このサーバーから提供されるコンテンツを、このヘッダーに一致
するオリジンのページでも使 用できるようになります。プリフライトリクエストは、クラ
イアントに1,728,000秒 、つ ま り 20日間キャッシュできます。
解説
JavaScriptなどのリソースは 、リクエ ストしてい るリソース が そ れ 自 体 以 外 のドメイン の
ものである場合にCORSを作成します。リクエストがクロスオリジンと見なされる場合、
ブラウザはCORSルールに従う必要があります。特に使用を許可するヘッダーがない場
合、ブラウ ザ ー はリソースを 使 用しません 。リソースをそ の 他 の サブドメインで 使 用 で
きるようにするには、CORSヘッダーを設定する必要があります。これはadd_headerディ
レクティブで実行できます。標準コンテンツタイプのGET、HEAD、POSTリクエストのい
ずれ か の 場 合で、リクエストに特 別なヘッダーがない 場 合には、ブラウザはリクエスト
を行い 、発 信元のみをチェックします。他のリクエストメソッドを使 用すると、ブラウ
ザはプリフライトリクエストを実行して、そのリソースについて従うサーバーの条件を
確認します。これらのヘッダーを適切に設 定しないと、そのリソースを利用しようとし
た場合にブラウザでエラーが発生します。
7.2 クロスオリジンリソース共 有の 許可 |
74
7.3 クライアント側 の 暗 号 化
問題
NGINXサーバーとクライアント間のトラフィックを暗号化する必要があります。
解決法
ngx_http_ssl_module やngx_stream_ssl_module などのSSLモジュールを使用してト
ラフィックを 暗 号 化します：
http { # All directives used below are also valid in stream
server {
listen 8443 ssl;
ssl_certificate /etc/nginx/ssl/example.crt;
ssl_certificate_key /etc/nginx/ssl/example.key;
}
}
この構成では、SSL/TLS、8443で暗 号 化されたポートでリッスンするようにサーバーを
設 定 し ま す 。デ ィ レ ク テ ィ ブ ssl_certificateは、証明書と、クライアントに提供される
オ プ ション の チェーンを定 義します。ssl_certificate_keyデ ィ レ ク テ ィ ブ は 、リ ク エ ス
トを復号化し、レスポンスを暗号化するためにNGINXが 使 用するキーを定義します。
多くの SSL/TLSネゴシエーション構成は、デフォルト設定で適用されています。
解説
安全なトランスポート層は、転送中の情報を暗号化する最も一般的な方法です。この記
事の執筆時点では、SSLプロトコルよりもTLSプロトコルが 好まれています。これは、SSL
のバージョン1から3が 安 全ではないと見なされるようになったためです。プ ロトコル名は
異なる場 合 がありますが、TLSは依然として安全なソケット層を確立します。NGINXを
使用すると、サービスでユーザーとクライアント間の情報を保護できます。これにより、
クライアントとビジネスが保護されます。CA署名付き証明書を使用する場合は、証明
書を認証 局チェーンと連 結する必要があります。証明書とチェーンを連結する場合、
証明書は連結されたチェーンファイル上になければなりません。認証局がチェーンの
中 間 証 明 書として 複 数のファイル を 提 供して い る 場 合、そ れらを 階 層 化 する 順 序 があ
ります。その順 序については、証明書プロバイダーのドキュメントを参照してください。
関連項目
Mozilla サーバー側 TLSページ
Mozilla SSL 構成ジェネレータ
SSL構 成テストをSSLラボのSSLサーバーテストで実 行
| 第7章：セキュリティコントロール
75
7.4 クライアント側の暗号化（応用）
問題
高度なクライアントサーバー暗号化構成のニーズがあります。
解決法
NGINXのhttpおよびstreamSSLモ ジ ュ ー ル に よ り 、受 け 入 れ ら れ た SSL/TLSハンドシェ
イクを完全にコントロールできます。証明書とキーは、ファイルパスまたは変数値を介し
てNGINXに提 供 できます。NGINXは、構成ごとに、受け入れられたプロトコル、暗号、
キータイプのリストをクライアントに提 示します。クライアントとNGINXサーバー間の
最高水準がネゴシエートされます。NGINXは、クライアントサーバーのSSL/TLSネゴシ
エーションの結果を一定期間キャッシュできます。
以 下 で は 、ク ラ イ ア ン ト /サーバーネゴシエーションの利用可能な複雑さを説明する目
的 で、一 度 に多くの オプション を意 図 的 に 示しています。
http { # All directives used below are also valid in stream
server {
listen 8443 ssl;
# Set accepted protocol and cipher
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
# RSA certificate chain loaded from file
ssl_certificate /etc/nginx/ssl/example.crt;
# RSA encryption key loaded from file
ssl_certificate_key /etc/nginx/ssl/example.pem;
# Elliptic curve cert from variable value
ssl_certificate $ecdsa_cert;
# Elliptic curve key as file path variable
ssl_certificate_key data:$ecdsa_key_path;
# Client-Server negotiation caching
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
}
}
サーバーは、SSLプ ロトコルバージョン TLSv1.2およびTLSv1.3を受け入れます。受け入れ
られる暗号はHIGHに設 定されます。これは最 高水 準のマクロです。明 示 的な拒 否は!
マークでaNULLおよびMD5に 示されます。
2セットの 証 明 書 とキー の ペ ア が 使 用され ます。NGINXディレ クティブに 渡される値
は、NGINX証明書キー値を提供するさまざまな方法を示します。変数はファイルへ
のパ スとして 解 釈さ れます。data:プレフィックス が 付 いてい る 場 合 は 直 接 値として 解
釈されます。クライアントに下位互換性を提供するために、複数の証明書キー形式が
7.4 クライアント側の暗号化（応用） |
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.