Is there a way to find out which tables and stored procedures a user has accessed? Note that this is what the user has actually accessed and not what they can access.
For tables, is it also possible to know whether the access was read or write?
I would like this information to determine which database privileges can be removed for this user.
It is possible, but not for the past. On SQL Server 2014, you can setup specific monitoring tasks (called "audititing"), so that from now on you can collect the access data you want.
Related
Here is what I am trying to accomplish with SQL Server, is this possible, and if so, what is the best approach?
Move all tables from the dbo schema, or change permissions to view only for anything but a stored procedure
Only stored procedures will have access to write and update the tables within the schema, dbo or a private schema.
I am doing this because I am the only dev in my company who has any type of database management experience; the other devs just edit tables live, create and update willy-nilly. I am coming in as a senior and am trying to prevent direct table create/update/delete; I believe all creates and updates should be managed through a stored procedure to help maintain data integrity and ensure proper time stamps are updated.
Is doing something like this possible? If so, what is the best approach?
I work in my companies small IT department. I have been creating automation via VBA in Excel to pull data from SQL and put it into Excel, then dynamically format and summarize the data. The issue I am running into is the IT department does not want to give anyone outside the IT department SQL Read-Only Access. They view SQL as a privilege not a right...even if it is only Read-Only. They claim security reasons.
Just to be clear, we are NOT installing SQL on these peoples' computers nor do they have the technical understanding on how to write queries. Also, they can already view all the information on the front-end website.
I currently have to specify which database and which tables they can have access to and it takes about 1-2 weeks to give them access (they drag their feet doing the requests).
I am not trying to vent, I am actually wondering do they have a legit concern about security and is this actually a best practice on their part?
The worst thing that could happen is a user knows just enough to connect MS Access to the database, write some poor queries, and grind everything to a halt. You should always have non-IT users access data in a safe, structured way. Especially if this database is a transactional one, and not a reporting database.
Sure, they can access all the data per business process. So then, create a nice, safe query to read all the data and dump it to Excel - if that's what the users want.
Otherwise, IT-created queries - preferably in Stored Procedures - should be reading the data and presenting it to the users.
So it's not a security issue per se. It's more an issue of "we don't want non-IT users getting crafty and bringing down the database with poorly written queries."
I believe the connection properties to the SQL server is embedded in your VBA code, as long as the code is not visible to the user then there is no way they can query the SQL server directly.
Sounds like you need an SQL read only service account which you can use for Query connections. Create an Excel data connection that has the security details to connect to SQL, then your VBA hooks into that data connection.
We have a SQL Server 2012 instance which is the database for our security system. Now we have a scenario where we want to allow another team our SQL Server to select certain records, ie we created four views for them for their requirements.
But, we don't want to provide or list all our tables to them but only allow these four views to see and query in our system. As I go through many documents it's clear that we can do it through making our SQL Server as a linked server.
What's the best way to do it through a linked server?
Are the views in a specific schema?
Try to grant the users access to that schema, so that they can only read and see meta from it.
https://learn.microsoft.com/en-us/sql/relational-databases/security/metadata-visibility-configuration
we don't want to provide or list all our tables to them but only
allow these four views to see and query in our system.
You don't need linked server to accomplish this.
All you need is to grant SELECT permission on these 4 views.
When you create a user in a database and don't grant any permission to it, it does not see any user table/view at all. And it will be able to see and query only those objects on which you'll grant the permissions
I am not sure what the correct forum is for a question like this, so if it would go better on a different one could you move it there please?
I have split my database into a front and back-end database. The front end is using linked tables which are linked to the back-end real tables. If a user changes something in a table on the front-end database, the changes are carried over to the backend database.
Why is this and how can I prevent this from happening? Is there a way to change the settings to make the database read only? Whether it's through VBA or not, I would accept either answer.
That's a feature, not a bug. You're using a linked table, it's linked.
If you want a separate table, make a separate table, and make some ETL (extract/transform/load) process to keep the two tables in sync as needed, accordingly with whatever business rules you need to implement.
If your Access DB is connecting to SQL Server via SQL authentication, you could have the SQL user on the SQL Server side only authorized to SELECT, and denied UPDATE, DELETE and INSERT permissions. Expect errors on the Access side when the linked table is modified then.
I want to give access to certain data, in various databases on a single sql instance, to our parent company. They don't want a web service but instead want a stored procedure, which would compile data from different data sources and return a record set.
There is a trust between our two domains so essentially they are on our domain and I will just give the required permissions to sql objects (stored procedures)
I plan to create an 'integration' database which would have the required stored procedures.
While the integration database will have no tables itself, at least for now, I do want to lock the database down so that there are no holes such as the parent company being able to create tables on database or affect permissions etc.
What is the recommended approach to lock my 'integration' database down such that the parent company only has access to run the stored procedures I explicity give permissions to.
As a sql DBA I make a good .net programmer ie from what I understand it will require the user of commands such as GRANT EXECUTE ON [procedure] TO [user] to grant permissions on selected stored procedures, but beyond this I am not sure of a clear strategy to achieve what I need.
I want to make sure I don't leave holes in the security.
If anyone can advise the steps I need to take, ie what commands I need to run to achieve what I want, or point me to a good article I would appreciate it.
I have already run the command REVOKE CONNECT FROM GUEST on the database.
What is the recommended approach to lock my 'integration' database down such that the parent company only has access to run the stored procedures I explicitly give permissions to.
Create a role specifically for the users from the parent company
Only grant EXECUTE to the role for the specific store procedure(s)
Grant the role the db_datareader role -- that will make sure they can't create tables, etc.