We are using different Microsoft SQL Servers (SQL Server 2008 R2) within a Windows LAN network physically seperated each of them. Is there a good strategy how to control incoming connections to the central server?
I mean, how can I prevent/protocol significant changes like ALTER to a table structures from "other" users?
Thank you,
Move
Create different users for different purposes
Most SQL Server databases have a number of users viewing and accessing data, which makes security a major concern for the administrator. The smart administrator will take full advantage of SQL Server security roles, which grant and deny permissions to groups of users, greatly reducing the security workload.
The first step in protecting your client’s data is determining which users need to view which data and then allowing access to only those users. For example, a payroll clerk probably views salary figures for everyone in your company while team managers have access to salaries for team members. Individual employees have no need to view salaries at all.
The benefits of using roles
Roles are a part of the tiered security model:
Login security—Connecting to the server
Database security—Getting access to the database
Database objects—Getting access to individual database objects and data
For better understanding read below link guide line you will get answer
https://www.techrepublic.com/article/understanding-roles-in-sql-server-security/
https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/server-and-database-roles-in-sql-server
https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/database-level-roles?view=sql-server-2017
Related
I'm an auditor, and I want to ask if there is a list of system generated report of DBA users in SQL Server? Per my audit client, there is no way to generate it.
However, I'm thinking that this is a data also in which you can just generate to the SQL Server databases. I just want to validate that the list of DBAs is restricted to DBA of our company for legitimate business need and security purpose.
Row-Level Security Is this a good way to protect registered registries against other database administrators that do not have enough information or sensitivity to recorded data or misuse of data for personal resources.
I am using Microsoft SQL Server. As you know, edit the data in the database either manually by the original environment using SQL Server user SA or any user of other authorized and also through programming environment that connects to SQL Server to edit the data.
Is there a way to disable this editing of data in the SQL Server environment so there is no person in the database manually does not change?
No users even through MSSQL unable to make changes in the original data. For example, to manually stock the number to another number that this event would not have realized how to change.
can SINGLE_USER help?
Can wizard SQL manager for remote did not open?
Who does not have access to SQL server console? And changes only through an interface software or Command Line in the master database server operating system?
Change the password of the SA user and do not give it out.
Do not give user access to the database specific using the dbo, data writer and associates roles.
Only allow users access via the data reader role.
Only admin user (if any) should have data writer access.
Give and specific user utilized via the programming side more elevated permissions.
Row-Level Security is a nearly good feature in SQL server 2016.
Row-Level Security enables you to implement restrictions on data row access.
For example ensuring that workers can access only those data rows
that are pertinent to their department, or restrict a customer's data
access to only the data relevant to their company.
I have a rich client program installed on users PCs where I want to start storing some user created data on SQL Azure/SQL Server. The potential anonymous-to-me users would key in their name, email account and a password which would get stored on SQL Azure/SQL Server. Then they would start generating their own data. I'm anticipating volumes of maybe 1000 users.
There are times when those users would like to run their own queries against their own data but, obviously, I must ensure that they can never view other users data.
I'm thinking the best way to ensure security of data is for each user to be issued their own SQL Azure account and password. I will setup a SQL Azure user and long password, known only to me, which only has permissions to execute several stored procedures with appropriate parameters being passed to those SPs which will create the SQL Server accounts, logins and add the users to a role which I have created.
Obviously someone running debugging tools could figure out the user name and password but I'm thinking this isn't a big deal. If all that particular SQL Azure account can do is execute a few SPs so what if a malicious individual starts doing that. I will only allow a very limited amount of data to be uploaded before I require payment.
The users can only insert records using stored procedures which use the following:
SELECT #uName=SYSTEM_USER
and only select appropriate parent records. All stored procedures which users can execute would have the above as required to ensure they can only work with their own records.
All views will have embedded with them WHERE clauses such as
WHERE tbLoginName = SYSTEM_USER.
I'm new to SQL Server so I may be missing some fundamental concepts so I'd appreciate any and all comments.
The issue is, as pointed out on http://msdn.microsoft.com/en-us/library/ms189751.aspx:
In SQL Azure, only the server-level principal login (created by the provisioning process) or members of the loginmanager database role in the master database can create new logins.
Those accounts are also capable of alter and drop logins. So if you embed those accounts in the client application, you’re essentially granting every user permission to alter/drop other users accounts. While an average user won’t do that, a hacker will. So you cannot let a client application manage SQL Azure logins, unless only trusted users (such as your IT administrator) are permitted to use the app.
Best Regards,
Ming Xu.
I would like to point out a potential issue in the approach you mentioned: Your master SQL Azure account need to have privilege to create new accounts and grant them access to particular tables. This means your master account itself need to also have access to all those tables. If you store the master account on the client side, a clever user will get access to all users data.
From my experience, connecting to a database directly from a client side application will almost always make your solution less secure. You can do that for testing purposes, but in a real world solution, I would like to suggest you to use a service. You can host the service in Windows Azure. Then the service will access the database, and client application can only access the service. In this way, you can authenticate clients using any mechanisms you like, such as ASP.NET membership.
Best Regards,
Ming Xu.
You are essentially creating a physical two-tier database connection, allowing a client application to connect directly to the database. This is a problem in many ways, including security and performance. From a security standpoint, not controlling from where your customers will connect, you will need to keep your firewall rule wide open for anyone in the world to try to hack every customer uid/pwd. And instead of having only 1 user id to play with, hackers will have up to 1,000...
The second issue is performance. You applications will be unable to leverage connection pooling, creating undue stress on your database server and possibly hitting throttling issues at some point. Using a web service, with ASP.NET membership to manage logins, and using a service account (i.e. the same uid/pwd) to get data will ensure you will leverage connection pooling correctly if you keep the connection string the same for all your requests.
With a web service layer you also have a whole slew of new options at your fingertips that a two-tier architecture can't offer. This includes centralizing your business and data access logic, adding caching for improved performance, adding auditing in a centralized location, allowing to make updates to parts of your applications without redeploying anything at your customer locations and so much more...
In the cloud, you are much better off leveraging web services.
My 2 cents.
I having trouble understanding some core concepts in SQL Server 2008. Until recently I haven't had to care much about security, users, schemas etc.
What is the difference between a Login and a User?
How do these relate to roles
What is a schema? (Until I started reading about security I thought a schema was just a database design?!)
I'd like to be able to create a script to create my Users, Logins, especially as IIS attempts to connect to SQL Server as it's app pool. Can anyone point me in the direction of some examples of scripting this kind of thing?
Thanks in advance!
P.S:
I've been trying to read some MSDN articles about this stuff and getting a bit lost for example this seemed out of my depth:
http://msdn.microsoft.com/en-us/library/ms190387.aspx
A login is the principal that is used to connect to the server. A user is the principal that is used to connect to a database. The security context on the instance itself is dictated by the login, it's roles and the permissions granted/denied. The security context on the database is dictated by the user, it's roles and the permissions granted/denied.
Like all other role based systems, the roles are logical groupings of permissions. Roles can be applied to users and logins. There are fixed server roles and fixed database roles for frequently used sets of permissions.
A schema is a database object that is used for two things: logical separation of database objects (tables, stored procs, functions, views), and security separation. A schema contains these objects. And users can be granted/denied rights on schemas, implicitly granting/denying rights on the objects contained within.
4 doesn't really seem like a question. Can you reword??
What's a good way to manage and maintain SQL Server logins, server roles, and individual access rights across multiple databases that exist in multiple environments? What are your best practices?
Some info about my situation:
SQL Server 2005
We have N amount of "client" databases with identical schemas (in theory, at least)
We have a central "admin" database that references each client database and can hold configuration values
This "admin/client" pattern is duplicated across multiple environments (dev/qa/stage/prod)
Some users, like testers, need different rights based on evironment
We frequently have to pull client db backups from one environment to restore on another for development or testing purposes
We keep our stored procedures and scripts in source control and deploy in a build cycle
Right now my organization is chaotic and we don't follow good security practices. We have no formal DBA. However, if we got any more complex it would be a constant hassle to maintain it all the time. I could see migrating to a new server or recovering from disaster being extremely time consuming if we where to attempt configuring it directly through the management studio IDE.
First, to make restoring a database to a different server easier, make sure that your logins all have the same SID on all of your servers by using the sp_help_revlogin stored procedure from Microsoft to script the login on the first server you create it on and then use the script to create the login on your other servers. This keeps the database user mapped to the login correctly when you restore the database.
Having different permissions at the database level depending on the environment is going to be a hassle to a point no matter how you role this out. I have a stored procedure in master that gets called on my Dev Server as a part of my restore process that performs the additional GRANT's on the database to give the developers access to make changes. That's the best I have been able to come up with to solve similar problems.
A way to make the rights easier would be to create rolls in the database called Dev, QA, Test, Prod and grant the correct rights to those roles. Then as you restore the databases to each environment just drop the developers in the correct role.
We use active directory groups and enforce windows authenticated logins. From within SQL Server we can then define access based on the AD group the user is in by creating a single SQL Server login per AD group. Not sure if this is any better or worse than DB roles, but it means the roles are managed outside each database.
Propagating access to databases is then either a manual operation or a short SQL script to ensure the logins in the database point to a valid SQL Server login (which in turn is an AD group).
Generally this works well for the general case. We can use DB roles then to assign the builtin roles (e.g, db_datareader) to each AD group
Rarely someone needs some specific access to a database outside this model. We either end up opening it up to the group as a whole if it's not going to be invasive or critical or we'll end up creating a per-user account that has to be managed separately. We endevour to keep these to an absolute minimum, and clean them up every now and then so they're not abused/forgotten about.