データベースの読み書きユーザーを分離することは、良いセキュリティ実践ですか？

Question

コードの一部でSQLインジェクションが発生しがちな場合、少なくとも誰でもデータベースに書き込むことはできません。万一、全面的な書き込みアクセスを持たないフロントエンドを使用しているのであれば、

Answer 1

はい、私は、ユーザーがサイトを使用するために必要な最低の特権しか許可しないアカウントを使用して接続することをお勧めします。あなたのWebユーザーがデータベースからデータを読み取るだけであれば、私は間違いなく読み取りアクセス権を持つアカウントを作成し、それを介してDBにアクセスさせます。

さらに重要なことは、Webアプリケーションを保護することです。ユーザーがデータベースに書き込まなくても（盗難されたクレジットカード番号やパスワードを考えても）、SQLインジェクション攻撃の犠牲になることがあります。

Answer 2

一般的に、アプローチは実際にはユーザー自身ではなく、異なる役割を持つことです。 SQLインジェクション攻撃に関しては、私が提案しているこのアプローチを通して問題を緩和するのではなく、問題を完全に解決することに集中します。

Answer 3

はい、ただし、データベースインターフェイスと表面積を制御するのに役立つ設計テクニックがたくさんあります。

コードでは、通常、特定のセッション（読み取りと書き込み）でのすべての操作で同じログインが使用されると仮定する必要があります。しかし、ユーザーが書き込みユーザーでない場合、セッションに使用されるログインには書き込み権がないはずです。

SQLインジェクションにさらされる表面積を減らすための良い方法の1つは、そのアカウントが最初に直接テーブルを更新できるようにすることではありません。

たとえば、格納されたprocsを介した書き込みアクセスでは、発生する可能性がある唯一の注入は、適切なパラメータでこれらのプロシージャを実行することです。

Answer 4

ほとんどの場合、これは過剰ですが、ほとんどの場合、SQLインジェクションを受けにくいパラメータ化されたクエリを使用する必要があります。

ストアドプロシージャと、プロシージャを呼び出すことができ、クエリを直接実行しないユーザーアカウントを使用することを検討してください。

直接クエリを使用する必要があり、何らかの理由でパラメータを使用できない場合は、可能であればデータベースからのみ読み取れるユーザーアカウントが必要です。

Answer 5

はい。 AbeとCade Rouxの優れた回答に加えて、セキュリティ監査者が攻撃後に優先順位をつけ、法医学をより簡単にするのに役立ちます。

セキュリティ監査をより多くの特権を使用するコードに集中させることができます。読み取り権限が必要なコードよりも書き込み権限が必要なコードを監査するのに時間を費やすことができます。

ロールの分離というもう1つの優れた特性は、フォレンジックスをより簡単にすることです。分離した役割があり、DBログの攻撃を識別できる場合、悪用された可能性のあるコードを絞り込むことができます。ログ内の攻撃に関連付けられた役割を使用するコードのみを絞り込むことができます。

Answer 6

ボビー・テーブルのその愚かな漫画からSQLインジェクションのあなたの考えが来ているようです。
しかし、実際には、データベースからの読書だけが書面よりも悲惨なことがあります。

また、実生活で使っていた「いいやり方だ」と言われたいい人はいないという強い気持ちがあります。言う、フロントエンド（実際には、想像上の人生ではない）も書き込みアクセス権を持っている必要があります。

あなたは間違った木を吠えています。
SQLインジェクションが発生しやすいコードの一部がある場合 - これらのパーツを正しく修正してください。それが唯一の純粋な解決策です。