Webapp: Mysql: безопасность на уровне строк.Pro / минусы?Лучший способ сделать это? - PullRequest
2 голосов
/ 28 ноября 2011

Я пытаюсь эмулировать безопасность на уровне строк в веб-приложении, которое я разрабатываю с использованием MySQL.

Использование этого метода: создание базы данных с необходимыми таблицами, в которой будут храниться данные, относящиеся ко всем пользователям.правильное индексирование столбцов таблиц.

Создание «представлений» mysql для конкретных пользователей на основе идентификатора пользователя.

Для обеспечения безопасности на уровне строк мне также потребуется создать учетную запись mysql для каждого пользователя.для пользователя и установите права «предоставления» для представлений.

Для веб-интерфейса будет использоваться основанная на 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.

Ответы [ 2 ]

0 голосов
/ 29 ноября 2011

ответ на вопрос 3:

Намного проще было бы использовать отдельные таблицы. Это может быть лучше с точки зрения производительности. Есть ли причина, по которой вы хотите хранить данные в одной таблице? Как я понял, между пользователями нет общих строк.

0 голосов
/ 28 ноября 2011

Мое мнение:

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

Есть несколько точек входа в вашу базу данных. Это отличается от наличия таблицы users, в которой хранится информация ваших пользователей, и затем использования правильно ограниченной учетной записи mysql, которую они все используют (как часть файла конфигурации вашего веб-приложения)

2] Does the disk I/O increase considerably?

Не уверен, как правильно ответить на этот вопрос, потому что статья, которую вы, возможно, прочитали, была о нескольких учетных записях sql, используемых разработчиками / администраторами баз данных / и т.д., которые directly имеют доступ к вашей базе данных.

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

Имея функции и представления SQL в вашей реализации для MySQL, может быть, вы можете просто попытаться контролировать доступ не с учетных записей SQL, а с доступом пользователей через данные таблиц?

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

Следствием наличия нескольких учетных записей является ведение учетных записей.

Использование представлений, функций и хранимых процедур будет хорошим способом управления количеством или видом данных, которые вы разрешаете видеть посетителям, так что это профессионал.

Опять же, это только мои мнения; Возможно, я неправильно понял несколько частей, и я могу ошибаться с другими. :)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...