Using SQL Server (2008), is it possible to grant a specific user full control of the objects under a specific schema? This includes create/drop/alert table. Its important that this user isn't not given db_ddladmin role because that would give him access to other tables.
You can create a role in the database, assign all appropriate permissions(SELECT, UPDATE, DELETE, EXECUTE, etc.) to the role, and then assign the user to that role.
Related
We have build a streaming pipeline that has the rights to create new tables in snowflake when they are created in the source system. (running under the role PROD_EL_ROLE)
Even though we have time travel enabled 'for backup', I want to prevent the PROD_EL_ROLE itself from being able to 'accidentally' DROP tables. AFAIK, this cannot be done directly as the creator of a table in snowflake is also the owner, and thus, is also allowed to drop the table
What I tried in addition, is to transfer the owner to another role higher in our RBAC hierarchy (PROD_SYSADMIN_ROLE) . This unfortunately only works by using REVOKE GRANTS, which is not what we want as with the creating of a table under PROD_EL_ROLE various privileges are auto-created by various FUTURE GRANTS. And we obviously don't want to remove them.
If I use COPY GRANTS, it does not work due to the PROD_EL_ROLE not having the MANAGE GRANTS right. Which is a grant we obviously do not want to give to PROD_EL_ROLE...
I only want to prevent table dropping by PROD_EL_ROLE
Any idea how to solve this?
To follow the DAC concept, you own the object created then you can customise grants to it, so no way to prevent dropping it unless a higher role in same RBAC hierarchy claims ownership, and grant back some or ALL privileges of the object to that role.
So, for your requirement here another separate process/user need use PROD_SYSADMIN_ROLE to claim objects ownership and grant back ALL PRIVILEGES on that object to role PROD_EL_ROLE
USE ROLE PROD_SYSADMIN_ROLE;
grant ownership on ALL TABLES in SCHEMA TESTDB.TESTSCHEMA
TO ROLE PROD_SYSADMIN_ROLE;
grant ALL PRIVILEGES on ALL TABLES in SCHEMA TESTDB.TESTSCHEMA
TO ROLE PROD_EL_ROLE;
Now the role PROD_EL_ROLE can do all DML operations but no DDL operations on it again (dropping/modifying the definition of the object).
Can we grant direct select or insert access( with out creating a role ) to a user on a table ?
No, you cannot. Snowflake uses Role-based Access Control (RBAC):
https://docs.snowflake.com/en/user-guide/security-access-control-overview.html#access-control-framework
Therefore, all access on a table should be granted through a role.
https://docs.snowflake.com/en/sql-reference/ddl-user-security.html#access-control-management
Of course you can use "existing roles" instead of "creating a new one".
The short answer is NO - you can only grant access to a ROLE - never directly to a USER.
In Snowflake, everything is accessed via a ROLE. See this diagram:
RBAC: USERS, ROLES and SECURABLE OBJECTS
From this article: https://www.analytics.today/blog/introducing-snowflake-rbac
In summary:
USERS are granted one or more ROLES
A ROLE is granted PRIVILEGES (for example, insert, update, delete) on SECURABLE OBJECTS (for example a TABLE or VIEW)
Even the concept of OWNERSHIP is different in Snowflake. Every USER with the same ROLE shares access to the OBJECTS. This has some unusual results.
For example:
If a USER creates a TABLE - everyone with the same ROLE has OWNERSHIP on the table.
You can read more about Snowflake RBAC on this article - which also links to another two which explain best practices on how to deploy. https://www.analytics.today/blog/introducing-snowflake-rbac
CREATE OR REPLACE DATABASE "Orders";
I did not set any permissions on this database. Another person at my company ran the SQL above and replaced the data. How can I prevent this from happening in the future using the permissions in Snowflake?
TL;DR: The global privilege CREATE DATABASE in Snowflake permits a user/role to run such a statement. Removing it requires designing a role based access system and revoking administrative level rights from existing users.
At the very minimum, severely restrict the users who are allowed to run statements as ACCOUNTADMIN, SECURITYADMIN or SYSADMIN roles. Revoke these privileges from the set of users you want to prevent from performing DATABASE level operations:
REVOKE accountadmin FROM USER other_user1;
REVOKE securityadmin FROM USER other_user1;
REVOKE sysadmin FROM USER other_user1;
REVOKE accountadmin FROM USER other_user2;
REVOKE securityadmin FROM USER other_user2;
REVOKE sysadmin FROM USER other_user2;
(… repeat for all users that need to be limited …)
Next, design custom roles and define a desired level of accesses over them. Also decide which usernames will belong to each role depending on their function in your organization.
The following is a very generic and basic example just for illustrative purposes that divides all "Orders" database users into two levels of access. Specific needs will vary depending on your organization's unique situation.
CREATE ROLE orders_read_and_write;
CREATE ROLE orders_read_only;
-- Snowflake recommends you create a hierarchy of roles so you can allow any
-- SYSADMIN-allowed users to manage these newly created roles instead of
-- requiring an ACCOUNTADMIN level user to do so in future
GRANT ROLE orders_read_and_write TO ROLE sysadmin;
GRANT ROLE orders_read_only TO ROLE sysadmin;
The two roles orders_read_and_write and orders_read_only created above can then be granted privileges appropriately to control their level of access for schema and tables under the "Orders" database. Continuing the example:
-- Allow both these roles to access schema and tables under "Orders" DB
-- This does not allow them to perform any DB-level operations
-- such as replacing/overwriting it
GRANT USAGE ON DATABASE "Orders" TO ROLE orders_read_and_write;
GRANT USAGE ON DATABASE "Orders" TO ROLE orders_read_only;
-- Allow read and write access appropriately to schema under the DB
-- Note the difference on using ALL vs. USAGE in the privilege granted
-- to each role here:
GRANT ALL ON SCHEMA "Orders"."SCHEMA-NAME" TO ROLE orders_read_and_write;
GRANT USAGE ON SCHEMA "Orders"."SCHEMA-NAME" TO ROLE orders_read_only;
GRANT SELECT
ON ALL TABLES IN SCHEMA "Orders"."SCHEMA-NAME"
TO ROLE orders_read_only;
Finally, grant the roles to their respective username(s).
GRANT ROLE orders_read_and_write TO USER other_user_1;
GRANT ROLE orders_read_only TO USER other_user_2;
(…)
Any role lacking the CREATE DATABASE level privilege will no longer be able to perform a statement such as CREATE OR REPLACE DATABASE "Orders";.
In the above example, both roles only receive USAGE level access on the Orders database, which does not permit them to run such statements anymore.
If you ever need to permit such a privilege to a role, you can GRANT it explicitly to the role of choice that has trusted users under it:
GRANT CREATE DATABASE TO ROLE role_name;
I highly recommend going over Snowflake's Access Controls feature section a few times to get acclimated to the terminology. This makes it easier to implement and manage effective access controls in your organization.
Note: Introducing access control is a wide-impacting change and will require communication and coordination within your organization to be truly effective. It is always difficult to remove freedoms as this may be ingrained into scripts and programs already in use.
How can I give a user (who was created WITHOUT LOGIN) full control over a contained database without having to specify that database's name, like GRANT CONTROL ON DATABASE::DatabaseName TO UserName, but without using a database name? I figure it'll include GRANT ALTER ANY SCHEMA TO UserName, but I'm not sure what else I'd need to grant, or if there's a better way. Thanks.
If you literally want them to be able to do anything in that database, you can just add them to the db_owner role:
USE ContainedDatabase;
GO
ALTER ROLE db_owner ADD MEMBER [username];
If you want to be more granular, you can add them to lesser roles, like db_ddladmin, db_securityadmin, etc. You can see the list of built-in roles here:
Database-Level Roles
The permissions inherent in each of those roles:
Permissions of Fixed Database Roles
And if those don't suit, you can create your own roles, add your user to that role, and grant specific permissions to that role you created (and/or add them to other roles). The difference between applying the permissions to the role instead of directly to the user is simply reuse - if you add five more users that you want to apply the same permissions, you just add them to the custom role, rather than apply those granular permissions or roles to all 5 of the users.
Open SQL Server Management Studio and connect to your server.
In the Object Explorer, expand the "Security" folder under the server.
Right click on the "Logins" folder and choose "New Login..."
Add the users name in the format "Domain\UserName". You can also add domain groups by just changing it to "Domain\GroupName".
5.If you would like this user to have full access to the SQL Server instance, you can choose the "Server Roles" tab. Adding the role "sysadmin" will give them full access to the server to do actions like update the database, backup the database, delete the database.
Click ok and your user will be created and have access to your database.
Choose the "User Mapping" tab. In the top half of this screen, check the box next to the database name. Once you highlight the database and check the box to map the user to it, you can add role memberships to the user. For access to the database.
Click ok and your user will be created and have access to your database.
I just finished creating a new user for my database in SQL Server. I had 4 tables I wanted to grant Insert, Update, Select and delete permissions. I did this manually in the Securables area of the new user.
Is there a better way to do this that to have to touch each object? if so, how?
Thanks,
rod.
One way is use schemas such that
tables belong to a schema (let's call it data, CREATE SCHEMA)
users belong to a role (CREATE ROLE, sp_addrolemember)
permissions are assigned to the role on the schema (GRANT INSERT ON schema::data to myRole)
Now, you can add new tables or change users without losing/creating permissions
If you want finely granular control over who can do what, I don't think there's a whole lot you can do - you're doing it just fine.
gbn's approach is quite nifty - another approach for "simple" setups (when you don't need a whole lot of different permissions) is to:
grant every user (or a role) the database role db_datareader - this allows read access
(SELECT) on all tables and views
grant every user (or a role) the database role db_datawriter - this allows write access (INSERT, UPDATE, DELETE) on all tables and views
If you also need to grant execution rights on stored procedures, there's unfortunately no predefined role to use. You can however create your own database role and then grant execute permissions to that role. The great thing is: this permission to execute stored procedures also applies to all future stored procedure you might create in your database!
To define your new role, use this:
CREATE ROLE db_executor
GRANT EXECUTE TO [db_executor]
and then you can just assign db_executor to those users who need to be able to execute stored procs and stored functions in your database.