個々のユーザーが1つのアプリケーションを使用しているときに、自分のデータベースユーザー/パスワードを取得する必要がありますか？

Question

私が尋ねようとしていることは...

ユーザーは自分のアプリケーションを介してデータベースにアクセスします。アプリケーション自体により、管理ユーザーはユーザーを作成/変更/削除し、特定の特権を与えることができます。だから、私は各ユーザーのログイン名&パスワードを含むテーブルがあります。

私はまだアプリケーションを開発中ですので、現在はパスワードなしでrootとしてログインしています。明らかに、私はそれを変えますが、ベストプラクティスは何ですか？アプリケーションで使用する単一のデータベースユーザー&パスワードを使用するか、アプリケーションのユーザーを作成（または変更）するたびにdatabaseの別のユーザーを作成する必要がありますか？後者はもっと仕事のようです。

Answer 1

ユーザーごとにデータベースログインを作成する必要はありません。これは、ユーザーではなく、データベースとやりとりするアプリです。余分なログインを作成するだけで、データベースの安全性が大幅に低下します。

Answer 2

短い回答：インターネットの前には、はい。インターネットの後：誰もそれをしませんが、それはまだ完全に受け入れられています。

インターネット時代には、アプリケーションをユーザーとみなし、そのアプリケーションにログインすることが一般的に行われています。実際の唯一の利点は、接続プーリングによるパフォーマンスの向上です。知覚されるが幻想的な利点はセキュリティである。

セキュリティアングルを理解するには、最終的にすべてのセキュリティがどのテーブル、行、列から読み書きできるかを解決する必要があります。これがどのように機能するかを確認するには、安全性の高いテーブルを操作する権限を持つユーザーと、そのテーブルを参照できないユーザーを考えます。権限の低いユーザーは、セキュアなテーブルを消去しようとするSQLインジェクション攻撃を正常に管理しますが、データベースがそのユーザーによるそのテーブルへのアクセスを禁止するため、失敗します。

接続プールが重要な場合を除いて、1回のログインを使用する技術的な理由はないということです。データベースは、多くのインターネット時代のプログラマによって非常によく理解されていないので、組み込みのセキュリティの使い方を説明することは、多くの先入観や誤ったアイデアとの闘いです。

Answer 3

アプリケーションには、ユーザーごとに個別のユーザーIDとパスワードが必要です。そのため、アプリケーションがデータベースと通信するときに複数のユーザーIDを持つ必要はありません。アプリケーションのセキュリティが正しく実装されている限り、複数のDBユーザーIDを持つことによる利益はありません。

それぞれのユーザに自分のDBユーザIDを与えることは、あらゆる種類の特殊なケースや例外を含む可能性があるため、確かに巨大な痛みになります。たとえば、アプリケーションにログインするには、アプリケーションはユーザーのIDとパスワードを検証する必要があります。ユーザーがパスワードテーブルにアクセスできない場合はどうすればよいですか？しかし、不正なアクセスから何かを保護する必要がある場合は、それがパスワードテーブルです。したがって、ログインを行うために1つのユーザーIDを使用し、それを取り出して別のユーザーIDを与える必要があります。特定のユーザーがあるコンテキストではアクセスできるが、別のコンテキストではアクセスできない可能性がある他のテーブルが存在する可能性があります。会計部門は、年間の給与で支払われた総額を見なければならない可能性がありますが、個々の従業員の給与を見ることはできません。従業員は、自分の利益についてのデータにアクセスできますが、他の従業員のデータにはアクセスできない可能性があります。その他

私がこれに考えることのできる唯一の例外は、データベースへの一般的なアクセスを許可した場合です。最も極端な場合は、ユーザが任意のSQLクエリを入力して実行できる画面があれば実行します。その場合、理論的にはアプリケーションがクエリを分析してセキュリティルールを適用しようとすることもできますが、アプリケーションではSQLに関する非常に多くの知識を埋め込む必要があります。その場合は、各ユーザーに自分のDBユーザーIDを与え、セキュリティルールをデータベースエンジンに入れる方がよいでしょう。