I am new to SQL server and now I have a database with thousands of tables stored. I want to replicate this database and pass this replica to other vendors, but for security concern, I would like to mask all the fields in the tables. The vendors don't really care about what has stored in the table but they do care about the structures or distributions about the tables.
The idea is to copy the current database and do masking then. But I don't know if SQL server has provided this technique to simplify the process. Appreciate it for any comments or suggestions!
Just deny view definition permission to the user who will access the database using the below query :-
USE master
GO
DENY VIEW ANY DEFINITION TO User1
Once you deny this permission to User1, all objects such as table,SP,view etc will be hidden in the database and at the sametime user1 will be able to do whatever he wants if he knows the object.
This will mask the all objects from the user.
Related
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.
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 am transitioning a project from Advantage Database Server to MS SQL server. In Advantage, you can password protect an individual table, which is also encrypted. As such, you cannot open, view, update, etc. the table without the password. I place my project's registration information in this table, so I don't want any user to be able to look at its contents.
I cannot find a similar function in SQL server. Encrypting the data is insufficient. So my question is: is there a way to password protect a table in SQL Server.
In SQL server you can link various access roles to the users. These roles can be applied to tables, views, stored procedures etc. The best thing to do is to create views on the database, and let the users access specific views, rather than giving permissions on all DB objects.
Alternatively, you can deny permissions on a specific table to a user or a role.
Here are two articles on MSDN that will get you started:
GRANT Object Permissions
DENY Object Permissions
I have MS Access as a front end and PostgreSQL as back end for my database. So I set up the database in PostgreSQL and linked the tables to MS Access using the ODBC drivers. Everything works great, I can update the tables in MS Access and the record will appear in Postgres database.
Since I can still see the linked tables in MS Access, I feel like it is possible for some users to go in and manually modify the tables without filling out proper forms. Is it possible to HIDE the tables or lock the tables so that Access users cannot modify the raw data at all? If not, what can I do to secure the integrity of the database.
Thanks!
I would recommend looking at Postgres privileges as a way to lock the tables down.
In short, you could have your backend run as one user that has full access permissions on the tables in question, and when the users login to the app, they would be connected to Postgres using a user whose privileges are considerably more locked down (say, read only if you just want to be able to do SELECTs to surface data).
For example, you could run the following SQL against your Postgres server:
REVOKE ALL ON accounts FROM joe;
GRANT SELECT ON accounts TO joe;
Which would first remove all privileges from the user joe for the table accounts, and then allow only SELECT priveleges for that table.
You could do something similar for all the tables you wish to lock down. You'll also need to do the same for the sequences used by those tables.
You may wish to create a special readonly user which has only read access across the board, and use those credentials to surface the Postgres data for the users to access.
When you need to alter data, your backend could specifically use a power user of sorts which has much greater access.
Here's a link which details creating a readonly Postgres user (for purposes of backups in this case, but the general concept and the SQL commands should apply (just ignore the stuff about pg_dump).
If you aren't concerned about users' ability to modify the data in those tables via the up other than in the ways that are authorized, but are only concerned about them using, say, psql to go in and update them, then you probably don't need a readonly user, but can simply lock the tables down and have the backend use that user with sufficient access.
whats the best way to grant access to a few users to a couple tables in a SQL Server 2005 database?
I know the literature pushes the use of views but what is the gain over granting read only access to the actual table?
at least with the table there will be less overhead in that the index and other restraints are already in place and managed at the table (a single point of maintenance). If I make views then won't i need to maintain them and create indexes on them... as well as this will be additional overhead for SQL itself?
CREATE ROLE role_name
GRANT SELECT ON table_name TO role_name
Don't forget to add users to that role. Adding individual permissions is generally a bad practice.
Using views and giving permissions to the view is useful if you want to hide particular columns / name columns in different ways / otherwise filter the data.