I'm starting to learn the basics of developing database applications (I want to learn MySQL specifically), but I'm unable to determine how the structure of the application should be. Say my system serves the students of a school (records grades, etc.), where the client side is a GUI application written in C++/Qt talking to my server computer over the internet.
My question is What is the natural/correct way to implement this?
Do I encapsulate the SQL queries directly in the GUI program, and
thus making every student a user of the MySQL database, and thus
assigning a database user for each student?
Or should the encapsulation occur in a server side application that I
write that represents the link between the GUI application and the database
server? (I.e. the server side application is the client side of the
MySQL system.)
In other words, who is the user of MySQL? My server side application or the users of my client side application?
In both cases (wide client -- client-DB or thin client -- client-server) it is enough to have only 1 MySQL user.
You will store it's user and password in application settings (usually hidden from regular student/customer).
And you will grant those rights to application username, not to the student.
It is the role of application to control the user rights.
Safety:
For the thin client, it is usually safe, but it will introduce the need to use API-key that has its danger.
For wide client architecture it is dangerous enough, so:
usually, such applications work in-house
MySQL user has those rights that protect the data from full destroying (at least forbid tables dropping).
grant privileges to the user on SPECIFIC HOSTs
make backup copies on the hourly or daily basis depends on the
size
it is good to store the password, not in open form but
encrypted
Related
On a lot of public webpages, hosted by people at their own homes, they use their own desktops as webserver. Within this kind of setting usually I use a form of server sided language (like php) that connects to an MySQL server on the same machine. When installing this I always give an password to the “root” user and create a new user and password for the application (the php) script to use. Because both script and database are on the same “localhost” I always set the allowed connection to only allow connections from the local host and not from anywhere else. So both “root” and other “users” can only connect from when accessed from within the machine.
(the separate “root” and “user” accounts are made to give them separate privileges and an user can not drop scheme’s for example)
Today it struck me, why am I setting passwords in MySQL? Because if you want to connect to this database you already have to been logged in in the local machine. So, is setting passwords really necessary or just a redundant precaution?
And if it’s NOT an redundant precaution, why is it unsafe to not set a password.
(not that it is a big burden, but I have to remember all these passwords somehow, using encrypted systems this is not a real big problem, but if it could be avoided than……)
The comments on your post have mostly summed this up, but as far as I am aware, this is known as "Defense in depth" (See 1 and 2). Defense in depth is basically about avoiding having a single point of failure in your project - If your webserver is compromised, having a weak password means that you're just giving away your database for free. This would be equivalent to somebody breaking into your house to find you've placed your safe on the kitchen table and unlocked it.
If you're hosting an externally facing website that you hope to get a decent amount of traffic, making it as secure as possible is a good idea, unless you particularly like the idea of malicious users having direct access to your home network. That said, if you are expecting a decent amount of traffic I highly recommend hosting your website elsewhere - You may find that your home internet speeds suffer greatly as a result.
I work at a small company and I am trying to figure out a solution for storing sensitive data of multiple clients in Microsoft SQL server. Actually, I feel like this is a general database question and it is not specific to MSSQL.
Until now we have been using a proprietary database where the client data is stored as db files (flat files) in the client’s root directories in the file system. So the operating system permissions guarantee that the application used by client X can never fetch data from client Y’s database. Please note that there is no database server/instance/engine here…
However, for my project I want to use SQL database. But the security folks are expressing concerns over putting data of different clients on a single database.
One option is to create separate database instances for different clients. However, I am not sure if this idea is scalable.
So my questions are:
1) Is there any mechanism in MSSQL that enables you to store databases ‘separately’ in different files used by the SQL server?
2) Let’s say I have only one database instance where I have databases of client X and client Y. How can I make sure that client X’s requests can never (accidentally) get misdirected to client Y’s database? I do not want to rely on some parameter in my code to determine which database to fetch from! :)
So, is there any solid authentication scheme to guarantee that my queries could not be misdirected to fetch from an incorrect client table?
I think this is a very common problem and there has to be a good solution for this. What are other companies doing?
Please let me know if there are any good articles to read up on this.
Different databases are always stored in different files in SQL Server so you don't even have to do anything special for this. However, NTFS permissions will not help you in this case as the clients aren't ever accessing the files directly on disk.
One possible solution in SQL Server is to create separate sets of Windows user IDs and map those to separate SQL Logins for each customer. You could then only assign those logins access to the appropriate databases. For example, if you were hosting web sites for client X and client Y, you would set up the connection string(s) in the web.config for client X's web site to use the appropriate login(s) for client X's database. Vice versa for client Y. This guarantees that no matter what (barring a hard-coded login), the code from client X's site will never access client Y's database.
You can have 32,000 databases on a single instance of SQL server and having separate databases enables a number of improved serviceability scenarios (such as restoring a single customer's DB in case of a data problem without affecting all of your other customers).
http://technet.microsoft.com/en-us/library/ms143432.aspx
Is it unsafe to open the mysql server port to allow remote connections?
If it is unsafe, what is a better solution?
EDIT:
-I need read and write rights.
-Each user has a password to connect. That means that not any user can connect to the database.
What security problems does this enviroment have?
Is there a better solution?
In principle, MySQL has a rigorous permissions system which could be set up to allow remote users minimal levels of access to the tables they would need to do their job.
In practice, MySQL has had many exploits in the past, both in applying those permissions and in preventing access to the host server. It is reasonable to expect more in future; since very few admins allow untrusted access to a MySQL server, it is not strongly locked down against attacks (unlike, say, a web server like Apache).
MySQL's authentication model is also weak: passwords are stored in a table as unsalted hashes and there is no protection against brute-force password attacks. For communication between a trusted server app and the DB, you can get away with that; for authentication of not-wholly-trusted third parties it's not good enough.
If your “users” are database administrators, it's plausible to give them remote access, with access locked down by IP address/firewall or SSH tunnel. If the “users” are not-fully-trusted third parties you expect to be using the database as part of a client application, I wouldn't. And definitely don't open access to the whole public internet.
In any case, if we are talking about application users, your business rules are going to need more granularity in access rights than you can manage with table- or column-level controls. For example rules like “reviewer-class users may set article.state to 3 but only if article.state was previously 1 or 2”, or “setting article.state to 4 always causes the associated articlecontent to be deleted” cannot be reproduced in table permissions.
For that, you almost always need some component between the raw table storage and the remote client/application to manage the requests. That layer is traditionally a separate server application which is the only thing talking to the database. You could in theory write that component in database stored procedures, and give users access only to the procs not the tables. But doing anything complicated in stored procs is a super pain to write and maintain compared to a general-purpose programming language.
im struggling to find the best practice to this so any links or research reading materials or any Google search terms will be much appreciated.
Im a volunteer for a local charity organization, a childcare setting.
We have a mysql database that contains various tables containing children & Parent information, invoices, staff rotas etc.
What we would like to attempt to do is have secure online access for parents to view there own contact details and invoices.
My question is, is it safe to allow the website to have access to the main database. it would be a second set of userPermisions with only read access to select tables and not the entire database.
I don't want the website to open up a hole to allow users to obtain all our data or destroy or corrupt the main database.
Or
should i create a second database that the website will have access to and have the main database sync with the second? I can see future issues if we decide to allow parents to edit there own contact details, pay invoices online.
Web specific details will be kept in a second database such as user name password, forum etc
Its not any thing iv ever attempted to do before and don't know where to start in terms of research.
Kind regards
Matt
You certainly couldn't hurt anything by having a second, slave/read-only database accessible to your user interface. If done properly, MySQL grants can restrict users to read-only operations, so it's not necessary from a functional standpoint to have a second database. Perhaps, given the nature of your business, there may be a legal reason why you must have a second database though. Be sure to investigate the requirements for protecting PII (e.g. HIPPA)
Security is an ongoing process - part of it is ensuring proper identification and authorization as well as defense in depth - ensuring that the account used to access the database has least privileges and that the surface area exposed to that account is minimal. Also if the database is on the same machine as the web server, then ensuring that a compromise of the web server doesn't also compromise the database.
You also have to contend with the standard social elements - ensuring users have a way to get their first password/setup an account, maintain their own passwords. You should not store their passwords (even encrypted), but instead store only a salted hash. When they forget their password, the reset it themselves, since the web site cannot and should not send them a permanent password via email.
And you should be aware of XSS (cross-site scripting attacks), SQL injection - you should be able to find references to that in most discussions of web application development.
I am working on a site that multiple projects will be using to enter confidential subject information for various research projects. Project data access will be limited to specific users and tools. But certain core data will be referenced in and joined to the project tables (username, project meta-data, etc). The current plan is that each project will have mysql users with any combination of Select, Update, or Insert rights as needed. Plus an overall project Adminstrator user that can alter the shape of the project's tables that will only be used in phpadmin. We are using a Database object with some backtrace logic to determine what object passed it connection credentials and will only allow that connection to be used by the originating object (not impossible to get around by a dedicated programmer, but would throw up red flags in code review). And we are following standard procedure of moving the config out of the web root and keeping all credentials in config files instead of code. Of course there is an overall administrator but that has so many access rules and it's password is ludicrously long (we have a static yubikey + 10 char password).
What I want to know is whether to separate project data out to their own databases or should I put them in tables that have access limited to certain accounts? Setting user permissions on the Database or Table level seem to be about equitable in difficulty. There will be joins and other such operations between the core tables (meta-data usually) and the protected data. But joining across databases on the same server works fine, but I am uncertain about how the performance of intra-database joins compare to inter-database joins.
It doesn't matter if you put them in the same database or in different ones. You can implement a good (or a bad) security concept with both alternatives.
if you are using one database and you put data for different users in one table you will have to implement a lot of the access control in you application.
if you have separated the data completely in different tables (or even databases) you can easily use the access control of mysql. In this case I would go with separated databases, because it is more convenient when setting up a backup system or if you want to scale your application over more than one machine. But since you want to join across different databases you gonna lose some of these advantages so it doesn't really matter.