Often in example code for software, I see a connection string eg. mysql://user#localhost
in the configuration file for the software to get access to the database. This seems fine for a test/development server but for production, this seems very insecure. What is the correct way to do this in a production environment?
Your production server should be secured, no random users/people should have access to sensitive files - such as app.config with a connection string in it.
That's pretty much the way it is on a production server as well. While it's a good idea to have the application access the database using an account that is as restricted as possible (e.g., it might not have permission to create or drop tables, schemas, databases, or might even be read-only depending on the application), if someone gains access to the application server they're pretty much going to gain at least that level of access to the database server - even if the authentication to the database is based on "trust" (i.e. some windows types of schemes), the attacker has access to the trusted host.
In past jobs, I've heard considerations of various obfuscation scenarios but ultimately they don't accomplish much.
Related
I created SQL account for an application but how do I restrict or deny the same account not to connect the database using SSMS or Azure data studio by the developers since the developers can view the user information in web.config file.
Thanks,
Sandeep
You can use Azure Active Directory to authenticate your app, so that you don't need to write the username and password in config file.
With Azure AD authentication, you can centrally manage the identities of database users and other Microsoft services in one central location.
Benefits:
It provides an alternative to SQL Server authentication.
It helps stop the proliferation of user identities across servers.
It allows password rotation in a single place.
You can read more details from this document.
Basically the answer to your question is... You can't...
There is no way to identify the client of a certain connection in Azure SQL. What you can do, for example, is restrict access to a certain server using s firewall. But if your dev env is on the same machine as your SSMS that won't work because you're then blocking the dev env as well.
In that case, the best practice is to create a dev database to which all devs have access. In that case, it doesn't matter for you everyone knows the password because it's the dev database.
For production environments, you need to treat database credentials as secrets and thus make sure they are stored in a safe place. When you're using Azure, the KeyVault may be a good place to store the password. This KeyVault has a fine grained way of allowing access to secrets for individuals as well as IT systems.
I used SQL Server 2008 R2 database in my application, now I want to install the application for my friend. How can I block access to my database tables and stored procedures ?
I removed Windows authentication and SQL Server Management Studio just login with my own user or pass ! But what happen if he opens my database file in other Management Studio in other systems?
Your users should not have access (ACL permissions) to MDF files, ever. Not at all. They should, instead, have database access, and their account should be set to do what you want them to do, and not to do what you don't.
This is a pretty basic question, really; what you need to look into is SQL Server security, so you can figure out how and what to secure your database with users. But you also need proper file security, as I noted above.
Finally... your question makes me wonder; you do know that SQL Server is not necessarily meant to be installed on every single client system, right? You certainly can do that, but it's a server product. If you are installing it on a computer to which the user has admin rights, the game is pretty much over, really.
I have been working on the software using a SQL Server database. Now I am in the phase when I would like to provide this software for other people, but I don't know how to manage the database. The thing is that it is really inconvenient when installing my software to also install SQL Server at the users computer (many unexpected thing could happen).
Therefore I thought that I would pay for web hosting with SQL Server, but it is:
Expensive (just for database with few tables).
Most of the web hosting don't offer remote access to the SQL Server database (so I can't connect there from my software).
So there is my question, what would you do? My own virtual server? (even more expensive), or would you install SQL Server on users computer? Or do you know where to get only SQL Server hosting for low costs?
I don't advice using a remote SQL Server. SQL Connections strongly depend on network connection and the Internet is not "stable" enough for that. There are also performance issues that will make your application completely useless.
One important thing you didn't mention is whether different users will share the same data or will have their own. If each user will use their own data you can install a "local" SQL Server Edition (SQL Compact Edition, here is the reference)
http://msdn.microsoft.com/en-us/library/aa983341(v=vs.110).aspx
In case several users will share the same data, you shouldn't rely on the database solely. One possible approach is having an Application server that implements business logic whereas your desktop application stays actiong as a "dumb" client. This is a lot better for performance and reduce data transfer problems. You can implement webservices for you application server. This is a good solution as the data is transfered from he application server to the clients through HTTP/HTTPS and this relieves you from dealing with ports and other communication issues. An alternative is using Microsoft Communication Framework (WCF)
Good luck!
I haven't done SQL in a while, so I need to freshen up on things. I have a SQL Database running on my computer, and my server is localhost. I made an app in VB.Net that connects to this database. Everything works fine and all, until I distrubute my app to another person. When they try to connnect it doesn't seem to work for them. Do you know whats happening, I copy the whole release folder to them, and they can't connect? Also does anyone know why my icon is not appearing for my application as well, when I give it to another person?
Sincerely,
Kevin
It looks like you are distributing the code with a connection to a MySQL server in localhost, but the other users do not have a SQL server installed. So, depending on what you actually want to do, you have alternatives:
You want to distribute your app with a database, where each user will have his own data (their own 'SQL server'): In this case I recommend you to use SQLite. That way, they don't have to install any database server because SQLite is a file-based DB server, all the funcionality is in the library, no install needed. http://sqlite.phxsoftware.com/ is a .NET binding that works very well.
You want for other people to connect to your database: Then you have to configure connectivity from your users to your database and have a means to configure the connection string, because you probably have "localhost" hard coded there now. Opening the DB server to the world is not a very wise thing to do in general, YMMV. A good alternative is to offer a web services / REST interface for clients to access the data instead of opening direct connections to the DB server.
We have a DB server with a couple web app db's on there (don't get a ton of traffic). We'd like to make use of the server and allow it to be the DB server for sharepoint. I'm assuming it's not good practice and that sharepoint should have it's own exclusive db server. Am I right in that conclusion, or is it alright if we put the database on a server that already hosts other databases.
You can install SharePoint on an existing DB server, sure. Unless your environment is going to be huge, I don't see why you would give it its own DB server. It will use an embedded SQL Server instance if you want, but you'll get better performance if you have the full-blown version. We're running a few SharePoint apps on our DB server with a number of other applications.
The way in which I solve this is to install a second SQL Server instance dedicated to SharePoint, as SharePoint likes to have a lot of control over the database and spews all sorts of stuff such as logins, etc. across the instance, which you really want to separate from your standard line of business instance.
The added bonus is multiple SQL Server instances on the same physical machine are included in your licence.
Be careful with the SQL Server collation. I think SharePoint requires a particular setting for this. See http://www.moss2007.be/blogs/vandest/archive/2007/07/24/sharepoint-2007-and-sql-server-collation-latin1_general_ci_as_ks_ws.aspx for one reference.
Prior to centralizing our environment we had many Sharepoint sites located on servers with existing applications. I'm not a fan of adding an additional named instance as this increases the administrative overhead for the DBA. You have to know how much use you expect of your Sharepoint instance then measure the resource utilization of your existing applications balance it from there.