How to limit access to Mysql database for a developer - mysql

So we've got a MYSQL database with very sensitive information and we want to prevent it from being exported by a developer/admin who has access to it, while still allowing them to access database while working on their duties.
In simple terms we want to prohibit mass select on specific tables.
Ideally it would be an option to disable mass select, something like limit 0, 1 enforcement for all SELECT queries on specific tables. Is it possible to configure MYSQL like that? Any other ideas how to prevent database from being exported?

Any solution I can think of when someone needs to access your production data within MySQL and you want to apply the principle of least privilege leads to separation of users and to the page on GRANT command in MySQL documentation.
But as I said in a comment to you question, it is much easier to develop a procedure to generate an impersonated sample of your data, so that your developers would not have access to the production data.

Related

MySQL Multiple Database Setup

I've searched for an answer to this and all I can seem to find are questions asking whether it is better to use multiple databases or multiple tables in a single database. This isn't my question though.
QUESTION 1.
I want to set up a new database alongside my current DB and don't know how. I want to give a user full admin access to DB2 without seeing DB1. This way I can host a friend's site and they can create and delete as many tables as they want without disturbing my own DB. I could also use it for demo sites that aren't secure and shouldn't exist inside my primary DB.
I figure I could do this pretty easily with a virtual machine and run a separate instance of MySQL but my resources are limited so that isn't really an option.
I'd like to set this up in one of 2 ways. I would prefer to have "server.example.com" host both DBs and open the proper DB based on user login. If not I could do it routing to server1.example.com and server2.example.com.
QUESTION 2.
If this isn't possible I'd like to know how to properly set up restricted access to a single DB in sequel pro. I have been messing around with it and so far prefer it to PHPMyAdmin. For some reason if I set up a new user with no permissions they have full access to my 'information_schema' and 'test' tables but can't create new tables. I don't want other users to access these tables though and I want them to be able to set up their own tables. I'd like to set it up so a new user can create a limited number of tables and only see and edit those tables. I can't seem to find information on this either.
Even if my first question is possible I'd like to know the answer to question 2. I've been searching for a long time and can't find reliable information anywhere. Maybe my brain is just tired...
You can set up multiple instances of mysql but for your situation you are better off creating different databases within the same instance.
You can create databases and then add users that only have access to manipulate the database they are given and nothing else.
Essentially the heirarchy is as follows:
Mysql (root or any other super user can see everything)
- Your DB
- Your Users
- Your tables/functions/Procedures/etc
- Their DB
- Their Users
- Their tables/functions/procedures/etc.
You basically separate the access for each, and in PHPMyAdmin it is very easy. The steps are:
Add Database )
Add User, restricting them to that database allowing only priveleges you want to give to that user and only to that database. (Guide here)
You can grant access to different database to different user using GRANT in MySQL.
https://dev.mysql.com/doc/refman/5.1/en/grant.html has the information you need.
The most simple you can do is
CREATE DATABASE db_for_user_a
CREATE DATABASE db_for_user_b
GRANT ALL PRIVILEGES ON db_for_user_a.* TO user_a IDENTIFIED BY 'user_a_s_password'
GRANT ALL PRIVILEGES ON db_for_user_b.* TO user_a IDENTIFIED BY 'user_b_s_password'
You are going to need to provide more information about your set up to answer this question of setting up multiple databases specifically.
Servers typically have methods to create multiple databases with software that is designed specifically to run on those platforms (Apache, and Windows server are a couple servers that can run software like WAMP or phpMyAdmin to manage these databases).
And in answer to the permissions: Yes, you can designate users that can have specific privileges on one, both, or neither of the databases. But, you can also set up table-specific roles and actions as well. This is more obvious with Microsoft's management studio though, where Mysql you may want to use something like Mysql Workbench initially.
On cPanel, for example, you can add a new database if your host allows it. On windows, you'll have to use other tools to set up a new database.
In answer to your first inquiry, each database requires its own connection, and there are database-wide operations that you can do such as migration and backups. A rule of thumb is to only keep entirely separate data in different databases, unless there is absolutely a reason to separate types of information into a different kind of database for efficiency. Typically, you do not relate data between different databases except for much more complex situations.
You can create separate databases and use them separately in sequel pro, I believe. Most platforms have an option to create a new db in the databases list.
Well I think I was confusing some stuff here. I apologize for that. I was calling databases 'tables'.
I was wanting to allow users to create new databases but not see the ones that others create. I think I can make this work by just limiting permissions and allowing users to access one or two databases.
It seems like PHPMyAdmin has some easier to use options than Sequel Pro. I've only briefly used it in the past but I'll give it another shot.
As for command line stuff, I love being able to work in command line but I don't know all the commands so it makes things generally difficult to figure out and the man pages weren't all that helpful.
Thank you for your answers and I'm sorry for my newbie questions.

Providing SQL query access to visitors on a rails app

I want to provide the ability to query the underlying mysql db on a rails-powered site to visitor on the web. The most transparent way seems to be able to take the text in a textbox and pass it to an sql connection.
However, I'd want to hide the user/password details and only make certain content tables available. Also, I only want to provide read access. Is there a convenient way to do this? It would be better if there were convenient view helpers too. Any gems like this? Perhaps something similar to PHP's MyAdmin?
The solution to this is more about configuring your database rather than finding special code.
You need to create a user in your MySQL database and grant read-only privilege to a subset of tables of your choice. Use this user in your connection string for queries from your "raw" SQL page. This is the only place you'll have to change code and all it involves is using a different connection string from your other code.
Here's an object-specific example of granting read-only permissions to a user.
To help manage this issue on the server you could make use of a schema.

Good security in MySQL web application: Root? Not Root?

Suppose you're writing a simple database web application using Ruby and MySQL. Access to the database is controlled by Ruby code. The user name that the Ruby code uses to access the data is the only regular user on the database. Does it make sense for that user to be "root"? Or is there any extra security in creating a second user just for the application?
Simple, consider the root as the main user, who can do everything (by default).
If he wants to dump the whole database, he can, if he wants to create some data to create (for example) fake account to overpass your bank system, he can.
So if your code is not enough secure (and this is quite often usually), you have strong security issue.
Usually, "a basic" security (really basic), should looks like that :
create a simple user, give him (with GRANTS) the right to SELECT, INSERT, UPDATE and DELETE on a specific database.
create another user who can SELECT and lock tables and SHOW VIEWS to perform dump (database save).
On a more "complex" system, you should create many users, depending of what they should access, this is for simple reason : if somebody got a SQL injection access, if the user can only access to a single view (for example), and not the whole database, this is a security issue but not the baddest one...
Also view are often used for that...
And finally don't forget triggers if you want (for example a log table), to disable insert or update or delete on a table, for everybody (except somebody who can destroy trigger of course) :
Use a trigger to stop an insert or update
Besides editing or deleting all data in your database, the root user also have the FILE privilege which gives access to:
LOAD DATA INFILE which can be used to read any file on the server machine.
LOAD DATA LOCAL INFILE which can read files on the client machine (the web server machine).
SELECT ... INTO OUTFILE which can create files on the server machine.
This is why your application should have only the privileges it needs, and this is also the reason your MySQL server daemon should be run as a non-privileged user on the server machine.
See also General Security Issues in the manual.
If everybody/thing is root, you lose auditability, you lose the ability to restrict the app to stop attacks (i.e. your app doesn't need this segment of sensitive information, seal it away from its user). If somebody compromises the app, you can suspend the account etc.
I would not make a user "root".
I'd create a separate username and password just for that application and GRANT it only the permissions required to do its job.
I would create a new user, giving it only the permissions it needs (SELECT, UPDATE, INSERT and DELETE usually do the trick). Like that, you limit the ability for the code to be manipulated in an unintended way.
"root", or generally speaking, users with Super User privileges, can change passwords, delete accounts, and therefore prevent you from accessing your own database.
If you server hosts only one application, then you may not need to create several lesser privileged accounts. However, it is common practice to create at least one user for each application, so that if one application gets compromised, other applications (and underlying data) may not be.

django db schema design for multiple users

I am making a site in django [mysql] that will have to be scalable, so my question is what is better for multiple users with same kind of data
have a db per user , or have one big monolithic db?
Please advice of the design pattern preferred for this?
thanks!
Normally, You use a single database for multiple users with the same table schema, unless your requirement makes you create multiple DBs. Especially, if you have the same kind of data for each user, you must handle access rights and other things in your application side, not in your database side.
Django hava a nice User authentication/authorization system that lets you define permissions and lets you control user access rights (creating a new record, updating an existing one and deleting one) for each type of data that is represented by a table in your system. Also you can define custom permissions to control access rigts as you wish.
Separate databases are almost never the correct answer but there are cases in which it's appropriate. Unless you have very special needs, and in absence of any real description of what your project is, a single database is likely to be the correct decision.

How to restrict user from modifying data in mysql data base?

We need to deploy application(developed by Java) WAR file in client place which make use of MySql 5.0. But we would like to restrict the client (the application owner, not the webpage visitor) from modifying any data in the database. Is there any way to protect data. The client can make use of the application but they should not be able to change any value in database. How to do that?
Manage Role/User permissions
Create an sql user (you should already have one), which will have only SELECT permission. So it would be something like
GRANT SELECT ON db_base.* TO db_user#'localhost' IDENTIFIED BY 'db_passwd';
http://kb.mediatemple.net/questions/788/HOWTO:+GRANT+privileges+in+MySQL
http://blog.wl0.org/2010/01/managing-mysql-grants/
http://www.ntchosting.com/mysql/grant.html
Check links below for further reading
FOR MySQL
Best Practice for Designing User Roles and Permission System?
http://www.databasejournal.com/features/mysql/article.php/3311731/An-introduction-to-MySQL-permissions.htm
http://www.devshed.com/c/a/MySQL/MySQL-User-Account-Management/
Can't set permissions on MySQL user
http://www.aquafold.com/d7/docs/BD5C99E4-3B55-C812-8318-6338A9A89ED9.html
FOR SQL Server.
http://www.databasejournal.com/features/mysql/article.php/3311731/An-introduction-to-MySQL-permissions.htm
http://www.mssqlcity.com/Articles/Adm/SQL70Roles.htm
http://www.sql-server-performance.com/articles/dba/object_permission_scripts_p1.aspx
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1061781.html
http://www.databasejournal.com/features/mssql/article.php/2246271/Managing-Users-Permissions-on-SQL-Server.htm
This is impossible; if you deploy the application at the client, he will have the credentials and will be able to log into the MySQL database and pretent he is the application. And thus he can make any change to the database that your application can.
The only way to solve this securely is to make a tier between the client and your MySQL database, and make sure that you control this so that it is only possible to make 'legal' changes.
Just write the code accordingly so that the user doesn't have any chance to modify the database? I.e. the code doesn't execute any INSERT or UPDATE and/or controls the access based on a login/role.
I honestly really don't forsee any problems here, or the code must be prone to SQL injection attacks.
Update: The above answer is actually irrelevant since the question is clarified. Turning into Community Wiki.