Is there any experience with Azure Managed Identity performance vs let's say basic authentication.
I am testing managed identity implementation in a microservices environment and observing some degradation compared to basic auth between these services.
I conducted some testing and found that Managed identity performance is same or better than basic authentication.
Can you please explain the scenario a bit more?
What do you mean by performance here? What are you trying to measure?
The biggest advantage of using Azure Managed Identities is that you do NOT have to manage any credentials in your code. You are free from rotating any credentials. You don't have access to the credential, so you cannot accidently leak it either.
Otherwise, Managed identities are same as any other identity in Azure AD. Read more at https://aka.ms/managedidentity
Related
We have developed an SQL based application for Motorsport and some of our clients are looking at Azure to hold the database. Trouble is they travel around the world to races and as such will need to access the database using what-ever Internet connection they have and cannot pre-define IP addresses in Firewall rules. Is it possible to effectively disable the Azure firewall so that they just need to enter login credentials to the SQL server rather than having to be on specific IP address ranges?
Given the whole idea of the SQL database is access anywhere it is difficult to believe that you have to define access based on IP addresses but I can't find anything which suggests otherwise!
Before giving you mode advice on security, to answer your question, Yes you can allow All inbound to your Azure SQL Database using the following T-SQL
EXECUTE sp_set_database_firewall_rule N'Allow Azure', '0.0.0.0', '255.255.255.255';
The range above allows all. This basically means this range is permitted to pass through firewall. This is for database-level firewall rule. For logical server-level rule, just setting the rule as follows
If database-level firewall rule is not set, the logical server-level rule is applied first.
First, giving direct access to your database over the Internet is a very bad practice from security perspective. Business/End-users are not often well trained in security awareness and the very high chance their computers are compromised. There are some approaches you should consider doing to improve security:
Use built-in Azure SQL Database security feature in Azure such as Transparent Data Encryption (TDE) to always encrypt your databases. If possible, use Azure Key Vault to store the encryption master key to add more encryption layer to the "whole" world. Another feature is Dynamic Data Masking but I don't think it is useful since you allow database access level. Of course, masking some fields is worth considering. Plus, enable Threat Detection to monitor if any anomaly queries (e.g. SQL Injection).
Integrate with Azure Active Directory to monitor access identity. Every access which is authenticated by Azure AD can be monitored and notified. In Azure AD, have a look at Conditional Access policy to see whether it is applicable to your business users. Saying all business users only travel to just a list of countries usually or they use managed computers. Azure AD (Premium) also gives you Sign-In Risk functionality which combines both Analaytics and Machine Learning to identify if a sign-in is potentially risky (from unknown person). If looking at Azure AD as an option, and more stronger then consider Azure AD Universal with Multi-factor authentication options.
Establish an Azure VNET, then configure Point-to-Site (P2S) VPN to your Azure SQL Database. Fortunately recently Microsoft announces the ability to control inbound to your Azure SQL Database inside a given VNET. After setting P2S VPN, give to your business users certificate. Such a certificate needs to be installed on business users' laptop before they can connect to the VNET. Attackers without having access to their computers have no way to connect to your Azure SQL Database.
Add an application layer (e.g. ASP.NET) and login page to let your business user access from this web application. This perhaps adds development efforts but this can help to eliminate at least some direct attack to your database connection string such as brute-force. In the application, handle SQL query to reduce direct SQL Injection. This way requires in-depth understanding of development.
If financial budget is limited, I'd highly suggest you to apply Azure AD and VNET first. Below is the cost drafting:
Azure VPN Gateway: $29.2/month ($0.04/hour * 730). Basic plan is enough. The plan supports up to 128 P2S connections. If your number of business users are greater than 128, just create a new VPN Gateway.
Azure AD: if you target to Free plan, you can store up to 500,000 users. If you like to use Conditional Access and reporting, you need to pay $6/user/month for Premium P1 plan
Azure SQL Database Auditing & Threat Detection: $15/logical server/month. If Auditing is enabled, you are charged Blob storage but the cost for Blob should not really a concern.
Azure App Service: if adding an application layer. The cost is around $60-70/month for small plan (Basic or Standard). Cost also includes development and deployment effort.
What I've said here may add more concerns on the effort, cost to build. Well, I'd leave that decision consideration to you. Just one thing, think about data breaches and your business reputation if an incident happens. The cost would be much more than the implementation.
I strongly advise against it, but if it's development database, you can create an AllowAll rule in the Firewall: How can I allow unknown users to access my SQL (Azure) DB?
Better option, is to use a VPN server so that the users have to log in to the VPN to have access to the database. This way the Db is not accessible to everyone. You can further secure the VPN by adding a sign in certificate so only owners of the certificate can log in to VPN.
My guess is that you have several options:
securing the database with Azure Active Directory users. Each user can login tot the database with specific rights you could also make them readers and disabling the firewall. You could even implement row level security.
Create a Azure API application that performs the actions on the database. Let the users login with there credentials to the api and pass those credentials to SQL server.
I think that in combination with row level security is one of the most secured options. On my blog: msftplayground I created a set of articles about it.
Currently I have a website which uses MS SQL 2008 and the Microsoft Membership Provider to create/authenticate users, this works fine.
We have migrated all of our 'data' over to Neo4j, which has gone really well and everything works, but we are not sure at this point the best way of managing the authentication system.
So the question is, what is the standard way to store/retrieve credentials and other sensitive information and perform authentication using a graph database.
Is it ideal to store the credentials data in the graph, or should we still use MSSQL and the Membership provider we already have?
The authentication feature introduced in Neo4j 2.2 is just a "all or nothing" based on username / password.
If you need a more fine grained approach you need to implement your own security rules.
I have a question that really feels like I should have an easy answer to, but for one reason or another I haven't been able to totally reason around it.
I'm embarking on development of an ASP.NET MVC3 intranet application, and I'm currently working on designing authentication & authorization. We're forced to use basic authentication in our environment, and we use Active Directory, so the authorization part is generally taken care of. Unfortunately our role/user hierarchy in active directory doesn't mirror what I need for the roles in the application, so I'm going to have to define my own.
I'm using SQL Server, so I was originally thinking of using stored procedures for all DML, and then creating roles and adding users in roles in SQL Server, and then controlling access to the stored procedures via those roles. I was also thinking I could query for those SQL Server database-level users & roles in order to use that as the source of authorization info in the application itself. That originally seemed like a great idea, but it doesn't seem like a popular one (for one, it seems the queries for that are a little long and messy for what they produce). Alternatively, would it be better to have the web app impersonate a user for all queries to the server, and then implement a user/role database with my own schema, and only authorize on the application side?
It originally seemed that authorizing on both the application and database side would be a good thing for security, and using the SQL Server user/role objects means that the user and role data wouldn't need to be stored in two places.
I did see some potentially relevant discussion at Best practice on users/roles on SQL Server for a web application, but I think this is a different question overall.
Thanks!
I recommend creating a sql login that the web application will use to connect to sql server. This way you are not impersonating any specific AD account which may get deleted, disabled in the future and can control the user strickly in SQL Server.
I would then recommend implementing roles based authentication in your application. This will enable you to create users and roles that are custom to your application and then assign users to them. This way if a user tries to access a resource that their role is not allowed it will not do any work. Here is a demo app based on this principle http://www.codeproject.com/KB/web-security/rolesbasedauthentication.aspx.
I'm working on a website (asp.net c# with SQL Server) and the client is asking for SSO solution. I'm looking to use one shortest implementation where we can create sub-domains for different modules and install/deploy on same or different servers but all of these module/application uses same SQL Server and session is also maintained and shared by SQL Server. However the client is concerned about the performance/scalability and security therefore I would like your advise if you have already worked on such projects and if you would recommend me this solution or anything else.
thank you in advance for your help !
Keep your single sign on information in LDAP. It's definitely the most standardized way to store user information and access. It's really just a database but if scalability and performance are concerns this is your best bet.
What is the best option for a windows application that uses SQL server authentication? Should I create a single SQL account and manage the users inside the application (using a users table). Or should I create a SQL server account for each user. What is your experience? Thank you!
Depends on whether the username/password for the SQL server would be exposed to the user, and whether that would be a problem. Generally for internal apps (in smaller organisations), one would trust the users not too log in directly to the sql server. If you have a middleware layer (ie webservices) the password can be hidden from user.
I prefer to use a general login for the DB and manage users in the application. Even if you do create a login to sql for each application user, they could still connect directly, so why not just use a generic sql login that is easier to manage. This is of course assuming all users have the same accesses.
One good practice, if the users potentially can get direct access to the db, would be to grant access only through Stored Procedures and not directly to tables, so that only certain actions can be performed. Steer away from writing business logic or security checks (except basic ones) within the stored procs.
One way I would solve your problem is to write some webservices that check security and does your CRUD (via datasets, etc), but again it depends on the app and environment.
In summary if you have a middle layer or all users have the same access manage the user within the application and use a single user login. Otherwise use a login per user or role.
One option that I have used in the past is to use the ASP.NET Membership Provider. It makes authentication a breeze to use. The only drawback that I saw was that it added a bunch of tables to your database.
The code for using it is very straight-forward.
Here's a blog post about using this in a Windows app. http://msmvps.com/blogs/theproblemsolver/archive/2006/01/12/80905.aspx Here's another article with more details. http://www.c-sharpcorner.com/UploadFile/jmcfet/Provider-basedASP.NET10162006104542AM/Provider-basedASP.NET.aspx
Here's another article that talks about using it with Windows applications: http://www.theproblemsolver.nl/usingthemembershipproviderinwinforms.htm
Google for "ASP.NET 2.0 Membership Provider", and you will get plenty of hits.
What about having SQL accounts based on the level of permissions needed for the task. For example you could have a read only account just used for reporting if your system has a lot of reporting. You would also need an account what has write access for people to change their passwords and other user admin tasks.
If you have situations where certain users are only going to have access to certain data I would have separate accounts for that data. The problem with using 1 account is you are saying that there is no SQL injection anywhere in your application. That is something everyone would strive for but sometimes perfect security is not possible, hence the multi-pronged approach.