I'm curious if there is a way for a user to use a view in database A (they have permission to database A) that accesses tables in database B (and/or additional databases they don't have permission to) without the user having access to database B?
My scenario:
We currently have a database (database A) where most of the views are housed. Most users across the team also have access to database A. We are wanting to split out our data tables from database A into their own databases (on the same server). When we do this, of course, the views will break because the tables they access will now be in database B. Since there are so many views, I'm looking for an easier way. My thought was to use database A as the hub for the views and as the views are accessed, permissions are granted to the various databases for the user(s) - without giving them direct access to the other databases.
Thank you in advance.
I think a database role would be better than a database as the container for view access.
It might be easier to delete objects than to move them. A backup-restore can create a copy of the database. Then delete the tables and views that don't belong in each database.
Cutting corners on security or integration can come back to bite. If the tables are distinctly part of different systems, then the views should go with the tables. Security and integration between systems by cross database references will tie all those systems to the same server. (Linked servers would be a performance and DTC nightmare.) We have several "separate" justice applications (e.g., DA, Public Defender, Probation, etc.) that do this. Security is still detailed via the use of database roles for each use. The integration is great, but it's a nightmare to migrate because it's all at once and together. If done correctly (e.g., connections strings to each database), we would be able to move one database at a time and update and test one system at a time. As it is now, it takes a lot of project management and a long time to get everybody ready.
If the tables are part of the same system, then schemas could be an option to segregate them if database roles are to tedious to manage. Is it more work to segregate the objects into databases or schemas than to manage a role?
Also, if you use SSDT db projects, then those cross database references (circular?) can be a pain.
For security, I would suggest a database role for each group that needs access. There is no "magic" database level container just for views. The best you can do is SELECT which includes tables and views. For just views, a script is not hard to create to grant a db role select access to all views in the db. I would not ever use grant select and then a DENY on tables because it can prevent access to table for users that should have access. If one or more schemas are used for the views, a role can be granted SELECT access to the schema. This might be the best option. If the view schema and the objects accessed by the view have the same owner, the ownership chain should allow access via the view to tables. For example, if the "view" schema is owned by "dbo", views in the "view" schema should be able to access tables in the "dbo" schema without the user being granted access to those tables. (I have not tried it.)
It would be nice if there was a second flavor of INSERT, UPDATE, etc. permissions that applied to views only, but there isn't.
Related
I am new to SQL Server database and I am struggling to figure out the access issue for one of the user on a particular view. I don't want to expose any of my base tables.
The scenario is: I have 3 databases, DB one, two and three
Database one has 2 base tables
Database two has one view on top of those tables (tables in database one)
Database three has one view which is on top of the view of database two
Database three is our data warehouse. So, I would like to know if I give select permission on only database three's view, will that suffice?
The catch is I don't want to expose any of my base tables in database one
If I grant select permission to user1 on datawarehouse view (view in database three) and deny all the permissions to the base tables (in database 1), then is it possible?
Thanks
Ownership chaining allows access to data via the view without permissions on the underlying tables as long as all objects are owned by the same security principal. There is no need for an explicit GRANT or DENY on the indirectly used objects with an unbroken ownership chain since permissions are checked only on the directly access view. The object owner is typically inherited from the schema owner.
To allow ownership chaining to extend across multiple database:
The DB_CHAINING database option must be ON for the databases involved.
The user must be able to use the databases (have a user account in each database with CONNECT permissions), although only permissions on directly accessed objects are needed.
In the case of dbo-owned objects, the databases must be owned by the same login (AUTHORIZATION) since the dbo schema owner is the database owner. For other schemas, the schema owner must map to the same login.
DB_CHAINING should be enabled only when you fully trust highly-privileged users (those with permissions to create database objects).
I read a write up about database schema.
A SQL Server schema is a container of objects. For example you may have a large enterprise application and then is a good practice to use different schemas for different purposes (e.g. put HR related tables into HR schema, accounting related tables into Accounting schema and so on). A schema can be owned by any user, and the ownership is transferable.
They said: use different schemas for different purposes (e.g. put HR related tables into HR schema, accounting related tables into Accounting schema and so on)
Do they mean create new database for HR and again new database for accounting?
Because when we create a database then a single schema is created so we cannot create multiple schema in single SQL Server database as far I know.
So please tell me how is it possible to create different schemas for different purposes in a single database? Thanks
Purpose of Schema
Schemas in sql server were introduced in sql server 2005, The main purpose was to eliminate User's ownership of objects in sql server. or you can say to separate users from objects in sql server.
Prior to Sql server 2005 objects in sql server (Tables, views, Store proceders etc) were owned by users. Typically the user who created it.
And that user had to give permissions to other users to use that particular object.
Imagine a scenario where 12 developers are working in a company and all developers are creating sql objects left, right centre. Now all the developers had to give permissions to other 11 developers if they had to work objects created by that one developer. quite a bit of mess isnt it??
Since sql server 2005 came with Schema. All the objects were Owned by a Schema Not a User. if you havent created any custom schema it will be under default Schema dbo.
Now anyone who has permission to dbo schema has permission to any object under dbo schema.
Why it is a good idea to create different schemas for different departments in your case. It may be because HR people doesnt need to know anything about Finance stuff. so you can create a HR schema and give HR people permission only on HR schema. and vice versa with finance people. That will restrict their access to only objects related to their departments.
And we can create multiple Schemas in one database if you have ever worked with Adventureworks database, it has Schemas like 'Production', 'Sales' etc etc.
Read here to learn more about schemas in sql server.
No they mean create a schema. Create schema works within a database. There are all sorts of uses for it, I tend to think of it as either namespacing or a more natural way of partitioning a smallish database and keeping role based access, where you can think of schema as a user group.
Unfortunately, there are two meanings to the word "schema" in the database world.
One means the overall design of the database tables. "Show me your database schema", for example. This would be the collection of "create table" commands, or and ERD diagram.
The other is a synonym for "namespace", which the article in question is referring to. You can store tables, functions etc in different namespaces to ease cognitive load or use for security grouping.
I am using SQL Server 2008R2 and one of the things I am trying to do is allow users read-only access to some of the tables in one of the DBs via MS Access ODBC so that they cna build their own reports, etc (Their request). The problem is that they can see all of the system views /tables (information_schema and merge replication stuff). Is there anyway that I can revoke these so that all they can see are the tables /views I designate as available for selection?
Not sure what I can do to limit what they see as "available".
Thanks,
S
Put them on the public role, and only give SELECT permission to the tables/views you want.
You can't stop them from seeing the system views but you can stop them viewing what those views return. If they don't have permission on the table, sys.tables will not return that table.
I'm working with a database (let's call it DB_data) that contains all of the tables for a series of applications. In an attempt to minimize downtime during upgrades, a facade database (let's call it DB_facade) has been created which has a view for each of the tables in DB_data. It also contains all of the functions and stored procedures, which work against these views.
In trying to lock down security in DB_data we've done a DENY on all of the tables for all of the users in DB_data. All of these users have also been created in DB_facade with permissions to the views.
The problem here, is that because of cross-database ownership chaining the DENYs in DB_data are overriding the GRANTs in DB_facade.
I'd like to avoid turning on ownership chaining for both of these databases because of the potential security issues (although in my original tests, that did seem to correct the access problem). Also, we're trying to minimize impact to the applications, so requiring all access to be through stored procedures and using certificates (for example) wouldn't work.
Does anyone have any other suggestions on how to handle this?
Thanks!
Do you have this problem if you exclude the DENY on the tables in DB_data? If you don't explicitly GRANT permissions on these tables, you may be able to get the security you need and get the access rights through the views.
from what i've seen and done, sql server doesn't let you have any permissions unless explicitly told so. You should be able to grant select (or use the role datareader) in DB_Data to the users, and as long as it's the same account and it's mapped to both databases (you'll have to grant select and exec on db_facade) that should work just fine.
You can create a view in the DB_data database for each view in the DB_facade database. The new views would have rights to select from the tables. GRANT SELECT on the views in DB_data. Change the views on DB_facade to SELECT from the views on DB_data. And, the tables would have DENY set.
I recognize one disadvantage to this; the users can still interact with the DB_data database. They wouldn't be able to access the tables, but they could access the new views.
In SQL Server 2005, a snapshot of a database can be created that allows read-only access to a database, even when the database is in "recovery pending" mode. One use case for this capability is in creating a reporting database that references a copy of a production database, which is kept current through log-shipping.
In this scenario, how can I implement security on the "snapshot" database that is different from the "production" source database?
For example, in the production database, all access to data is through stored procedures, while in the snapshot database users are allowed to select from table in the database for reporting purposes. The problem the I see is that security for the snapshot database is inherited from the source database, and can not be changed because snapshots are strictly read-only.
Are you able to manage permissions on this database? Would adding a separate user who only has read access to a database be sufficient for this type of scenario? This could be a read-only user on the main database, but is only effectively used on the snapshot db.
i.e. Add a new user, readerMan5000 who is only given select access, to the database in question. Then require users to authenticate through that new credential.
Note to future commenters, you may want to read:
http://www.simple-talk.com/sql/database-administration/sql-server-2005-snapshots/
or
http://msdn.microsoft.com/en-us/library/ms187054(SQL.90).aspx
before you open your big mouth like me. :)
You can't change permissions after you take the snapshot, but here's one workaround: instead of having them access the tables directly, require them to use views instead. If the views are used only for reporting, then you can set tight security on them in the original database, and then have the users hit those views in the snapshot. You'll need to restrict access on the underlying tables though if you want it to be effective.