Background: I built a Razor Pages web app that connects to Azure SQL DB and have successfully set up Azure AD single sign on. I have a DB context class which use AD interactive authentication, but when I publish the app to the Web App Service, I have to configure the Azure SQL DB dependency and I am forced to hard-code a username and password.
I have created users and logins in the DB and also utilize RLS as not all users have a need to see all data in certain tables, so I want to retain the security measures already in place.
Problem: Because the username and password are hard-coded all users will be able to see, edit, delete information they shouldn't, so I need to configure pass-through authentication to the DB.
Anyone have examples on how to achieve this?
Edit: Just how you can configure Power BI to have end users use their own credentials to access the SQL DB, I need to this with my web app.
If you want to protect the username and password, some other way is that you can store the SQL database connection string to the Azure Key Vault, then use secret key name to connect to the SQL database.
Example ref: Spring boot application that would read configuration from Key vault and connect to SQL?
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.
I've got an Azure App Service that needs access to a classic SQL Server (non-Azure SQL, not SQL Managed Instance) and I'd prefer to do this via System Managed Identity. This is enabled on the App Service and a corresponding Enterprise Application is created on Azure AD.
The SQL Server is also connected to this Azure AD and User accounts on the AD already have access to the database. However I can't find how to create a login for the Enterprise Application. If this was an Azure SQL database I could do it with CREATE LOGIN [AZUREAD\app] FROM EXTERNAL PROVIDER but this does not work on a classic SQL Server, only on Azure SQL/MI.
A solution would be to use SQL accounts and reference the login/password in the connection strings, but as mentioned I'd much rather use Azure AD for authentication.
To answer my own question: SQL Server 2022 includes Azure AD authentication Link
Using integrated security or an access token it will be possible to authenticate with an App Registration.
This is currently in preview with no RTM date specified.
On AWS an application can access a database by attaching an IAM role that allows access.
Or an application can access the database by obtaining passwords from the secret manager.
In what use cases would one use IAM or a secret manager to connect their DB and Application?
Secrets Manager is just storing your database password. You would be reading the password from Secrets Manager, and then connecting to the database with username/password. The fact that you are storing the password in Secrets Manager is kind of irrelevant. Your question should actually be stated something like this:
What are the advantages of using AWS IAM authentication for RDS databases, instead of the default username/password authentication.
In answer to that question, the primary benefit is that you can use IAM roles attached to EC2/ECS/EKS/Lambda to provide database authentication credentials, instead of having to separately configure those resources with a database password somehow.
You also don't have to worry about rotating the database passwords periodically if you are using IAM authentication.
As far as I know, IAM are used for inter-cloud application access. Unless you want a user role created with access to DB and then assuming the user role to connect to DB. This is the case if your application runs in cloud.
Also this is the case mostly for cloud native DB's like Dynamodb.
For RDS Databases we usually use passwords.
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)
Scenario: In an intranet application, ADFS uses AD for authentication(Account Store) and Sql server for authorization(roles/Attribute Store).
The roles are my own application specific. There are other applications that need to use ADFS. If ADFS is configured to use my SQL Server to fetch roles, what would other applications do? How will they manage their authorization?
Is my understanding correct? If yes, please verify my answer:
Ans: ADFS just returns me the AD identifier(SID/Name).I map this to my sql server roles. Role management should be done by my own application connecting to Sql server. Use session to prevent hitting DB for authorization every time.
To avoid hitting the SQL server for every authorization check, you could implement claims based authentication. Use the SQL attribute store to add your role claims to the AD user ID claims. The resulting claims ticket (SAML) is sent as a cookie and isn't fetched on every authentication check as it is kept as a cookie by the user browser available to the server on each and every request. The timeout/refresh can be set by ajusting the claims ticket TTL (time to live).Just a suggestion... =o)