Contact Us

Entra ID Security Best Practices

How to protect your Entra ID user identities
04 Dec 2023

Securing Entra ID – Best Practices for 2024

At Keytos, we’re not shy about saying, “we set the bar high” when it comes to identity security. As a self-professed leader in the space, it’s really what our whole business is about. Securing identities and data. In this post, we’re going to delve into our rigorous approach to securing our Entra ID-based cloud infrastructure to not only align with but exceed the highest industry standards. …Did I mention we’re SOC2 Compliant and our tools are FIPS Inside Validated? Continue reading if you’re interested in learning how the ex-Microsoft Cloud Security Engineers go about locking down their infrastructure.

Fully Passwordless Entra ID Environment w/ Unphishable Credentials

While Entra provides a few identity security features like conditional access and risky logins, no account is truly secure until there is absolutely no password to steal. To protect against identities being compromised or stolen, we have gone fully passwordless for all our user accounts as well as our machine identities. You’d be surprised how easily this is accomplished, but as they say, “With the right tool, any job is easy.” (or something like that) …That’s why we suggest having a look at the best passwordless onboarding tool for Azure, EZCMS. …You’d be surprised how much money you’ll save! In the spirit of “zero trust,” we’re going to assume you don’t believe how easy it truly is. That said, take a look at how this small business made the move in just a couple days:

Protect User Authentication: Go Passwordless

If we’re getting right into it, there’s basically two (primary) ways in which you can achieve true passwordless user authentication within your Entra ID environment. “Smartcard” authentication (which is really CBA) and FIDO2.

At Keytos, we employ both authentication methods as we’ve found this to be the most practical approach for our organization. Let me tell you why…While FIDO2 has been the industry standard for quite some time now, there are still many cases (even in Entra ID) where it is not accepted. We found that FIDO2 + CBA covers all the authentication scenarios we encounter here at Keytos. Once again, very easy to set up; just check out the best passwordless onboarding tool for Entra, EZCMS.

Passwordless Machine Identities

I’d guess that 99.9% of the general population isn’t aware that passwords are still the riskiest attack vector for MACHINES! So, to keep our precious babies safe, we’ve chosen to utilize Azure Managed Service Identities (MSI) these identities are fully passwordless identities that are managed by Microsoft, making it very easy to authenticate with other Microsoft services.

In the somewhat-unlikely event that there’s a scenario in which MSIs are not supported (cross tenant authentication, apps hosted outside of Azure like a customer’s on-prem server), we use Azure Service Principals with certificate-based authentication. Unlike with MSIs, or regular certificate-based authentication, authentication for Service Principals requires you to register each new certificate in Azure before it can be used. Think certificate expiration related outages are going to be a problem? Think again! We offer auto-rotation for Azure AD Applications as part of EZCA.

Identity Isolation in Entra ID

As an organization that is accountable for running critical services for companies across the globe, we’re contractually (and morally) obligated to maintain the absolute gold standard of security. At Keytos, we strive to go WAY above-and-beyond what is considered to be top-notch standards by following Microsoft’s Identity Best Practices. We’ve created our own isolated “Production” tenant that has ZERO connection or trust with our “Corporate” Tenant. What does that mean? Should anyone’s corporate account become compromised, the Phisher (digital bad guy) wouldn’t obtain access to the Keytos production resources. Adding this insulation to our resources exponentially reduces the risk of an incident and adheres to zero trust best practices.

Device Isolation in Entra ID

Now that we’ve covered identity isolation, which is a great start, let’s take a peek at another terribly vulnerable vector, Devices. Hackers continue to become increasingly sophisticated in their attempts and have started attacking organizations with malware. Basically, they’re trying to steal your credentials or access resources using your computer. To mitigate this risk, we have implemented a modern version of the Microsoft PAW model. Instead of leveraging legacy on-premises technology, such as domain controllers, we use Intune to manage the devices and Azure conditional access to attest device health prior to login.

Just in Time (JIT) Access

Something we don’t think about often enough is, should everyone have access to Production all the time? Historically, they have, but just because it’s always been that way, should we continue doing it? Although we are very confident on our secure identity and device story, we also believe humans should not access production unless it is necessary. This does not only improve security, but by making access to production harder, it also promotes good engineering practices for deployment automation and self-healing features that improve our reliability and productivity. To enforce this, we have implemented no standing access to production. If an engineer needs to access any production resources, they must request access to the resources through Microsoft PIM or through EZSSH for our Linux endpoints.

How to Protect the DevOps Pipeline

In a direct response to strengthening our posture on authentication and production access, hackers have decided to “move left” on the software supply chain, and they’ve got GitHub in their sights. To prevent these attacks and protect our infrastructure, we extend our already secure AAD identity to GitHub for SSO. While this is a great first step to protect our code, it only protects against actions created in the GitHub site; however, as you most likely know, most privileged git activities happen over SSH. To protect our SSH access to GitHub, we use EZGit, the first GitHub SSH Certificate Authority. This gives our engineers just in time access to the code, ensuring that every time they push or pull code, they are doing it from a computer that meets our conditional access policies in Azure AD.

That being said and considered, DevOps security does not stop when you commit the code. We need to be aware that Supply Chain attacks are on the rise and things like compromising open-source build packages used by GitHub actions are one way you’re vulnerable. To protect our artifacts from these types of attacks, we use Step Security’s harden-runner to monitor and block these attacks.

Strict Monitoring of Azure Resources

Following the “Assume Breach” mentality, we cannot just rely on our security measures to protect our infrastructure. We must constantly monitor to detect any anomalies. Other than using the tools provided by Azure such as Sentinel and Azure Defender for Cloud, we wanted to take our security to the next level and monitor more events, that is why we created CloudWatcher, a free open-source monitoring solution that will monitor any slight changes in our Azure environment and alert the on call engineer if any changes are detected. As a security company, we also follow Google’s recommendation of monitoring certificate transparency logs with EZMonitor. This not only protects us against someone creating SSL certificates for man-in-the-middle attacks, but also other attacks such like the Azure domain takeover attack.

Compliance Excellence

These strict controls have enabled us to meet and exceed compliance requirements for standards respected across the globe, such as SOC 2 type 2, and PCI level 4. If you have any questions about how we secure our infrastructure or how we can help you secure yours, schedule a call with our security experts and start your zero-trust journey with Keytos.

You Might Also Want to Read