HTTPの公開をアプリケーション実行および永続データから分離してください。リバースプロキシはルーティングと制限を整理できますが、オリジンアクセス、アプリケーション認可、アップストリーム容量、リカバリにはそれぞれ独自の制御が必要です。
Webリクエストは複数の責任を横断します
WebサーバーはHTTPリクエストを受信し、静的ファイルを提供できます。アプリケーションプロセスは、アカウントの確認やデータベースへのクエリなど、プロジェクトの動的な動作を実行します。リバースプロキシはそのプロセスに代わってリクエストを受信し、アップストリームに転送します。1つのプログラムが複数の役割を果たすこともありますが、責任を分離することで構成とリカバリの推論が容易になります。
ホスト名解決から応答までの1つのリクエストを追跡してください。TLSがどこで終了するか、どのプロセスがルートを選択するか、どのコンポーネントがアプリケーションデータを読み取れるかを記録します。管理リクエストについても同様に行います。この演習は、テスト用に作成され誤って到達可能なままになっているリスナーやホスト名をしばしば明らかにします。図は、構築を望んだアーキテクチャではなく、展開された経路を記述すべきです。
エッジを使用してHTTPの動作を整理する
NGINXは、静的コンテンツの提供とアップストリームへのリクエスト転送の両方を文書化しています。そのワーカーアーキテクチャとHTTPモジュールは構成メカニズムを提供しますが、特定の構成が動作を決定します。ホスト名、アップストリーム、ファイルシステムルートを意図的に定義してください。構成、資格情報、リポジトリメタデータがアプリケーションの近くにあるという理由だけでダウンロード可能にならないよう、提供できるファイルを制限してください。
アプリケーションに応じて、リクエストボディ、タイムアウト、接続に適切な制限を設定してください。キャッシュはデータの決定として扱います。ユーザーや権限に紐づくコンテンツは、レビューなしに共有キャッシュルールを安全に継承できません。認証とキャッシュの動作を一緒にテストしてください。再現可能な構成を維持し、サービスをリロードする前に変更を検証し、以前の動作バージョンに戻る既知の経路を確保してください。
| 層 | 有用な責任 | 起動前に確認する |
|---|---|---|
| パブリックWebエッジ | TLS、ホスト名ルーティング、HTTP制限 | 証明書、ルート、意図されたホスト名 |
| アプリケーションプロセス | ビジネスロジックと認可 | 認証、入力チェック、依存関係の障害 |
| 内部データサービス | 永続的なアプリケーション状態 | 制限されたアクセスとテスト済みの復元 |
| アップストリームプロバイダーネットワーク | 契約されたネットワークサービス | 保護範囲とエスカレーション経路 |
リバースプロキシはオリジンの露出を排除しません
オリジンが公開されたままの場合、クライアントは意図されたプロキシ経路を使用せずに到達できる可能性があります。展開がその境界を必要とする場合は、ネットワーク設計とアプリケーション構成を通じてオリジンアクセスを制限してください。1台のマシンでは、バックエンドは多くの場合ループバックまたはローカルソケットでリッスンできます。マシン間では、明示的な制限付きルートとアップストリーム接続に適した保護を使用してください。
転送ヘッダーにも信頼ルールが必要です。元のクライアントに関する情報は、信頼された仲介者からのみ受け入れ、任意の呼び出し元がアプリケーションが権威あるものとして扱う値を提供するのを防いでください。アクセスログとエラーレポートに何が表示されるかを決定します。プロキシは各層で利用可能な情報を変更できますが、アカウント識別子を消去したり、アプリケーションを自身のオペレーターに対して匿名にしたりはしません。
アプリケーション内でアクセス決定を適用する
NISTのゼロトラストアーキテクチャは、ネットワーク位置だけに基づく暗黙の信頼ではなく、リソースへのアクセス決定に焦点を当てています。その原則を具体的に適用してください。呼び出し元を認証し、要求された操作を認可し、サービスアカウントには必要なスコープのみを与えます。内部サブネットから到着したリクエストが自動的に管理者リクエストになるべきではありません。
実用的な場合は、パブリック機能と管理機能を分離してください。ユーザーがレコードにアクセスする際は、最初のログインだけに依存するのではなく、権限を再確認します。プロキシ、アプリケーション、データベースの資格情報は別々に保ってください。変更はテスト可能な段階で導入し、狭い機密経路から始めます。展開をゼロトラストと呼ぶことは、禁止されたアクションが実際にその責任を負うコンポーネントで拒否されることを実証するよりも有用ではありません。
複数の層でサービス拒否を計画する
飽和したネットワークリンクと高コストなアプリケーションリクエストは、異なる場所で失敗します。Webエッジでのレート制限はリクエストパターンの制約に役立つ場合がありますが、アプリケーションの制限は検索、アップロード、エクスポートなどの作業を制限できます。NGINXのリクエスト制限モジュールは1つのメカニズムを提供します。キーとしきい値は実際のユーザーに適合し、正当なトラフィックを拒否しないようテストする必要があります。
OWASPのサービス拒否ガイダンスは、アプリケーション動作におけるリソース枯渇にも対処しています。高コストな作業には時間とサイズの制限を設け、有界キューを使用し、障害シグナルを監視してください。ローカル制御は、すでに飽和しているアップストリームリンクに容量を生み出すことはできません。選択したオファーに含まれる特定のネットワーク保護を確認し、エスカレーション経路を準備してください。カタログのレイヤー3～4保護が、すべてのHTTPワークロードの保護も証明すると決して仮定しないでください。
リカバリを公開の一部にする
意図されたホスト名を使用して、外部クライアントからサイトを確認してください。HTTPS、リダイレクト、静的リソース、ログイン、代表的なアプリケーショントランザクションを検証します。管理リスナーとプライベートファイルがアクセス不能なままであることを確認してください。停止したアップストリームをシミュレートし、エッジが内部詳細を露出したり無制限に待機したりするのではなく、制御された失敗を返すことを確認します。
Canvasの場合、ホスティングアカウント内で利用可能な制御を確認してください。VPSの場合、Webエッジとアプリケーションを自身の運用計画の一部として維持してください。大きなネットワークポートは容量仕様であり、アプリケーションがそのスループットを維持できる証明ではありません。監視、復元、プロバイダーの連絡先をランブックに含めてください。実際のリクエスト経路と実用的なリカバリ経路が検証された後にのみ公開してください。
実践チェックリスト。
- パブリックリクエストと管理リクエストを追跡してください。
- 提供されるルートとアップストリームリスナーを定義してください。
- 承認された仲介者からのみ転送ヘッダーを信頼してください。
- 認可とキャッシュの境界をテストしてください。
- ネットワークとアプリケーションの障害に対する制限とエスカレーションを準備してください。
重要な詳細。
Webサーバーはリバースプロキシとしても機能できますか？+
はい。NGINXは文書化された一例です。その役割は構成に依存し、アプリケーションには依然として独自の認可とメンテナンスが必要です。
リバースプロキシは自動的にオリジンを隠しますか？+
いいえ。ルーティング、ファイアウォール、リスナー設定が意図された境界を強制しない限り、オリジンは到達可能なままである可能性があります。
リクエスト制限はすべてのDDoS攻撃を停止しますか？+
いいえ。選択されたHTTPリクエストパターンに対処します。ネットワーク飽和やその他のリソース障害には、適切なアップストリームとアプリケーションの制御が必要です。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- NGINX：初心者ガイド nginx.org
- NGINX：HTTPリクエスト制限 nginx.org
- NIST SP 800-207：ゼロトラストアーキテクチャ nvlpubs.nist.gov
- OWASP：サービス拒否の防止 cheatsheetseries.owasp.org
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。