2

MySQLを使用して開発しているWebアプリで行レベルのセキュリティをエミュレートしようとしています。

この方法の使用：必要なテーブルを使用してデータベースを作成します。このデータベースには、テーブルの列に適切なインデックスを付けて、すべてのユーザーに関連するデータが格納されます。

ユーザーIDに基づいて特定のユーザーにmysqlの「ビュー」を作成します。

行レベルのセキュリティを実現するには、すべてのユーザーにmysqlアカウントを作成し、ビューに「grant」権限を設定する必要があります。

Webインターフェイスには、PHPベースのMVCフレームワークが使用されます。

しかし、私の調査によれば、次のようになります。

1] Having separate mysql account per user "make the webapp less secure".
2]Having separate mysql account per user "increases the disk I/O".

質問：
1] How does creating mysql user per webapp user make the webapp less secure?
2] Does the disk I/O increase considerably?
3] Is there a better way to implement row-level-security in MySQL?
4]What are the pros/cons of implementing row-level-security by the above method?

行レベルのセキュリティを検討しているのはなぜですか？
I need row level security because there are rows which will be shared between multiple users & have 1 or 2 owners to it. Only these owners can delete/modify them.

4

2 に答える 2

0

質問3の答え：

個別のテーブルを使用することで、より簡単なアプローチが可能になります。性能的にも良いかもしれません。同じテーブルにデータを保持したい理由はありますか? 私が理解したように、行はユーザー間で共有されません。

于 2011-11-28T20:42:17.067 に答える
0

私の意見:

1] How does creating mysql user per webapp user make the webapp less secure?

データベースへのエントリ ポイントは複数あります。これはusers、ユーザーの情報を格納するテーブルを用意し、適切に制限された mysql アカウントをすべてのユーザーが (Web アプリの構成ファイルの一部として) 使用することとは異なります。

2] Does the disk I/O increase considerably?

あなたが読んだかもしれない記事は、directlyあなたのデータベースにアクセスする開発者/データベース管理者/その他が使用する複数のSQLアカウントに関するものだったので、これに適切に答える方法がわからない..

3] Is there a better way to implement row-level-security in MySQL?

MySQL の実装で SQL 関数とビューの両方を使用すると、SQL アカウント レベルからではなく、テーブル データを介したユーザー アクセスでアクセスを制御することができますか?

4] What are the pros/cons of implementing row-level-security by the above method?

複数のアカウントを持つことの結果である 1 つのことは、アカウントの維持です。

ビュー、関数、およびストアド プロシージャを使用することは、訪問者に表示できるデータの量または種類を制御するのに役立つ 1 つの良い方法であるため、これはプロです。

繰り返しますが、これらは私の意見です。いくつかの部分を誤解している可能性があり、他の部分で間違っている可能性があります。:)

于 2011-11-28T14:34:37.850 に答える