I'm making an Access database which will be used by multiple people, but I want to make it so that only certain people can edit,add,delete certain tables or fields so data isn't accidentally changed wrongly, and so the data is read-only to the people who don't have permission to edit. Is there any way to do this? Could I even just have access to certain tables or forms password protected?
Access used to have its own security model using an MDW file, but that went away sometime ago. So the short answer is "no". If you are able to introduce SQL Server into the equation, you could store the tables in SQL (or the free version SQL Express). SQL Server offers the security model you need, and you would then link the tables from SQL Server (ODBC) to Access. In this model, SQL Server is managing your data, and Access is your "front end". Once linked, access forms, reports, etc. really don't distinguish between local or attached tables, so all of your same Access skills apply. You can export the tables from Access to SQL using the export feature within Access, and choose ODBC. I'm not sure if you're comfortable doing this, but it's really not all that difficult.
If you do use SQL Server (or Express) you would configure the users and permissions on the tables themselves, using SQL Sever Management Studio. If a user that did not have update permissions, for example, tried to update a row from an Access form, Access would fire the statement at SQL Server which would return a permission error. You could also use SQL Security to implement Windows Authentication, and assign permission to network users. When the statements were fired at SQL Server, they would be authorized based on the users login (when they logged into the network). There would be no need for them to login again.
If you decide to go this way, let me know and I can guide you through it.
Related
I am trying to establish a very secure table(s). As a matter of fact, I prefer the same settings to apply to all tables within the database. Basically, this database would contain sensitive information: PersonID, CreditCard, Names, Address, PINs.
Nobody has the need to query this database; NO person. The only thing that needs to access the database is the integration services during the ETL process. As a result, my strategy to "secure the database/table" is to limit the access to the table to just the service account for Integration Services in COMBINATION with using TDE (encryption at rest).
my questions are:
1) is this a good strategy? it's important not to allow anyone (including myself) to be able to query the database
2) how do I limit access to a table to just the service account in SSMS? I dont know how I can just give "SSIS" access and nobody else.
(I use SQL Server 2012 and SSIS 2012)
Thank you so much!!
I don't see how this would be a good solution. The problem is, someone could find out the password to the service user, resulting in access to everything. Also you couldn't restrict DBAs.
I would rather store all the information encrypted with a password that is not available to anyone. SSIS or whatever interface accesses the data would take on the role of encrypting and decrypting (if even needed). SQL Server also has some encryption options, if you don't have a corporate encryption method.
Also you could use a specific schema for the tables with sensitive data. You could by default deny permission to normal users for that db schema.
Apologies in advance for the long post, I am trying to be as clear as possible. Is there a way to disable a user / Windows AD group accessing a database via SQL Server Management Studio (SSMS)?
I have an desktop application that uses a SQL Server 2005 database. The application runs as the user logged onto the machine (unfortunately we can't change that otherwise this would be simple). The database is permissioned with groups (but it would apply to users as well) to give access to the appropriate schemas and objects that the user requires. The users have (and need) the ability to select, insert, update and delete data to complete their process.
The application carries out a series of validation and auditing steps on the user input to ensure they are entering decent data (and for some additional business processing). A user could open SSMS and make these changes through the query editor avoiding the application completely which is what we are trying to avoid. What I am looking for is a way to stop the users updating the database through any tool other than the application provided.
I have found a couple of similar posts (including How to disable SQL Server Management Studio for a user) but these don't quite cover this issue as they work on restricting user access or using different logins.
The only solution I can think of at the moment is to have a set of tables where the user data goes initially and then another process picks this up, runs the application processes on and then puts the data into the master / source tables. Then I could restrict user access to the master tables.
This appears to be a good scenario for an application role.
I have a client-server application where a .NET client accesses all the data and stored procedures in a SQL Server 2008 database.
Is there any way to protect all this data so that only the users I create and authorize can access this specific database? Especially the user 'sa' comes to mind. I don't like him to access all my data.
You cannot prevent the system admin from accessing data, nor should you.
However, no one except the designated dba should have the password for the sa account. If sa doesn't have a password or if lots of people have the password, change that now. If the application accesses through sa, change that immediately.
Other than that way you can best limit access is remove access to all other accounts from the tables and views (including select access) and only allow exec access through the stored procs. That way anyone except the designated admin can only do waht the stored procs do and nothing else. You cannot do this however if you have used any dynamic sql either inthe application or the stored procs which is one reason why dynamic sql is a poor idea.
You can't block sa or another system administrator, as access to the full system is integral to their role.
You could try encrypting the data so it's meaningless outside your application, although it might complicate any future reporting needs.
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.
We have some corporate intranet users using a WinForms app to work on a system with SQL server behind. Integrated Security is setup, allowing all users update and delete permissions, where application security limits how and where table updates take place.
However, some users are power users with SQL query tools at their disposal, and access the DB directly for building reports. However, with integrated security, they have default update rights on tables where they should not have, as the application apply rules to the updates.
Is this an example of where it's more appropriate providing the app with a central SQL authenticated login, whilst users get read only rights for integrated security?
As Jon mentioned stored procedures would give you the protection over direct table modifications. There are other options too. You can use SQL Server's "Application Role" (via sp_setapprole proc). This enables you to continue to use a separate ID for everyone but only at application connection time (through the front-end) are the user's rights elevated.
A major downside to using a shared ID is you lose track of who is submitting SQL to the server though if they're all internal you can get to the machine name.
Something else is concerning though. It sounds as if your users can connect to the database and run queries at will. You run a major risk of downtime in the application due to user behavior in the directly connected SQL sessions. If you can pull it off you may want to try to have a reporting database created that is updated at intervals that your business can tolerate, i.e., daily. HTH
I presume from the way that you've worded your question that your app executes sql statements directly. If you could refactor it so that it executes stored procedures, you could grant exec rights on the procedures and deny direct updating of the tables. This might not be possible though, depending on what your app does.
sql authentication is one option. Stored procedures are another. However, building more granular roles for assigning just the appropriate permissions to just the appropriate user types is where you should really be looking.
Additionally, I would really avoid giving these users direct access to the DB at all. Security reasons aside, it doesn't take much for a user who isn't proficient in SQL to accidentally execute a query that will swamp your database server and create an effective denial of service. Even pros can do this accidentally from time to time.
Instead, give them access to a reporting services or analysis services type solution, or use replication to give them access to a clone of the data. This way your production system is protected.
Personally I would do all application data access through stored procedures. I would set Integrated security to only allow users to run the SP's and not manipulate the data directly.
Advanced access can be given to DB admins to manipulate the data directly when needed.
Group based permissions will provide you with much more flexibility for access rights, and less administrative burden when controlling these with integrated security.