Webapp：Mysql：行级安全。优点/缺点？更好的方法来做到这一点？答案

【问题标题】：Webapp: Mysql: Row level security. Pro/cons? A better way to do this?Webapp：Mysql：行级安全。优点/缺点？更好的方法来做到这一点？
【发布时间】：2011-12-05 05:29:09
【问题描述】：

我正在尝试在我正在使用 MySQL 开发的 web 应用上模拟行级安全性。

使用此方法：创建一个包含所需表的数据库，其中将存储与所有用户相关的数据，并对表的列进行适当的索引。

根据用户 ID 为特定用户创建 mysql“视图”。

为了实现行级安全，我还必须为每个用户创建 mysql 帐户并设置视图的“授予”权限。

对于 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.

【问题讨论】：

不要嘲笑我，你能建议我能做什么/读什么吗？
这不是在嘲笑你，但如果看起来像这样，我很抱歉。我只是想知道你为什么要这样做。为什么你甚至需要“行级安全”，这样做的原因是什么，你这样做是为了防止什么？至于磁盘 I/O，创建用户、视图等不会影响磁盘 I/O 到您需要担心的程度（除非您每天有成千上万的新用户，这加起来就是磁盘 I /O 处理视图时）。
我需要row level security，因为有些行将在多个用户之间共享并且有 1 或 2 个所有者。只有这些所有者可以删除/修改它们。 如果您有/知道我在哪里可以了解更好的方法，请提出建议。
我的建议是在数据库级别从头开始行“安全”实现，并使用您的 PHP 应用程序来确定用户可以查看或修改的内容。在数据存储级别实现它会适得其反，因为数据库不应该以这种方式使用。但是，如果您仍然坚持通过数据库而不是通过 PHP 进行操作 - 我只能说祝您好运，并且您将自己动手。任何告诉你实施“行级安全”是个好主意的人都不知道他们在说什么。
有点晚，但迟到总比没有好:) 就像对路过的其他人的评论一样...您可以进行行级安全性，而无需为每个用户创建视图。可以在此处找到详细信息：sqlmaestro.com/resources/all/row_level_security_mysql 根据您的操作，使用 MySQL 而不是 PHP 实际实现安全性可能更安全。事实上，即使您的用户数据库详细信息在技术上受到损害，也只有一部分数据处于危险之中.

标签： mysql database-design database-schema row-level-security disk-io

【解决方案1】：

我的意见：

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?

拥有多个帐户的后果之一是帐户的维护。

使用视图和函数以及存储过程将是帮助控制您允许访问者看到的数据数量或类型的一种好方法，所以这是一个专业人士。

再一次，这些只是我的意见；我可能误解了一些部分，我可能对其他部分有误。 :)

【讨论】：

感谢您的回复：不知道如何正确回答这个问题，因为您可能阅读的文章是关于直接访问您的数据库的开发人员/数据库管理员/等使用的多个 sql 帐户.. 感谢您指出这一点。这篇文章是关于使用触发器和自动日志记录的。
link 使用触发器时磁盘 i/o 会增加。您的第一点和第三点是我最初的实施想法。有什么参考资料可以参考吗？附言我以前不小心按了 enter 而不是 shift enter

【解决方案2】：

问题 3 的答案：

一个更简单的方法可能是使用单独的表。在性能方面也可能更好。您是否有理由将数据保存在同一个表中？据我了解，用户之间不会共享任何行。

【讨论】：

行将在用户之间共享。这就是我关注行级安全性的原因。我应该在前面提到这一点。而且.. 更多的表，1] 我的数据库表的大小更大。 2] 更多的 I/O。 3] 增大我的数据库转储的大小。