Azure Synapse Analytics
-
Support Always encrypted in SQL Data warehouse
Always Encrypted makes the data to be only available to client side applications and not visible to Database administrators also. It makes the data to be more secure. It is especially needed in the case of Azure, where PII data is stored in cloud.
50 votesThanks for your suggestion. We are looking into this scenario for a future release. 6386782
-
Support EXECUTE AS for stored procedures
As part of the ELT procedure the user staging data should be able to call a transform procedure to ingest the data without having read/write permissions to the production tables.
29 votesThanks for your feedback. Azure SQL Data Warehouse Support for EXECUTE AS feature is now in progress.
-
Use the same CREATE USER command as Azure SQL DB
Currently, Azure SQL DB supports a version of CREATE USER that allows an SPN to connect to the database via an access token and create Azure AD users. Azure SQL DW does not, and fails with an error from Azure AD. SQL DW requires an authenticated AD user be logged into the database directly and issue the CREATE USER command.
Making this function work the same on both platforms will allow a single DevOps deployment to create either DB and DW resources, as well as configure users for those resources, from within the deployment script.
12 votes -
Transparent Data Encryption (TDE) by default for Studio-created SQL Pools
Any SQL Pool I create while in the Studio, will not have TDE enabled by default. I believe this should be the default. At the very least, it should be an option in the "Additional Settings" page.
8 votes -
Enable Row Level Security in combination with Resultset cache
Please enable Row Level Security in combination with the use of resultset cache. We use Row Level Security a lot in PowerBI (DirectQuery mode), but this means we cannot get the performance improvements of Resultset cache. Every click in PowerBI arrives on our Synapse as well (instead of being taken by the Resultset cache)
7 votes -
default port
Configure SQL Data Warehouse to listen on a port that is different from the default 1433 port such as port 80 and/or port 443.
7 votes -
Hide schema objects based on role
We want to hide dbo and other custom schemas from users. We have stage, test, dbo, etc. objects in the DW. We would like to limit the schemas and/or objects that we expose to them through SQL Roles. We can limit their ability to query a certain schema, but I want to limit their ability to see it
5 votes -
Database auditing functionality in APS
Currently SQL DW and SQL Server allow one to audit database access. This functionality does not exist in APS. Please provide the ability to audit data access in APS as well.
4 votes -
Grantable Schema-level truncate permission
Need schema level TRUNCATE access so roles for ETL processes can be granted TRUNCATE in addition to INSERT/UPDATE/DELETE and said ETL processes don't have to own the table targeted for the TRUNCATE operation.
3 votes -
Support Security Option to grant non-admin user access to catalog views and DMVs
Support Security option to grant non-admin users access to catalog views and DMVs (without making them db_owner, effectively)
3 votes -
[In Preview]Support column level encryption and decryption based on security rules.
At this time Synapse warehouse does not support or give a method to decrypt a single column based on algorithm like AES.
The idea is I should be able to encrypt sensitive columns in a file (bolb) outside of the database load it as is to warehouse. Once loaded I can define rules for each user and provide feature like decrypt the column if the user is allowed by fetching key from Key vault else show encrypted value for data protection.2 votes -
API calls from SQL DW
We need to decrypt client side encrypted data while retrieving data from SQL DW via API calls .Currently I don't see any feature in DW which supports this .Any plans to add this or any work arounds currently available for handling this kind of scenarios
2 votes -
database level firewall
The following documentation states that a database level firewall works for Azure SQL DW databases:
https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-set-database-firewall-rule-azure-sql-databaseHowever, running the syntax mentioned results in the error:
Msg 15165, Level 16, State 1, Line 1
Could not find object 'spsetdatabasefirewallrule' or you do not have permission.Please add or fix support for the database-level firewall in Azure SQL DW
2 votesThanks for reporting this. We are looking into this. 10703354
-
Support ALTER AUTHORIZATION for all relevant object classes
Need to be able to change the ownership of any object in ADW that has an owner. For example a ROLE. Currently only DATABASE, SCHEMA, and OBJECT are suported.
2 votes -
[In Preview]support column level encryption in synapse
There is a gdpr requirement to store privacy data encrypted in the db, existing SQL versions support this with column level security, synapse is unable to maintain this level of security.
1 vote -
exception of fire wall rule by trusted Azure Service
We should need a exception of fire wall rule that allows accessing from trusted Azure Service same as Storage Account.
1 vote -
Please enable the ability to read audit files in ADW
There is no counter part to the system function sys.fngetaudit_file (Azure and on premise SQL Server) in ADW. Please enable it to read audit files in ADW.
1 vote -
Visual Stuido ADW connection shows Admin user name
Hi,
When you connect to azure dw or db using VS data tool, the connection windows displays database's admin login as default. can we change this not show the admin user name?thanks
1 vote -
SQL DW password policy profiles
We have multi-factor authentication (MFA) for AAD. Tableau and other tools connecting to data sources via ODBC cannot accommodate MFA. We can create local accounts in Azure SQL Server and SQL DW, but MUST CHANGE, CHECK EXPIRATION, and CHECK POLICY are not supported. We need to be able to enforce and report compliance with password security policies.
1 vote -
Create specific API REST operation for scaling instead of using the generic POST
Because the scaling operation is included in the generic write operation, if we need to configure a least privileges permission we would need to add the ability to create and update a database, which is way more than allowing just to scale a database.
1 vote
- Don't see your idea?