Is there any way to make user or role specific triggers in Azure Synapse or azure DW?
You do not need a trigger for this. Users can only do what you allow them to do. For example, when you first create a user in the database, they have no permissions. Users can only drop tables if they are members of the database role db_ddladmin or they are effectively db_owner or sysadmins. So the answer to your question is, make sure that user is not a member of the db_ddladmin role in the database.
You can look at using the DENY statement for certain roles but I think that would lead to an over-complicated setup that is hard to maintain and administer. See the Database Roles documentation for Synapse for more info.
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
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.
I am not so into SQL Server and I have the following doubt: I have to require the creation of an user that can work on some databases. This user have to create\delete table, insert\delete records in these tables.
What type of permission have to be set for this user on these databases? Is dbowner ok to perform these operations? (in particular is very important that this user can create\delete tables) or am I missing something?
Just to understand first the benefits of using roles :
Roles are a part of the tiered security model:
Login security—Connecting to the server
Database security—Getting access to the database
Database objects—Getting access to individual database objects and
data**
Predefined database roles
You may need to create your own, but you have access to several predefined database roles:
db_owner: Members have full access.
db_accessadmin: Members can manage Windows groups and SQL Server
logins.
db_datareader: Members can read all data.
db_datawriter: Members can add, delete, or modify data in the tables.
db_ddladmin: allows a user to create, drop, or modify any objects within a database, regardless of who owns.
db_securityadmin: Members can modify role membership and manage
permissions.
db_bckupoperator: Members can back up the database.
db_denydatareader: Members can’t view data within the database.
db_denydatawriter: Members can’t change or delete data in tables or
views.
Fixed roles :
The fixed server roles are applied serverwide, and there are several predefined server roles:
SysAdmin: Any member can perform any action on the server.
ServerAdmin: Any member can set configuration options on the server.
SetupAdmin: Any member can manage linked servers and SQL Server
startup options and tasks.
Security Admin: Any member can manage server security.
ProcessAdmin: Any member can kill processes running on SQL Server.
DbCreator: Any member can create, alter, drop, and restore databases.
DiskAdmin: Any member can manage SQL Server disk files.
BulkAdmin: Any member can run the bulk insert command.
From the SQL Documentation:
Members of the db_owner fixed database role can perform all
configuration and maintenance activities on the database, and can also
drop the database in SQL Server.
Are you certain that is the right that you want to grant this user? It seems like a more restricted set of permissions would be more suitable for them.
For example, the roles db_ddladmin, db_datareader, and db_datawriter could be more suitable:
db_ddladmin:
Members of the db_ddladmin fixed database role can run any Data
Definition Language (DDL) command in a database.
db_datareader:
Members of the db_datareader fixed database role can read all data
from all user tables.
db_datawriter:
Members of the db_datawriter fixed database role can add, delete, or
change data in all user tables.
Alternatively, you can grant specific privileges to the user account against that database and it's user objects in order to restrict their access to the functionality subset you want.
I am trying to provide DBAdmin privilege for a user on multiple databases.
I know how to do from on premises SQL database, I can directly map the user to required databases.
Can anyone let me know how to do it in Azure managed instance. Since the added user is external user, can,t see it in the Logins to map the user.
I have like 100 databases on which the user should have db admin right. Is there a easiest way to do that?
You can use an Azure Active Directory Login
eg
CREATE LOGIN [someuser#somecompany.onmicrosoft.com] FROM EXTERNAL PROVIDER
then create users mapped to this login in the appropriate databases, or make this login a sysadmin. Not sure if this shows up in SSMS, as it was added relatively recently. So you may have to create the users and grant them permissions in the target databases in TSQL, as per: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance-aad-security-tutorial