ほとんどの場合、Web アプリケーション サーバーはパブリックにアクセスできる必要があります。これは、Web アプリケーション サーバーがあらゆる種類の脅威にさらされていることを意味します。
これらの脅威の多くは予測可能で簡単に回避できますが、未知の脅威もあり、不意を突かれる可能性があります。後者のケースの可能性を最小限に抑えるために、Web アプリケーション サーバーを可能な限り安全に保つための重要なヒントのリストを提供します。
ヒントのリストを始める前に、Web アプリケーション サーバーは独立した島ではないことを理解する必要があります。サーバーは、Web アプリケーションのホスティングと操作を可能にする Web アプリケーション ファームの中心的なコンポーネントです。したがって、セキュリティを確保するには、それを囲むすべてのコンポーネントを考慮し、Web アプリケーション環境全体をセキュリティで保護する必要があります。
Web アプリケーションをホストして実行するための基本的な環境には、オペレーティング システム (Linux、Windows)、Web サーバー ソフトウェア (Apache、Nginx)、データベース サーバーが含まれます。これらのコンポーネントのいずれかが侵入されると、攻撃者がアクセスを取得し、必要なすべての悪意のあるアクションを実行する可能性があります。
上で説明したような環境を保護するための最初の基本的なヒントは、各コンポーネントのセキュリティ ガイドラインとベスト プラクティス リストを読むことです。そうは言っても、ほぼすべての Web アプリケーション環境に適用される、いくつかの常識的なセキュリティ ガイドラインを確認してみましょう。

ファイアウォールの謎を解き明かす
「幸運なことに、ネットワークを保護するファイアウォールがすでにある」と考えて、この項目をすぐにチェックしたくなるかもしれません。でも、馬は抱いたほうがいいよ。
ファイアウォールはネットワークの境界を管理し、悪者を締め出し、善良な者を中に入れているかもしれませんが、攻撃者が Web アプリケーション サーバーに侵入するための扉を大きく開いたままにしていることは確かです。
どうやって?
シンプル: ネットワーク ファイアウォールは、少なくともポート 80 と 443 (つまり HTTP と HTTPS) での受信トラフィックを許可する必要があり、誰が、または何がこれらのポートを通過しているかを知りません。
アプリケーションを保護するために必要なのは、特に Web トラフィックを分析し、クロスサイト スクリプティングやコード インジェクションなどの脆弱性を悪用する試みをブロックする Web アプリケーション ファイアウォール (WAF) です。 WAF は、一般的なウイルス対策やマルウェア対策と同様に動作します。データ ストリーム内の既知のパターンを検索し、悪意のあるリクエストを検出するとブロックします。
WAF を効果的に機能させるには、新しい脅威パターンをブロックできるようにデータベースを常に更新しておく必要があります。パターンベースの攻撃防御の問題は、Web アプリケーションが、WAF がまだ認識していない新しい脅威の最初のターゲットの 1 つになる可能性があることです。
これらの理由から、Web アプリケーションにはネットワーク ファイアウォール以外に追加の保護層が必要です。

Web 固有の脆弱性をスキャンします。
繰り返しになりますが、ネットワーク セキュリティ スキャナーがそう判断したからといって、Web アプリケーション サーバーに脆弱性がないと考えないでください。
ネットワーク スキャナーはアプリケーション固有の脆弱性を検出できません。これらの脆弱性を検出して排除するには、アプリケーションを一連のテストと監査 (侵入テスト、ブラック ボックス スキャン、ソース コード監査など) にかける必要があります。ただし、これらの方法はどれも完璧ではありません。理想的には、すべての脆弱性を排除するために、それらをできるだけ多く実行する必要があります。
たとえば、 Invicti のようなセキュリティ スキャナーは、悪用可能なコードが運用環境に侵入しないようにします。ただし、手動のコード監査によってのみ検出できる論理的な脆弱性が存在する可能性があります。手動監査は多大なコストがかかるだけでなく、人間が行うためエラーが発生しやすい方法です。多額の費用を無駄にすることなくこの種の監査を行うための良いアイデアは、主に開発者を教育することによって、開発プロセスに監査を組み込むことです。

開発者を教育する
開発者は、リソースが無制限で、ユーザーが間違いを犯さず、冷酷な意図を持つ人々が存在しない理想的な世界でアプリケーションが実行されると考える傾向があります。残念ながら、ある時点で、彼らは現実世界の問題、特に情報セキュリティに関する問題に直面する必要があります。
Web アプリケーションを開発する場合、プログラマーは脆弱性がないことを保証するセキュリティ メカニズムを理解し、実装する必要があります。これらのセキュリティ メカニズムは、開発チームが準拠する必要があるベスト プラクティス ガイドの一部である必要があります。
ソフトウェア品質監査は、ベスト プラクティスへの準拠を保証するために使用されます。ベスト プラクティスと監査は、論理的脆弱性を検出する唯一の方法です。たとえば、URL 内で暗号化されていない可視パラメータを渡すなど、攻撃者が意図したとおりに簡単に変更できる可能性があります。

不要な機能をオフにする
Web アプリケーションに可能な限りエラーがなく、Web ファームが保護されていると仮定して、サーバー自体を攻撃から保護するためにサーバー自体で何ができるかを見てみましょう。
基本的で常識的なヒントは、潜在的に脆弱なエントリ ポイントの数を減らすことです。攻撃者が Web サーバーのコンポーネントのいずれかを悪用できる場合、Web サーバー全体が危険にさらされる可能性があります。
サーバー上で開いているすべてのポートと実行中のサービスまたはデーモンのリストを作成し、不要なものを閉じる、無効にする、またはオフにします。サーバーは Web アプリケーションの実行以外の目的には使用しないでください。そのため、すべての追加機能をネットワーク内の他のサーバーに移動することを検討してください。

開発、テスト、運用に別々の環境を使用する
開発者とテスターは、作業する環境に対して、ライブ アプリケーション サーバーでは持つべきではない権限を必要とします。たとえ盲目的に信頼していたとしても、パスワードは簡単に漏洩し、望ましくない手に渡る可能性があります。
開発およびテスト環境には、パスワードと権限に加えて、通常、データベースのユーザー名やパスワードなどの機密データが公開される可能性のあるバックドア、ログ ファイル、ソース コード、またはその他のデバッグ情報が存在します。 Web アプリケーションの展開プロセスは管理者が実行する必要があります。管理者は、アプリケーションをライブ サーバーにインストールした後、機密情報が漏洩しないようにする必要があります。
同じ分離概念をアプリケーションのデータに適用する必要があります。テスターや開発者は常に実際のデータを操作することを好みますが、本番データベースやそのコピーへのアクセスを許可するのは得策ではありません。明らかなプライバシー上の懸念に加え、データベースには、エンドポイント アドレスやパス名などの内部サーバー設定を明らかにする構成パラメータが含まれている可能性があります。
サーバー ソフトウェアを常に最新の状態に保つ
当たり前のように思えるかもしれませんが、これは最も見落とされているタスクの 1 つです。 SUCURI は、CMS アプリケーションの 59% が古いものであり、リスクにさらされていることを発見しました。
新しい脅威は毎日出現します。それらによるサーバーの危険を防ぐ唯一の方法は、常に最新のセキュリティ パッチをインストールすることです。
ネットワーク ファイアウォールとネットワーク セキュリティ スキャナーだけでは、Web アプリケーションへの攻撃を防ぐのに十分ではないことは前に述べました。ただし、DDoS 攻撃などの一般的なサイバーセキュリティの脅威からサーバーを保護するためには必要です。したがって、そのようなアプリケーションが常に更新され、ビジネス アプリケーションが効果的に保護されていることを確認してください。
アクセスと権限を制限する
基本的なセキュリティ対策は、RDP や SSH などのリモート アクセス トラフィックを暗号化してトンネリングし続けることです。また、リモート アクセスが許可されている IP アドレスの限定リストを保持し、他の IP からリモートでログを記録しようとする試みが確実にブロックされるようにすることもお勧めします。
管理者は、そうすることで「すべてが機能する」とわかっているため、サービス アカウントに可能なすべての権限を与えることがあります。ただし、攻撃者がサービスの脆弱性を利用してサーバーに侵入する可能性があるため、これは良い習慣ではありません。これらのサービスが管理者権限で実行されている場合、サーバー全体が占有される可能性があります。
セキュリティと実用性のバランスを適切に保つには、各アカウント (ログイン アカウントとサービス アカウントの両方) が、そのジョブの実行に必要な権限だけを持っている必要があります。
たとえば、管理者がさまざまなタスク (バックアップの作成用、ログ ファイルのクリーンアップ用、サービスの構成の変更用など) を実行するためのさまざまなアカウントを定義できます。同じことがデータベース アカウントにも当てはまります。通常、アプリケーションにはデータの読み取りと書き込みの権限のみが必要で、テーブルの作成や削除は必要ありません。したがって、実行する必要があるタスクを実行するために制限された権限を持つアカウントで実行する必要があります。
サーバーのログに注意してください
ログ ファイルが存在するのには理由があります。
管理者は定期的に監視し、損害が発生する前に不審な動作を検出する必要があります。ログ ファイルを分析すると、アプリケーションの保護を強化するために役立つ多くの情報が明らかになります。攻撃が発生した場合、いつどのように攻撃が開始されたのかがログ ファイルに記録されるため、より適切なダメージ コントロールを行うことができます。
また、古いログ ファイルを削除したり、古い情報を削除したりして、サーバー内の利用可能な記憶領域がすべて消費されるのを防ぐための自動手順も必要です。
おまけのヒント: 常に最新の情報を入手してください
インターネット上には、Web アプリケーションの利益のために使用できる、無料で役立つ情報がたくさんあります。評判の良いセキュリティ ブログ (このブログなど) の新しい投稿を見逃さず、セキュリティと Web 業界で何が起こっているかについての最新情報を入手してください。
チュートリアル 、コース、ビデオ、書籍も役立つ知識の源です。業界ニュースを常に把握するために週に 1 ~ 2 時間を費やす練習をしてください。そうすることで、アプリケーションのセキュリティを維持するために正しいことを行っているという安心感が得られます。