データベース サーバー上の非常に機密性の高いデータにアクセスするアプリケーション サーバー上に小さな Web アプリケーションがあります。SQL 接続を介してこのデータに直接アクセスする代わりに、アプリケーション サーバーのみが使用できるデータベース サーバー上に Web サービス インターフェイスを作成することを考えていました。
私の考えでは、アプリケーション サーバーがハッキングされた場合、データに直接アクセスできなくなるでしょう。ハッカーは別の層 (インターフェース) に対処する必要があり、その時までに私はその状況に対処していたでしょう。
これにより Web アプリケーションに多少の遅延が生じることはわかっていますが、データは機密であるため、これは許容できるトレードオフであると考えています。
このセキュリティの追加の「層」は、本当に私のシステムをより安全にするのでしょうか、それとも何か足りないのでしょうか?
あなたがどこから来たのかはわかりますが、私には少し「隠すことによるセキュリティ」の匂いがするようです。最初の呼び出しポイントは、Webアプリケーションが使用するSQLユーザーが適切にロックダウンされ、必要なデータベースオブジェクトにのみアクセスできることを確認することです。たとえば、読み取りのみが必要なテーブルへの読み取り専用アクセス、書き込みが必要なテーブルへの書き込みアクセス。MS SQLでは、実行アクセス権を狭い範囲のストアドプロシージャに与えるだけで、これをいくらか簡単にすることができます。ユーザーはSPでの実行アクセスのみが必要であり、基になるテーブルへのアクセス許可は必要ありません。これにより、追加の、場合によっては安全でない抽象化レイヤーを使用する代わりに、データベースレベルのセキュリティが利用されます。
すでに提案したように、アーキテクチャにさらに階層を追加することもできますが、私は、独自のセキュリティオプションを導入する前に、すでに利用可能なセキュリティオプションを使用して地上レベルから始めます。
「この時までに状況を処理しただろう」というあなたのコメントは的外れだと思いますが、そうでなければこれは良い考えです. 攻撃者がフロントエンド アプリケーションを侵害した場合、バックエンド レイヤーを強化するための余分な時間が必ずしも与えられるとは限りません。バックエンド層が構成されていた場合、最も可能性の高いシナリオは、フロントエンド層が侵害されたことを発見したと同時にそれを発見することです.
バックエンド レイヤーが役立つ理由は、SQL の全機能ではなく、必要な機能のみをフロント レイヤーに公開するためです。また、多層防御であるため、攻撃者は 2 種類のエクスプロイトを見つけて同時に使用し、両方のレイヤーを通過する必要があります。
ここでは、標準の 3 層アーキテクチャを実際に使用したいと考えています。Web サーバー (ビジネス/アプリケーション ロジックなし) をフロントエンドとして配置します。静的コンテンツのみ。接続を許可されているファイアウォール (および特定のアプリケーション サーバーのみ) を介して、アプリケーション サーバーに接続する必要があります。次に、そのアプリケーション サーバーのみがデータベース サーバーと通信できるようにします。
インターネット -> ファイアウォール -> Web サーバー -> ファイアウォール -> アプリケーション サーバー -> データベース
誰かがあなたの Web サーバーをハッキングします。アプリケーションはすべてアプリケーション サーバー上に存在するため、アプリケーションに関連するものは何も得られません (そうです、彼らはそれに接続できますが、少なくとも速度を低下させるはずの定義されたインターフェイスを使用するだけです)。アプリケーション サーバー上にある場合でも、データベースへのインターフェイスを作成する必要があります。これは、このタイプのアプリケーションの標準的なセキュリティ アーキテクチャです。