Like the title says, Nicolas and I have over the years, taken umbrage in how easy it is to do things in Entra ID.
And because of that, we felt that we had to voice our opinions about what issues we have with Applications living inside of your Microsoft environment. For those of you that have watched the VOD or attended the webinar, this post serves to list everything we spoke about in the episode. It's also more how we went about defining our issues. And to do that, we have to start at the beginning.
It's simple really, and that is probably part of the problem. When adding a cloud-native application to your Azure subscription, it can be done in a myriad of ways:
This is the traditional method of running an application. You head over to application registrations in Entra ID, and you create a new application.
Figure 1: Registered Application
Now, this is harmless, until you add an application to it. We’ll talk about the different application types further down.
Yes, as long as you have an account that has the right access, you can create, manage, update, and delete applications living inside of Azure.
Figure 2: Visual Studio Code, App registration extension
This is concerning because developers do not necessarily lead with a security-first approach for hosting applications.
3rd Party applications, no problem. As long as the vendor has published the application to the gallery, you can select it, and deploy it.
Figure 3: Application Gallery in Entra ID
Again, a very simple process. You select the application, follow the prompts, and it magically adds the application to your subscription. Way too easy. Do organizations ask for the security posture of a 3rd party application from, let's say, Workday? Unlike in the old days, where we would scrutinize what gets deployed.
If you know a little bit of PowerShell, and you have the right access, you can spin up an application, using Graph.
Figure 4: Graph PowerShell script
With very little scripting, you can deploy an application into your Azure subscription.
There are a few other ways that you can also get applications running in Azure, like using an Azure template from GitHub. My point is, there are multiple vectors when having to worry about how applications are deployed. And they all have specific considerations, based on the type of application that gets deployed. Which brings us to the next section.
Application types dictate the functionality of the application you want to use in Azure. Let's have a look at what they are:
Single-page apps (SPA), which are web apps whose code is downloaded and run in the browser
Web apps, or traditional web apps, whose code runs on a server
Web APIs, which are RESTful web services accessed by apps or other web APIs
Desktop/Mobile apps, which are apps with a user interface (UI) whose code runs on a user’s device
Background services, daemons, or scripts, which are apps without a UI that perform non-interactive tasks
These applications have different types of authentication mechanisms. These authentication mechanisms include the following:
Microsoft Entra accounts
Microsoft personal accounts
Social accounts like Facebook and Google
Users from partner organisations in a business-to-business (B2B) scenario
Custom sign-up and sign-in experiences for customers in a business-to-customer (B2C) scenario
OAuth and OpenID Connect
These authentication providers use different standards when authenticating user accounts against the application you deployed.
Added to that, you would use Microsoft Graph, on top of the application context, to provide more authentication into other applications that your application may have to interact with. Think of a web application that needs to talk to a database to retrieve or store data. This would normally be done through Graph:
Programmatic Access to Permissions
Types of Permissions
Admin Consent
OpenID Permission
And because we have to mention AI, the same process needs to be followed when deploying AI applications in Azure.
Figure 5: Microsoft’s AI shared responsibility model
You even have to care about Artificial Intelligence running in your environment.
So where does this leave us? Well, now that we’ve explained how applications get deployed in your environment, what should you do to ensure those applications are secure?
This is why we have a series focus on preventive maintenance. It's why Nic and I drone on and on about making sure that your applications are secure. It almost feels like we are Entra ID’s nagging parents that scream at our children to “pick up your clothes,” and “put the toothpaste cap back on,” etc.
Over the last 3 years, delivering episodes on application governance and security, we believe that there are things you should be focusing on. And not only us, this is straight from Microsoft themselves. In no order of importance, go do these things:
Redirect URI
Maintaining ownership and control of Redirect URIs prevents application compromise..
Avoiding insecure URI schemes (like HTTP) and wildcard reply URLs enhances security.
Access Tokens
Using Auth code flow instead of implicit flow reduces the risk of token compromise.
Turning off the setting to receive access tokens via implicit flow, if not actively used, protects against misuse.
Certs and Secrets
Using certificate credentials instead of password secrets improves security.
Using Key Vault with managed identities helps securely manage credentials.
App ID URI
Using default URIs for v1.0 access tokens ensures compatibility.
Using the Application ID URI to expose the Web API, rather than to identify the application, is a security best practice.
App Ownership
Limiting application ownership to a minimal set of people within the organization reduces the risk of compromise.
Regularly reviewing the owners list ensures that only current and appropriate personnel have control.
Integration Assistant
It highlights best practices and recommendations to help avoid common oversights when integrating with the Microsoft identity platform.
But what is application security without an application governance plan? You definitely need to make sure that you have a strategy that supports your application security needs. This plan would generally be defined upfront, so that when it comes to securing applications, you have specific use cases that drive what you need to lock down, to be secure.
And you don’t have to trust us, because Microsoft has created what this should look like. You can read about it here.
At a high level it looks like this:
Prerequisites/Standards for accessing an application
Access duration - how long do they need access for
Organization Role Model - defining users based on their use cases
Separation of duties - making sure that people have access to only the info they need
Conditional Access - evaluate the signals from the identity and device (Top TIP)
Exception handling - are you able to adjust based on a specific use case
And there you have it people. Nic and I's simple/not so simple approach to making sure that your applications are managed and more importantly, better secure in your Microsoft environment.
The biggest problem in our minds? Figuring out where to start. So follow these steps and interrogate those pesky little applications that are living rent free in your environment.
And remember, it’s always about “What’s Graph, What’s Graph got to do with it?”
Where exactly do you start with this 'app interrogation'!?
If you're looking for an immediate next step to streamline and simplify your application governance journey, request your ENow AppGov Score. The ENow AppGov Score is a free security assessment tool that quantifies your organization’s Microsoft Entra ID application governance state. It gives an organization a starting point to understand potential risks associated with enterprise applications, app registrations, permissions, and default tenant settings within your Entra environment. Strengthen your application governance and security posture - start now!