We have an issue with a particular user connecting to our Serverless SQL pool via PowerBI.
I created an Azure Synapse workspace, which contains the built in serverless SQL pool which has some Views set up to pull data from some Parquet files.
As the creator of the DB I can connect to the SQL pool no problem and can model the data from the views in powerBI. However when my colleague attempts to do the same he can see the names of the views/tables but gets the following error:
He is an admin on the synapse workspace, and I've even explicitly given his user account access to the parquet files but nothing seems to make a difference.
He is able to access a dedicated SQL pool on the same account with no issues
Follow the directions here Tutorial: Create Logical Data Warehouse with serverless SQL pool
In particular for the user you need to GRANT REFERENCES ON DATABASE SCOPED CREDENTIAL. If you give the user access to the credential, they won't need direct access to the Data Lake.
Related
So, we have made a web application login protocol via which users can query a database on Azure SQL Server with sensitive data. Now partner-organizations want to use the same app to query their own databases on their own Azure SQL Server.
Is there a way where we can ensure that as admin + host of the web application we don't have access to their sensitive data, while we are able to send user from the correct Identity Provider through.
Until so far I found the OAuth 2.0 Token Introspection, specifically this implementation: https://wiki.surfnet.nl/pages/viewpage.action?pageId=23794471. Is there a way to implement this within Azure around the Azure SQL Server (if needed via a very simple API)?
Azure built-in reader role:
View all resources, but does not allow you to make any changes.
EDIT: If the problem is security you need to solve it through security countermeasure like Always Encrypted:
This provides a separation between those who own the data and can view
it, and those who manage the data but should have no access -
on-premises database administrators, cloud database operators, or
other high-privileged unauthorized users.
My team is currently test driving Azure Synapse and we are hitting some role permissions that confused us a bit.
I was given the role of "Synapse Contributor" initially so I am able to log into the workspace and look around.
BUT when I try to use the built in serverless SQL pool I hit the following error:
You don't have access to the serverless SQL pool, Built-in. To be granted access, contact a Synapse Administrator for this workspace.
Weird thing is that for a newly created dedicated SQL pool I have no problem accessing it.
Now my admin played around and gave me "Synapse SQL Adminstrator" THEN I was able to access both the serverless and dedicated SQL pools.
So Im a bit concerned as I dont want to be giving out an administrator role to every person that wants to use the serverless SQL pool.
Questions
-Is this "expected"? That anyone needing access to the serverless SQL pool needs to be given this admin role? Or is there some other role or setting we are missing?
-Secondly - How come I am able to access the dedicated SQL pool as a regular Synapse contributor BUT not able to access the serverless SQL pool?
Is this "expected"? That anyone needing access to the serverless SQL pool needs to be given this admin role? Or is there some other role or setting we are missing?
As mentioned in Official document to access Serverless SQL you need either Synapse Administrator or Synapse SQL Administrator role.
See Grant Access to SQL pools for examples of SQL scripts for granting SQL permissions in SQL pools.
How come I am able to access the dedicated SQL pool as a regular Synapse contributor BUT not able to access the serverless SQL pool?
To access Serverless SQL you need either Synapse Administrator or Synapse SQL Administrator role.
To access Dedicated SQL you need either Synapse Administrator or Synapse Contributor role.
See Synapse Roles and Scope for more understanding of Synapse Built-in Roles.
How can I limit the permissions of an Azure SQL database when accessed from an Azure web app?
Details - I am working with an Azure SQL database and creating an ASP.NET Core web app. In the web app I have put a connection string that points to the Azure SQL database. The connection string includes the server admin username and password of the Azure SQL server. The web app successfully communicates with the database and can read and write data. Now, as a safety precaution, I would like to prevent the web app from ever deleting a database table (whether this be due to a mistake in the code, or a malicious SQL injection performed on the web app). How can I set permissions on the Azure SQL database to disallow table deletions from the web app?
I have heard of Azure Active Directory; I have never used it but I gather that it is an approach to manage identities and permissions of database users. Is there something similar to manage the permission of a web app rather than a user. Or is it possible to treat the web app as a user and assign user permissions/roles to it? If so, what would be the correct approach to implement this?
(Also, while we are on the subject, aside from preventing table deletions are there some other CRUD operations that you would recommend preventing from a security perspective as a best practice?)
As Dbro said, we suggest you create a new login and user to limit the permissions of an Azure SQL database when accessed from an Azure web app.
Replace the app connection string with the new Non-administrator username and password.
And we all know, no matter which way we access or connect to the Azure SQL database, we must through the SQL account, Server administrator or new Non-administrator.
Different Azure SQL account has different permission on database operation CURD.
Fore more details, please reference Azure document Controlling and granting database access to SQL Database and SQL Data Warehouse.
When a new user you created, you can decided which database permissions to grant for the user. Please see: GRANT Database Permissions (Transact-SQL)
For security, Azure also provides the Azure Key Vault for you. To see: Always Encrypted: Protect sensitive data and store encryption keys in Azure Key Vault:
Summary:
Always Encrypted is a new data encryption technology in Azure SQL Database and SQL Server that helps protect sensitive data at rest on the server, during movement between client and server, and while the data is in use. Always Encrypted ensures that sensitive data never appears as plaintext inside the database system. After you configure data encryption, only client applications or app servers that have access to the keys can access plaintext data.
Hope this helps.
Is there something similar to manage the permission of a web app rather than a user.
Yes. It's called Managed Identities. Azure will provision an identity in your Azure Active Directory, and ensure that only code running in your Application can generate tokens for that identity. This gives you the ability to authenticate and connect to SQL Server (and other Azure Resources) without having a username/password or a client secret in your code or configuration.
See:
Azure AD managed identities for Azure resources
Managed identities for Azure resources provides Azure services with an
automatically managed identity in Azure Active Directory (Azure AD).
You can use this identity to authenticate to any service that supports
Azure AD authentication without having any credentials in your code.
Learn how to create and manage managed identities for Azure resources
with our quickstarts and tutorials.
And: Tutorial: Secure Azure SQL Database connection from App Service using a managed identity
are there some other CRUD operations that you would recommend preventing from a security perspective as a best practice
You should create a database role that has the minimal permissions required to run the application, and add your application user(s) to that role. The permissions needed will, of course, depend on what your application does, but the role might look something like this:
create role ApplicationUser
grant select,insert,update,delete,execute on schema::dbo to ApplicationUser
deny delete on AuditLog to ApplicationUser
(In SQL Server a DENY overrides any GRANTs and so you can grant permissions at the schema-level, and selectively DENY permissions at the object level)
Description
We use Azure SQL database with multiple databases on a server. It is possible to grant permissions to a single database via the user's Azure AD login by creating a group, say "DBReader". in AAD and assign the group to the role "Reader" via the server's settings in azure portal and then create a user when connected to the database as CREATE USER [DBReaders] FROM EXTERNAL PROVIDER, which will allow connecting to the single database.
Problem
We'd like to grant read access to all databases, so that the user sees all databases with a single connection and must not add them separately. Normally, you'd create a login on the server for this. However, the preview feature https://learn.microsoft.com/en-gb/sql/t-sql/statements/create-login-transact-sql?view=azuresqldb-mi-current, which would allow CREATE LOGIN ... FROM EXTERNAL PROVIDER is not available for Azure SQL database.
Question
Is there any way we did not think of to simply grant access to all databases via an AAD group?
Is there any way we did not think of to simply grant access to all databases via an AAD group?
No. Outside of Managed Instance, which requires a minimum of 4 vCores, Azure SQL Database users must be added to each database.
A suitable solution would involve the user to being able to see all databases he has permissions to at once
For Azure SQL Database, this requires the client to connect to Master to, and then reconenct to switch databases. SQL Server Management Studio does this, but other clients may not.
I have created Extended event session for azure database from my local sql server management studio and storing resulting file in azure blob storage.
but when i start extended event session it giving me an following error :
I have follow all the steps properly for creating extended events storage account with following steps:
1.Created shared access signature for container storage.
2.Created credential in SQL server using following script :
CREATE DATABASE SCOPED CREDENTIAL [Cre_Name]
WITH IDENTITY='SHARED ACCESS SIGNATURE',
SECRET = 'shared access signature of blob container'
GO
3.In extended event screen i used credential created in step 2.
Also i found that Filestream data is not supported in current version of azure storage. Is this is cause of error?
https://msdn.microsoft.com/en-in/library/dn385720.aspx
You have created wrong storage account, create as "General" rather than "blob". I have the same problem and this fix it
Also i found that Filestream data is not supported in current version of azure storage. Is this cause of error?
No,It is not cause of the error. But It may cause we can’t view the session data directly that session data in the azure storage. As forester123 mentioned, it may be related to the target data itself.The following is my detail steps：
Create an Azure SQL Virtual machine [SQL 2016]
Create an Azure SQL Database
In the Azure SQL Virtual machine, connect the azure SQL Database via Microsoft SQL Management Studio
Create Database Scoped Credential for the azure SQL database.
Create the session Extended events ->Sessions -> New session Wizard
Start the session and check the file from azure storage and file status is locked.
The session can start the correctly.