Webアプリケーションは、アプリケーションサーバーを介してデータベースに接続されている方が安全ですか？

Question

同僚や他のWeb関係者から、この構成を実行する方が安全であるとのことです。

Web server -> Application server -> Database、これより：

Web server -> Database

攻撃者がWebサーバーを制御する場合、データベースが必要な場合に克服すべきレイヤーがもう1つある理由。

攻撃者がWebサーバーを制御している場合、それらはデータベースへの完全なアクセス権を持っているのと同じくらい良いと思います。なぜなら、彼らはそれらを信頼するアプリケーションサーバーへの任意の要求を実行できるからです。それは私が推測するそれらを遅くしますが、中間層を実装するための余分な努力+それによって導入されたアプリケーションのすべての可能な穴は私にとって努力の価値がないようです。

追伸私の質問は一般的なものであると言われたので、私は私が持っているセットアップについてさらに情報を追加します。

APIとのみ通信するSPAクライアントがあり、トークンが認証スキームとして使用されています。 Webアプリケーションは、実際にはアプリケーションをフックするための最初のリクエストのみを提供し、静的ファイルとAPI以外の呼び出しはありません。次に、Webアプリケーションはデータレイヤーのデータベースと直接通信します。データベースにユーザーが1人しかいない場合、すべてのアクセスはビジネスロジックやフレームワークの承認レイヤーによって制御されます（たとえば、トークンのロールは、ビジネスレイヤーに進む前に属性で確認できるため、必要なロールがなくても、一部のAPIへのアクセスはまったく許可されていません）。したがって、APIを呼び出す人に危険はありません（私が適切にAPIを保護できない場合を除きますが、それは別の話です）。

したがって、この設定を考慮に入れると、データベースの代わりにビジネスロジックを処理するアプリケーションサーバーとWebアプリケーションのデータレイヤーが直接通信するようにすると、セキュリティの観点からメリットがあります（アプリケーションサーバーはデータベースと通信します））。この場合、Webアプリケーションは通常、クライアント+アプリケーションサービスへのプロキシの初期ロードに削減されます。

paj28 · Accepted Answer

"より安全"は非構築的です

何かが「より安全」であると考えることは、しばしば不十分な意思決定につながります。あらゆるものは悪い考えでありながらより安全です。「これは意味のあるセキュリティを追加しますか？」と尋ねる方が便利です。そして「セキュリティはコストと利益の間で妥当なトレードオフを得ましたか？」

層はそれほどセキュリティを追加しません

ほとんどのinfosecブックは3層モデルを推奨しています。 2層モデルも同じように一般的（おそらくより一般的）であることがわかりました。これには、私が監査した非常に重要なアプリ（オンラインバンキングなど）が多数含まれています。

現実には、2つの層を持つことは、単一の層よりもわずかなセキュリティ上の利点にすぎません。「Webサーバーがハッキングされている場合、データベースにはない」とよく言われます。技術的には真実ですが、それは誤解を招くものです。 Webサーバーにはデータベースに接続するための資格情報があり、攻撃者はすべてのデータを抽出できます。 2つの層がある特定のエクスプロイトベクトルをブロックする特定の攻撃シナリオを想像できますが、これらはまれです。

3層と2層のセキュリティ上の利点は、2対1未満です。これは特に、Web層がクライアント上にあるSPAの場合に当てはまります。

編集明確にするために、純粋に論理的な分離ではなく、個別のサーバー（仮想または物理）上の層のような層を意味します。

Steffen Ullrich · Answer

Webサーバー、アプリケーションサーバー、データベースを区別する場合は、実際にはフロントエンド、ビジネスロジック、およびバックエンド（ストレージ）を意味します。これは、プレゼンテーション層、アプリケーション層、およびデータ層を備えた多層アーキテクチャとも呼ばれます。この場合、アプリケーションサーバーはWebサーバーからの要求を単に通過するのではなく、ビジネスロジックに適合するアクションのみを許可します。つまり、すべてのセキュリティ（つまり、誰が何にアクセスできるか）は基本的にアプリケーションサーバーで行われ、WebサーバーはWebブラウザーを介してこの情報にアクセスできるようにするためのものです。

代わりにWebサーバーとデータベースしかない場合、ビジネスロジックは基本的にWebサーバーの一部です。これにより、多くの場合、一部のWebアプリケーションでの起動が容易になりますが、プレゼンテーションとビジネスロジックの違いが見つかると、簡単に混乱してしまい、誰も理解できなくなり、ビジネスロジックを迂回して、データベースに直接アクセスできるようになります。アタッカー。

レイヤー間の分離は、必ずしも別のサーバーまたはアプリケーションで行う必要はありませんが、プロセス内の分離（つまり、API、クラスなど）にすることもできます。ただし、この分離は単純にバイパスできないので、別のプロセスまたはサーバーでより安全に処理できることが重要です。特定の情報にHTMLでアクセスできないが、JSONまたはXML APIで引き続きアクセスできるという点で、プレゼンテーションとアプリケーションの分離が見られないことがあります。

Philipp · Answer

ほとんどの*データベースシステムでは、複数のユーザーを処理するのに十分細かい権限の処理が許可されていないため、フィルターとしてアプリケーションレイヤーが必要です。

通常*異なる読み取り/書き込み権限を持つユーザーを作成できますが、通常*これらは数十人までのユーザー向けに設計されており、数千人または数百万人のユーザーに対してはうまく拡張できません。また、通常、権限を設定できるのはテーブルレベルのみです。行ごとのレベルではなく、フィールドごとのレベルだけを設定できます。

つまり、ユーザーが表示できるデータと表示できないデータ、およびユーザーが編集できるデータとできないデータを制御することは困難です。例として、これらの列を持つユーザー表を見てみましょう

userId password profilePicture createdDate lastLoggedInDate

人々は自分のprofilePictureを変更することを許可されるべきですが、他の人々のそれを許可されるべきではありません。誰もcreatedAtフィールドを変更してはいけません。userIdを変更すると、あらゆる種類のハイジンクが発生する可能性があります。すべてのユーザーは、ログイン時にlastLoggedInDateを編集して現在の日付に設定する必要がありますが、異なる日付には設定しないでください。データベースはこの複雑さを処理できますか？ああ、テーブル間の参照についてはまだ話していません。

まあ、でも、ユーザーがすべきでないことをするGUIコードを書かないだけで、クライアント層でこれを単純に禁止するとどうなるでしょうか。問題は、データベースに、クライアントアプリケーションが実際に作成したプログラムであることを確認する方法がないことです。 SQLを話し、有効なログイン資格情報を送信すると、データベースはそれを信頼します。悪意のあるユーザーが独自のクライアントを作成し、データベースに任意のSQLコマンドを送信する可能性があります。

_{*それをすべて実行できるデータベースが存在するのは不可能だとは言いたくありませんが、今のところ見たことはありません。知っている場合は、コメントしてください。}