ほとんどのFOSSアプリケーション(Wordpressなど)は、すべてのアクセス許可が付与された単一のデータベース資格情報セットのみを使用していることに気付きました。これは、最小特権の原則に違反しているようです。
このようなアプリケーションを作成する際には、複数のアカウントを使用する方がよいでしょうか。たとえば、SELECTクエリ専用のアカウント、UPDATE専用のアカウントなどです。
ほとんどのFOSSアプリケーション(Wordpressなど)は、すべてのアクセス許可が付与された単一のデータベース資格情報セットのみを使用していることに気付きました。これは、最小特権の原則に違反しているようです。
このようなアプリケーションを作成する際には、複数のアカウントを使用する方がよいでしょうか。たとえば、SELECTクエリ専用のアカウント、UPDATE専用のアカウントなどです。
これは間違いなく最小特権の原則の違反です。定義に戻りましょう:
情報セキュリティ、コンピュータサイエンス、およびその他の分野では、最小特権の原則または最小特権の原則とも呼ばれる最小特権の原則では、コンピューティング環境の特定の抽象化レイヤーで、すべてのモジュール(プロセス、ユーザーまたは私たちが検討しているレイヤーに基づくプログラム)は、その正当な目的に必要な情報とリソースにのみアクセスできなければなりません。
Wordpressの例では、パブリックユーザーがSQLアカウントを使用してデータベースからデータを取得しています。このアカウントには、そのデータを変更または削除する機能もあります。このユーザーの「最小特権」には、データがストアドプロシージャを介してテーブルに直接あるかどうかに関係なく、そのデータを変更するためのアクセス権は含まれません。これは、 「正当な目的に必要な情報やリソースのみにアクセスする」ことには絶対に準拠していません。
SQL環境でのリスクは、主にSQLインジェクションです。1つの小さな欠陥があり、そのパブリックアカウントに損害を与える権利がある場合は、あらゆる種類の問題が発生します。はい、入力を検証する必要があります。はい、クエリをパラメータ化する必要がありますが、これは追加の保険を提供する1つの追加の防御層です。
これについては、OWASP Top 10 for .NET開発者パート1:インジェクションで具体的に説明します。
メンテナンスの問題だけであれば、もっと悪いと思います。1 人のユーザーとは、資格情報が 1 か所にあり、正確に 1 か所でサーバーごとに更新できることを意味します。さらに、ほとんどのフレームワークは、1 つの資格情報セットがすべてを支配することを想定して動作します。
選択のみの権限を持つユーザーが 1 人いる場合、SQL インジェクションについてそれほど心配する必要がないという利点があります (確かにBobby Tablesレベルではありません) が、それでも保証されないので、とにかく、データ入力をサニタイズする必要があります(選択に基づいてインジェクション攻撃を行う可能性があります...)。
ベスト プラクティスは、テーブル レベルではなくストアド プロシージャに権限を付与することです。