Would every user who uses my database have a role? Is it more administrators who will have roles, people who need access to all the tables?
Also, I am unable to offer table-level privileges to a role and offer that to a user.. it just won't work. I have to offer the privileges directly onto the user for them to work. Is that normal? Should I be able to offer table-level privileges to a role or do I have to manually offer each of my users the table level privileges?
Would every user who uses my database have a role?
That depends on how you (or, should I rather say, DBA) set it up.
Quite a long time ago, say until Oracle 8i, there were 2 very popular roles: connect and resource so when DBA created a new user, they simply ran
grant connect, resource to new_user;
and the new_user was ready to go as those roles provided most needed privileges such as create session, create table or create view (check documentation for more info about those predefined roles).
However, it turned out that not everyone should be granted e.g. create cluster (which is one of connect's privileges) so nowadays you should create your own roles, if you want - then grant certain privileges to those roles and, finally, grant roles to your users.
Another option is to keep .sql scripts for each of your users. That script should contain list of privileges granted to those users, separately, which means that you shouldn't granted anyone privilege they don't really need.
I am unable to offer table-level privileges to a role and offer that to a user. it just won't work. I have to offer the privileges directly onto the user for them to work. Is that normal?
It works, but not everywhere. Those privileges (the ones granted via roles) won't work in named PL/SQL procedures (i.e. stored procedures, functions, packages). If you have to use those tables in them, yes - you have to grant privileges directly to each of those users.
As opposed to named PL/SQL procedures, privileges granted via roles will work in anonymous PL/SQL blocks or at SQL level.
If you're wondering why would you use roles at all, then, the answer is my first sentence: it depends.
Related
I have only seen examples of SQL statements granting users access to one database in a Postgres cluster at a time. Is there a way to grant a non-superuser access to all databases and their tables including future databases that get created in the cluster?
Since PostgreSQL v14, this is fairly easy, and you can use the following SQL script:
-- exempt the user from row level security
ALTER ROLE seeall BYPASSRLS;
-- allow the user to read all data
GRANT read_all_data TO seeall;
If you want write access as well, there is also a predefined role pg_write_all_data.
This relies on the fact that by default, everybody has the CONNECT privilege on databases. Of course you also have to configure pg_hba.conf to allow access.
And in case you wonder: no, before v14 you have to grant access to all objects individually. Group roles help with that.
When I scan my database, it shows one of the result like VA1143 'dbo' user should not be used for normal service operation in A Vulnerability Assessment scan
They have suggested to "Create users with low privileges to access the DB and any data stored in it with the appropriate set of permissions."
I have browse regarding the same to all form but cannot get the correct suggestion yet. Could you please suggested your idea or where i have to create the user and grand the permission. Since we have only one schema structure in our DB.
About "Create users with low privileges to access the DB and any data stored in it with the appropriate set of permissions.", the first thing you should know is the Database-Level Roles.
Create users with low privileges means that the use does not have the alter database permission.
When we create the user for the database, we need to grant the roles to it to control it's permission to the database.
For example, bellow the the code which create a read-only user for SQL database:
--Create login in master DB
USE master
CREATE LOGIN reader WITH PASSWORD = '<enterStrongPasswordHere>';
--create user in user DB
USE Mydatabase
CREATE USER reader FOR LOGIN reader;
GO
--set the user reader as readonly user
EXEC sp_addrolemember 'db_datareader', 'reader';
For more details, please reference:
Authorizing database access to authenticated users to SQL Database
and Azure Synapse Analytics using logins and user accounts
Hope this helps.
When designing and building databases, one the principal mechanisms for security must be the "least privilege principal". This means that you only give permissions that are absolutely necessary. No application should need to be the database owner in order to operate. This role should be highly restricted to only administration types. Instead, you create a more limited role for the application. It can include access to every single table, all the procedures, but it won't be able to do things like, for example, drop the database.
This is step one to a defense in depth of your system in order to properly and appropriately secure it. It helps with all levels of security issues from simple access to SQL Injection. That's why it's included as part of the vulnerability assessment. It's a real vulnerability.
Yes resolved the issue after creating the least privilege role and assigned to the user. But its leading to different below vulnerable issue's for the newly added user with least privilege role. Any lead will be helpful on this
1.VA2130 Track all users with access to the database
2. VA2109 - Minimal set of principals should be members of fixed low impact database roles
I have an Oracle DB and I am using the system username. Using C# I created a few tables using the system username/password. When I log into sql developer and view the privileges on that table, it does not show the system user (which has a dba role and a MGMT_USER role) as having select/insert/update/delete permissions (or any permissions for that matter).
"You may not GRANT/REVOKE privileges to/from yourself"
Why does my admin user not have access to these tables and how do I get it?
What #TenG said - you can't grant privs on objects you own to yourself - you have those privs inherently as the OWNER.
More importantly, DO NOT use the SYSTEM account to create objects, especially don't create them IN the SYSTEM schema.
Use SYSTEM to create your application user, log in as THAT user, and THEN create your objects.
In Oracle, being the owner of the means you have implicit grants on the tables.
No need to grant privs to yourself on your own objects.
I am new to oracle. I need to get the scheduled jobs in my database.
I queried
DBA_SCHEDULER_JOBS,
DBA_SCHEDULER_SCHEDULES, DBA_SCHEDULER_PROGRAMS,
DBA_SCHEDULER_JOB_CLASSES, DBA_JOBS.
But Oracle issues the error
"ORA-00942: table or view does not exist".
When I queried ALL_JOBS and USER_JOBS no rows are retrieved. Please suggest me which table should I see.
The DBA views are restricted. So you won't be able to query them unless you're connected as a DBA or similarly privileged user.
The ALL views show you the information you're allowed to see. Normally that would be jobs you've submitted, unless you have additional privileges.
The privileges you need are defined in the Admin Guide. Find out more.
So, either you need a DBA account or you need to chat with your DBA team about getting access to the information you need.
I think you need the SCHEDULER_ADMIN role to see the dba_scheduler tables (however this may grant you too may rights)
see: http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/schedadmin001.htm
Because the SCHEDULER_ADMIN role is a powerful role allowing a grantee to execute code as any user, you should consider granting individual Scheduler system privileges instead. Object and system privileges are granted using regular SQL grant syntax. An example is if the database administrator issues the following statement:
GRANT CREATE JOB TO scott;
After this statement is executed, scott can create jobs, schedules, or programs in his schema.
copied from http://docs.oracle.com/cd/B19306_01/server.102/b14231/schedadmin.htm#i1006239
I've moved to creating/using schemas in Sql Server 2005, where I've also created database roles and assigned schemas to the roles.
The problem I have is one of the db roles I have should have full access - say SuperSysRole.
However, when I assign a login to that role, it cannot execute specific commands. In particular, I want a user within this role to manage password resets. However, when I execute the stored procedure, it does not return back all users in the database.
The stored procedure has been run which returns back the details and calls a view which integrates the sysusers and sysmembers tables.
The user, say myAdmin, has been assigned to the role SuperSysRole. The role SuperSysRole has been granted execute to the stored procedure selectRoles.
It's probably a simple thing but can someone please tell me what I am missing?
My application authenticates using the myAdmin user name and password. It works fine when I login with the sa account.
Database role membership is queryable through the sys.database_principals and sys.database_role_members catalog views, which are the proper catalog views to use instead of the deprecated sysusers and sysmembers. Both have the same security restrictions:
In SQL Server 2005 and later versions,
the visibility of the metadata in
catalog views is limited to securables
that a user either owns or on which
the user has been granted some
permission.
The necessary permissions are listed in GRANT Database Principal Permissions: VIEW DEFINITION. There is no permission that can be granted to view any principal and role definition.
Your best option is to create a procedure that selects from the proper metadata catalog views and sign this procedure with a credential that is added into the db_securityadmin role. See Signing an Activated Procedure for an example how to sign a procedure. The grant EXECUTE on this procedure to whoever required to view these principals and role memberships.
However, all of this will get you nowhere with regard with the declared intent: manage password resets. Only server principals (aka. logins) have passwords, and any scheme designed at the database principals level can have no effect on server principals, since they are the wrong abstraction. And since there are no server roles to define (you can only have Windows groups as roles, but you want to use SQL Auth), you cannot have this done by role membership.
My recommendation is, again, to use code signing. Create procedures that do the activities you want (query sys.server_principals and sys.sql_logins to inspect password expiration, issue ALTER LOGIN statements to reset passwords etc) then use code signing to sign these procedures and grant the required privileges to the signature. I refer you again to Signing an activated procedure for an example how to do that. Then grant EXECUTE on these procedures to the 'special' users that have to manage these.