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.
Related
I'm trying to design an air-gapped server, which will be hosted and managed by the user. I will have SQL Server 2019 running on that server, which will access an important hosted database.
How do I prevent the user from modifying or replacing the database on the filesystem level? Note that the user will be a standard user and will not have Administrator privileges.
I know that I can control database access using roles and passwords, so I'm more worried about the filesystem access to the database files.
Architecture
A .NET application running with standard privileges which the user can use to view some data from the database (limited read access).
A WCF webservice running with administrative privileges that can read / write to the database but the user will have no access to this.
Ideal scenario
All access to the database must go through SQL Server.
The user will have no direct access to the database through the filesystem.
The user should only be able to selectively view some data through the .NET application.
There is nothing you can do to prevent a user who has admin rights on the system from doing whatever they want.
Ideally you would give them a black box system which they have no admin rights on, but then they cannot manage it properly, as sysadmin work always needs admin rights.
So the files and folders containing the database files would be owned and only have access by the SQL Server service account. All other users should have no rights on it. This should prevent a standard user without physical access to the box from gaining access.
If they are a limited user you can lock down the file system like this easily, but a determined user with physical access can still hack through. Ultimately, either you provide this over the cloud (host it yourself) or write a good contract. There is simply no other way.
Using Azure Resource Manager.
I have an Azure SQL Database resource, and even when I delete all "allow" firewall (on the sql server's blade) rules, my VM is still able to query the SQL DB.
EVEN when I set "Allow Access" to no for the ip address of the VM, I can still query the DB. How??
Is this because Azure automatically allows resources in the same Resource Group to access it? Even without explicit Firewall allow rules?
Under the Firewall section of the SQL Server blade, there's a switch called "Allow access to Azure services". Having this on will allow any Azure resource to access get through the firewall (they will still need your username and password of course to actually access the server). This includes Azure resources on other people's subscriptions. See this answer.
I had this turned on and that's why my firewall settings made no difference for my VM's.
Not exactly sure what's happening with your specific situation, security-wise, but Resource Groups have nothing to do with it. Resource Groups help organize resources within a single container, where you can manage those resources better (e.g. add users to the Resource Group without adding them to the rest of your subscription). They don't play a role in communication between Azure services.
How can I RDP to an Azure box using an account I created in Azure? I don't want to go down the route of syncing directories or anything. Just simply want to be able to create accounts in Azure that can be used to access Azure servers.
This is a basic centralised authentication model and I am sure I am just missing something. Surely Microsoft can't expect us to add a bunch of users and service accounts on EACH server we create and manage passwords etc as entirely separate entities.
By "Azure Box" I assume you mean an Azure VM running Windows. There's nothing "magical" about these VMs. If you want central user management instead of relying on local user accounts you need to add it to an Active Directory domain. And if you want sync between this Active Directory domain and the Azure Active Directory for your tenant, you need to set up Directory Sync.
One cannot do this (without resorting to directory synchronisation). A Configuration Management tool such as SaltStack/Chef/Puppet seems a leaner fit than creating a traditional AD infrastructure.
I have been allocated the responsibility at work of revising the current reporting services authentication process. The aim is to maintain the necessary level of security and also simplify the maintenance/configuration of granting access to the individual reports.
I do NOT have access to the domain controllers to be able to modify or create new AD groups. I have to work with the groups/users that currently exist.
In terms of authentication, it seems that I have the option of using either:
Windows authentication
SQL Server authentication.
Both the report server and the report database will reside on the same server. With this in mind, I understand that Windows authentication is probably a better solution as there is no need to maintain a separate SQL Server table of Users (and their passwords). Granting access to a report once it has been deployed on the report server, would simply involve adding the user/group to the report (load the report in a browser and access the Properties\Security option).
Using the second option of SQL Server authentication does not seem as appropriate as using Windows authentication for the reason the report server and report database are on the same box.
I am using SQL Server 2000 databases. The version of reporting services I have installed is Microsoft SQL Server 2008.
Please could someone let me know if my thinking is correct (i.e. I should go for Windows authentication). Cheers.
Jimmy
Sql Server authentication is not an option for users connecting to SSRS. It is an option for SSRS connecting to databases where it will get its data.
So bottom line, yes, you need to use Windows Authentication for user connections to SSRS. You can use special user names such as "Authenticated Users" or "Everyone" in SSRS to allow broad access.
I understand that you don't have access to AD, but managing the user accounts' membership in AD groups would be much easier than tracking and managing individual access in SSRS.
But without the AD access you can still add Windows/AD accounts to the report permissions and use those. You just create a more complex system, since you need to manage permissions for every individual separately. You can group the reports in folders and secure the folders: the reports can inherit that security.
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.