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.
Related
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
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.
Microsoft's docs on schema ownership don't go beyond saying "Schemas can be owned by any database principal, and a single principal can own multiple schemas." (MSDN doc)
I get that schemas are a way of containing different security permissions, but what is the purpose of assigning an owner to a schema and what special privileges does that user who owns the schema receive as opposed to simply being a member of the schema?
An owner of a schema is like the sysadmin within that schema, can create , drop, select , update, delete , alter objects, give permissions to other users , revoker permissions of other users and pretty much everything .
On the other hand a user with in a schema can only do the operations according to what database role was given to them , for example will be assigned these permission as Permission to create objects, db_datareader can only issue select statements against tables, db_datawriter can do inserts/updates and the list goes on.
You dont want every user who has access to database to do all sorts of operations, some people will have less access some will requires more access, hence the different roles to suit user specific needs.
Ownership of schema has it roots with the problem we had in past before sql server 2005 when there were no schemas and objects were owned by users. To separate users from objects schemas were introduced and the concept of "Schema Ownership" was introduced, it is just another way of saying that this user has all the permissions in a schema.
Our SQL administrator is currently ill and in the hospital however we have an upcoming security audit from the SQL cluster. Therefore we would like to grant the security auditor now read only access so that he can see all settings (primary which DB has which settings and which users are created). But the auditor shouldn´t have any rights to access DB content. Could that be performed? If yes how?
As Per my understanding you are looking for this solution where you want only definition access to user not the data reader operation access.
If this is the case then You can do it using GRANT Schema Permissions (Transact-SQL)
The VIEW DEFINITION permission lets a user see the metadata of the securable on which the permission is granted. However, VIEW DEFINITION permission does not confer access to the securable itself. For example, a user that is granted only VIEW DEFINITION permission on a table can see metadata related to the table in the sys.objects catalog view. However, without additional permissions such as SELECT or CONTROL, the user cannot read data from the table.
For more details go through the link
For grant access to different functionality of SQL Server you can go through the following link
GRANT PERMISSION
I create a schema and set schema owner on it.
what the owner can do as owner that a user with permission can't do?
why the schema need owner?
Unless designed by means of permissions being in place, by default there is little difference. I.e. on a stock SQL Server installation, the owner and a regular user would have similar permissions set up. The difference being that the owner cannot be dropped from the database, and normal users cannot revoke permissions or privileges from an owner.
From Microsoft Docs:
You cannot remove privileges from an object owner, and you cannot drop
users from a database if they own objects in it.
Things get more interesting once specific permissions have been set up, though. Imagine normal users are denied permission to read data from tables. The owner in that case would be able to see the data in table, while regular users would not.