Azure Lighthouse & Sentinel at Scale – Part 3

In this post we continue our exploration of enabling multitenant management with scalability, higher automation, and enhanced governance across resources. Let’s jump right in this week and learn about the best practices and security baseline of using Azure Lighthouse. This is the last in a mini-series of three posts about Azure Lighthouse and Sentinel at scale; we have looked in detail at delegated permissions, what Azure Lighthouse is all about, and now we look at the best practices and how to deploy!

First up, check out where we started here to get a foundational view of what Azure Lighthouse is all about.

Overview & Quick Re-Cap

What does Lighthouse bring to both sides?

1. Designed to enable enterprise
2. Cross-tenant management
3. Deployment automation
4. Single portal for SOC Teams to access Microsoft Sentinel and Log Analytics Workspaces
5. Ability to deliver well-architected services across all managed environments
6. There is no additional cost to use Azure Lighthouse (Q1 2024)

Azure Lighthouse Best Practices

Let’s first think about some of the best practices that we should follow when getting setup to manage multiple tenants using Azure Lighthouse and Microsoft Sentinel:

1. Assign permissions to groups.

In most cases, you’ll want to assign permissions to a Microsoft Entra security group or service principal, rather than to a series of individual user accounts. This lets you add or remove access for individual users through your tenant’s Microsoft Entra ID, rather than having to update the delegation every time your individual access requirements change.

An example from real world usage might look like: “SG-SOC-Staff-Intermediate-MSP-ClientName”

Without diving into Azure naming conventions too much, I think this group name is pretty straight-forward:
SG = Security Group
SOC = Security Operations Centre
Staff = Staff (vs External / Contractor / or other designation)
Intermediate = Level of SOC team in this group, some organizations specify this and some don’t.
MSP = Managed Service Provider (This identifier helps when the delegation is assigned for the customers)
ClientName = Well….your client’s name. This is so the group is easier to manage.

2. Follow the principle of least privilege.

Follow the principle of least privilege so that users only have the permissions needed to complete their job, helping to reduce the chance of inadvertent errors. For more information, see Recommended security practices coming up in the next couple of moments here…

3. Include a Registration Assignment for Delete Role

Include an authorization with the Managed Services Registration Assignment Delete Role so that you can remove access to the delegation later if needed. If this role isn’t assigned, access to delegated resources can only be removed by a user in the target customer’s tenant. Remember that sometimes MSPs will roll down operations or terminate services; this is part of a well-architected Lighthouse solution.

4. In the provider tenant ensure that users have Read permissions to view the My Customers page in Azure portal

Be sure that any user who needs to view the My customers page in the Azure portal has the Reader role (or another built-in role that includes Reader access).

Enterprise Scenarios Security & Access Considerations

In most enterprise scenarios, you’ll want to delegate a full subscription to Azure Lighthouse. You can also choose to delegate only specific resource groups within a subscription. Follow the principle of least privilege when defining which users will have access to delegated resources. Doing so helps to ensure that users only have the permissions needed to perform the required tasks and reduces the chance of inadvertent errors.

Azure Lighthouse only provides logical links between a managing tenant and managed tenants, rather than physically moving data or resources. Furthermore, the access always goes in only one direction, from the managing tenant to the managed tenants. (Provider > Customer tenant)

Users and groups in the managing tenant should continue to use multifactor authentication when performing management operations on managed tenant resources.

Monitoring Activity

Enterprises with internal or external governance and compliance guardrails can use Azure Activity logs to meet their transparency requirements. When enterprise tenants have established managing and managed tenant relationships, users in each tenant can view logged activity to see actions taken by users in the managing tenant.

Diagnostic logging and Azure Activity is used to push logs into a Logs Analytics Workspace when monitoring is configured. Remember that Sentinel is looking for events of interest when well-configured.

In this case we can also use Azure Monitor in the customer tenant to examine events if that logging is enabled as part of a deployment. This makes events fully able to be audited and examined such as VM size changes before and after that change.

There are many different flavours and methods that can be used for log event storage in short, medium, and long term storage; and many tools that can be used to audit events in a tenant. In this example I used Azure Monitor to provide additional oversight to an MSP that is using the same logs in a Log Analytics Workspace with Sentinel enabled on it to provide security services into a tenant.

Deployment Prerequisites

Yes, we will always have some things that need to be enabled. For the most part, it is unlikely you would need to add these unless there is a fully greenfield situation.

1. Provider tenant must have Sentinel enabled on at least one subscription.
2. Provider tenant must have the following service providers enabled under the target subscription:
   • OperationalInsights, and
   • SecurityInsights

How is Azure Lighthouse Deployed?

There are different methods of deploying Azure Lighthouse delegation packages, my favourite is JSON or ARM template. Microsoft even provides a number of examples for us:

• Sentinel & Log Analytics Workspace
• Security Center
• Azure Monitor & Policy
• Single & Multiple Resource Group

We can take a single template or a selected few and build an onboarding package that meets the balance of everything that is needed for our SOC Team and organization. Keeping the delegated privileges true to the spirit of least privilege.

This part also becomes a repeatable action for future tenants should others need to be onboarded.  This is part of the optimized management at scale with Lighthouse. In this case the SOC Team would not need further training as other environments are merged into the Incident Management dashboard and team members would be able to select one or many different workspaces!

What Does the Lighthouse Enabled Multi-Workspace View Look Like?

Here we can see that when you open Microsoft Sentinel in the portal, you can select multiple workspaces at one time and VIEW INCIDENTS from all of them at the same time. This allows a HUGE optimization for your SOC Team as they can now prioritize incidents across the whole enterprise or multiple customers and address all the critical and high importance incidents FIRST!

Security Baseline

This security baseline applies guidance from the Microsoft cloud security benchmark version 1.0 to Azure Lighthouse. The Microsoft cloud security benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is grouped by the security controls defined by the Microsoft cloud security benchmark and the related guidance applicable to Azure Lighthouse.

You can monitor this security baseline and its recommendations using Microsoft Defender for Cloud.

Azure Policy definitions will be listed in the Regulatory Compliance section of the Microsoft Defender for Cloud portal page.

When a feature has relevant Azure Policy Definitions, they are listed in this baseline to help you measure compliance with the Microsoft cloud security benchmark controls and recommendations. Some recommendations may require a paid Microsoft Defender plan to enable certain security scenarios.

The v1 baselines will follow the Microsoft cloud security benchmark v1 control requirements, which also map to newer industry frameworks such as NIST and PCI. These security baseline items are more security feature driven and more intuitive than what we saw a few years ago even; excellent improvements by Microsoft here to help us secure these Lighthouse deployments!

One thing I would like to make sure I hammer home here for providers:

1. Use strong passwords and Microsoft MFA with modern authentication!!

There are so many other standards that we could dive into here such as account separation and regular RBAC reviews, but I digress!

Summary

Why Use Azure Lighthouse?

• Work with incidents across multiple estates
• Prioritize incidents at the SOC level, not each individual organization/customer
• Summarized counters for the Analysts (# of incidents, etc)
• Familiar investigation tools and queries
• Same methods of investigation

Thank you for joining me for our journey through Azure Lighthouse!

Join me back here on AzureTracks.com for our next post!