Limit sql azure access from an azure web app - sql-server

Question

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?)

Answer 1

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.

Answer 2

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)