I have an application that manages user role and permission at application level not database level.
Different Tables for explaination :
User Table(Contains User details).
UserRoles Table(Defines UserRoels).
UserRole_Permission Table(Defines permission for each userrole).
User_userrole Table(Contains role of each user).(each user can only have one role)
Branch Table(Contains branch details).
Contract Table(Contains contract details).
I am using EntityFramework currently, So in order to perform any action say for example branch delete(branch_del) I check whether role to which this user is associated has permission to perform such action or not,as for below table Raj has permission but not Jay. This whole process is performed at application level(back-end) for now.
My question is how can I replicate same on database level in order to support back-end so that user should only be able to perform action for which they have permission else it should give error.
Related
Has anyone implemented a process whereby a user can submit a request for a role and that role will, after approval, be granted to that user?
So something like user fills out request form, once submitted an email is sent for approval, once approved a process is kicked off to run the grant statement and email the user that they have been granted a role.
In addition I would want that transaction logged for auditing purposes.
You could have your list of users/roles/grants on a version controlled file - and use commits to that file as a trigger to change Snowflake's configuration.
That's basically what tools like Terraform and Permifrost do.
See this discussion from dbt users:
https://discourse.getdbt.com/t/how-do-you-manage-snowflake-privileges/1397/4
This is a guide for Terraform on Snowflake:
https://guides.snowflake.com/guide/terraforming_snowflake/index.html
Meanwhile Permifrost:
Usage: permifrost run [OPTIONS] SPEC
Grant the permissions provided in the provided specification file for
specific users and roles
https://gitlab.com/gitlab-data/permifrost/
At first there is no authentication in mongodb, so I created one for one database with readWrite role.
Now I want to create more users for other databases but as this user doesn't have the privileges to create other users I'm stuck.
The documentation clearly says:
With access control enabled, ensure you have a user with userAdmin or userAdminAnyDatabase role in the admin database. This user can administrate user and roles such as: create users, grant or revoke roles from users, and create or modify customs roles.
If you haven't created such user, you cannot create it now with authentication and access rights enabled. I gues you need to restart the MongoDB server without authentication enabled, create that admin user, and restart the MongoDB server again with authentication enabled.
I highly recommend you read to complete documentation how to enable authentication first to understand the complete concept, before you follow it step by step. Otherwise it might be confusing and creating such state you are currently locked in and cannot continue with all actions.
I am new to snowflake, As a DBA I got ACCOUNTADMIN access to start with. I have granted read access on information_schema.login_history and information_schema.query_history to our security application user, via a role.
The user is able to login and query above views. However, the account is not able to see all rows when query above views. Only returns login history of that user, query history of that user. I tested it from my end, switching role from ACCOUNTADMIN to the read role I have created, and I see the same thing.
Can anyone tell me what privileges I need to grant the role, so anyone using that role can see all login history?
There are two places where you can see login history -- in the Account Usage view or using the Information Schema table functions. The documentation here explains the differences.
After reviewing the differences, many customers will opt for giving non-admins access to Account_Usage views for auditing purposes. The grants needed for this are mentioned in the documentation here.
However, if you prefer giving the non-admin role access to the Information_Schema login_history table function, you may need to give a MONITOR grant on each desired user to this role as per the article here.
You need to grant monitor privileges to said role:
grant monitor usage on account to role custom;
This information can be accessed/viewed only by account administrators. To enable users who are not account administrators to access/view this information, Snowflake provides the global MONITOR USAGE privilege. Granting the MONITOR USAGE privilege to a role allows all users who are granted the role to access this historical/usage information.
In addition, with this privilege, the SHOW DATABASES and SHOW WAREHOUSES commands return the lists of all databases and warehouses in the account, respectively, regardless of other privilege grants.
Ref: https://docs.snowflake.com/en/user-guide/security-access-control-configure.html#enabling-non-account-administrators-to-monitor-usage-and-billing-history
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.
I need to grant object privileges to a user but I'm not the owner of the schema.
I've tried doing it with the System user but I can't either.
My long shot was using the Sys user (other than System) but it is deactivated and there is no way I'll be able to activate it with my user.
Is there any way I grant that privilege to a user? I can't ask the owner of the schema to do that because she resigned today... and I don't wanna change the pwd of her DB user.
I know that at some point I'll need to create a new DBAdmin user and create a backup of those schemas because when the SAP user of my colleague be deleted, it'll delete the Hana user and the DB user with all of the objects, roles and privileges created and granted with it.
Oh oh!
Be very careful here with the deletion of the user since - as you correctly write - the deletion will have a cascading effect.
Also:
you have to either have the ownership for the objects OR the privileges you want to grant with grant option.
Using the SYSTEM user won't help with that and SYS can never be used to logon to the database anyway.
Since there is also no way to take over ownership, the only actual way really is to find out which objects and privilege grants the user has created/performed.
Then logon to the user and refactor the grants to roles that cover the object privileges.
As a next step, you may consider creating a non-logon user to own the objects and then perform a import/export of the users' objects.
Finally you may create design time roles with the required privileges to the objects. This allows granting/revoking of the privileges by a user with the ROLE ADMIN privilege, which makes management a lot easier and better structured.
Sure:
(
SELECT "SCHEMA_NAME",
'' AS "OBJECT_NAME",
'SCHEMA' AS "OBJECT_TYPE", "SCHEMA_OWNER" as "OWNER_NAME"
FROM "PUBLIC"."SCHEMAS"
WHERE SCHEMA_OWNER = 'A' UNION ALL
SELECT "SCHEMA_NAME", "OBJECT_NAME",
"OBJECT_TYPE", "OWNER_NAME" FROM "PUBLIC"."OWNERSHIP"
WHERE
"SCHEMA_NAME" IN
( SELECT "SCHEMA_NAME" from "PUBLIC"."SCHEMAS"
WHERE "SCHEMA_OWNER" = 'A' ) OR "OWNER_NAME" = 'A'
) ORDER BY "SCHEMA_NAME" ASC, "OBJECT_NAME" ASC;
You find this and lots of other useful stuff in the SAP HANA book I wrote: https://www.sap-press.com/sap-hana-administration_3506/