Skip to content

Commit

Permalink
Merge pull request #477 from MicrosoftDocs/main
Browse files Browse the repository at this point in the history
1/17/2025 PM Publish
  • Loading branch information
Taojunshen authored Jan 17, 2025
2 parents d7f1f7c + ecb3ea2 commit 3400292
Show file tree
Hide file tree
Showing 5 changed files with 84 additions and 84 deletions.
18 changes: 10 additions & 8 deletions articles/lighthouse/concepts/recommended-security-practices.md
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
---
title: Recommended security practices
description: When using Azure Lighthouse, it's important to consider security and access control.
ms.date: 11/28/2023
ms.date: 01/17/2025
ms.topic: conceptual
---

# Recommended security practices

When using [Azure Lighthouse](../overview.md), it's important to consider security and access control. Users in your tenant will have direct access to customer subscriptions and resource groups, so you'll want to take steps to maintain your tenant's security. You'll also want to make sure you only allow the access that's needed to effectively manage your customers' resources. This topic provides recommendations to help you do so.
When using [Azure Lighthouse](../overview.md), it's important to consider security and access control. Users in your tenant will have direct access to customer subscriptions and resource groups, so it's important to take steps that help maintain your tenant's security. We also recommend that you only enable the minimum access necessary to effectively manage your customers' resources. This topic provides recommendations to help you implement these security practices.

> [!TIP]
> These recommendations also apply to [enterprises managing multiple tenants](enterprise.md) with Azure Lighthouse.
Expand All @@ -18,19 +18,19 @@ When using [Azure Lighthouse](../overview.md), it's important to consider securi

[Microsoft Entra multifactor authentication](/entra/identity/authentication/concept-mfa-howitworks) (also known as two-step verification) helps prevent attackers from gaining access to an account by requiring multiple authentication steps. You should require Microsoft Entra multifactor authentication for all users in your managing tenant, including users who will have access to delegated customer resources.

We recommend that you ask your customers to implement Microsoft Entra multifactor authentication in their tenants as well.
We recommend asking your customers to implement Microsoft Entra multifactor authentication in their tenants as well.

> [!IMPORTANT]
> Conditional access policies that are set on a customer's tenant don't apply to users who access that customer's resources through Azure Lighthouse. Only policies set on the managing tenant apply to those users. We strongly recommend requiring Microsoft Entra multifactor authentication for both the managing tenant and the managed (customer) tenant.
## Assign permissions to groups, using the principle of least privilege

To make management easier, use Microsoft Entra groups for each role required to manage your customers' resources. This lets you add or remove individual users to the group as needed, rather than assigning permissions directly to each user.
To make management easier, use [Microsoft Entra groups](/entra/fundamentals/concept-learn-about-groups) for each role required to manage your customers' resources. This lets you add or remove individual users to the group as needed, rather than assigning permissions directly to each user.

> [!IMPORTANT]
> In order to add permissions for a Microsoft Entra group, the **Group type** must be set to **Security**. This option is selected when the group is created. For more information, see [Create a basic group and add members](/entra/fundamentals/how-to-manage-groups#create-a-basic-group-and-add-members).
> In order to add permissions for a Microsoft Entra group, the **Group type** must be set to **Security**. This option is selected when the group is created. For more information, see [Group types](/entra/fundamentals/concept-learn-about-groups#group-types).
When creating your permission structure, be sure to 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.
When creating your permission structure, be sure to follow the [principle of least privilege](/entra/id-governance/scenarios/least-privileged) so that users only have the permissions needed to complete their job. Limiting permissions for users can help to reduce the chance of inadvertent errors.

For example, you may want to use a structure like this:

Expand All @@ -41,9 +41,11 @@ For example, you may want to use a structure like this:
|VM Specialists |User group |\<principalId\> |VM Contributor |9980e02c-c2be-4d73-94e8-173b1dc7cf3c |
|Automation |Service principal name (SPN) |\<principalId\> |Contributor |b24988ac-6180-42a0-ab88-20f7382dd24c |

Once you've created these groups, you can assign users as needed. Only add the users who truly need to have access. Be sure to review group membership regularly and remove any users that are no longer appropriate or necessary to include.
After you create these groups, you can assign users as needed. Only add users who truly need to have the access granted by that group.

Keep in mind that when you [onboard customers through a public managed service offer](../how-to/publish-managed-services-offers.md), any group (or user or service principal) that you include will have the same permissions for every customer who purchases the plan. To assign different groups to work with each customer, you'll need to publish a separate private plan that is exclusive to each customer, or onboard customers individually by using Azure Resource Manager templates. For example, you could publish a public plan that has very limited access, then work with the customer directly to onboard their resources for additional access using a customized Azure Resource Template granting additional access as needed.
Be sure to review group membership regularly and remove any users that are no longer necessary to include.

Keep in mind that when you [onboard customers through a public managed service offer](../how-to/publish-managed-services-offers.md), any group (or user or service principal) that you include will have the same permissions for every customer who purchases the plan. In order to assign different groups to work with different customers, you must publish a separate private plan that is exclusive to each customer, or onboard customers individually by using Azure Resource Manager templates. For example, you could publish a public plan that has very limited access, then work with each customer directly to onboard their resources using a customized Azure Resource Template granting additional access as needed.

> [!TIP]
> You can also create *eligible authorizations* that let users in your managing tenant temporarily elevate their role. By using eligible authorizations, you can minimize the number of permanent assignments of users to privileged roles, helping to reduce security risks related to privileged access by users in your tenant. This feature has specific licensing requirements. For more information, see [Create eligible authorizations](../how-to/create-eligible-authorizations.md).
Expand Down
42 changes: 20 additions & 22 deletions articles/lighthouse/how-to/update-delegation.md
Original file line number Diff line number Diff line change
@@ -1,65 +1,63 @@
---
title: Update a delegation
description: Learn how to update a delegation for a customer previously onboarded to Azure Lighthouse.
ms.date: 05/23/2023
ms.date: 01/17/2025
ms.topic: how-to
ms.custom: devx-track-arm-template
---

# Update a delegation

After you have onboarded a subscription (or resource group) to Azure Lighthouse, you may need to make changes. For example, your customer may want you to take on additional management tasks that require a different Azure built-in role, or you might need to change the tenant to which a customer subscription is delegated.
After you onboard a subscription (or resource group) to Azure Lighthouse, you might need to make changes. For example, your customer might want you to take on additional management tasks that require a different Azure built-in role, or you might need to change the tenant to which a customer subscription is delegated.

> [!TIP]
> Though we refer to service providers and customers in this topic, [enterprises managing multiple tenants](../concepts/enterprise.md) can use the same process to set up Azure Lighthouse and consolidate their management experience.
If you [onboarded your customer through Azure Resource Manager templates (ARM templates)](onboard-customer.md), a new deployment must be performed for that customer. Depending on what you are changing, you may want to update the original offer, or remove the original offer and create a new one.
If you [onboarded your customer through Azure Resource Manager templates (ARM templates)](onboard-customer.md), a new deployment must be performed for that customer. Depending on what you're changing, you may want to update the original offer, or remove the original offer and create a new one.

- **If you are changing authorizations only**: You can update your delegation by changing the **authorizations** section of the ARM template.
- **If you are changing the managing tenant**: You must create a new ARM template using with a different **mspOfferName** than your previous offer.
- **To change authorizations only**: You can update your delegation by changing the **authorizations** section of the ARM template.
- **To change the managing tenant**: You must create a new ARM template with a different **mspOfferName** from your previous offer.

## Update your ARM template
:::image type="content" source="../media/update-delegation.jpg" alt-text="Diagram showing when to change mspOfferName and remove a previous delegation.":::

To update your delegation, you will need to deploy an ARM template that includes the changes you'd like to make.
## Update your ARM template

If you are only updating authorizations (such as adding a new user group with a role you hadn't previously included, or changing the role for an existing user), you can use the same **mspOfferName** as in the [ARM template](onboard-customer.md#create-an-azure-resource-manager-template) that you used for the previous delegation. Use your previous template as a starting point. Then, make the changes you need, such as replacing one Azure built-in role with another, or adding a completely new authorization to the template.
To update your delegation, you need to deploy an ARM template that includes the changes you'd like to make.

If you change the **mspOfferName**, this will be considered a new, separate offer. This is required if you are changing the managing tenant.
If you're only updating authorizations (such as adding a new user group with a role you hadn't previously included, or changing the role for an existing user), you can use the same **mspOfferName** as in the [ARM template](onboard-customer.md#create-an-azure-resource-manager-template) that you used for the previous delegation. Use your previous template as a starting point. Then, make the changes you need, such as replacing one Azure built-in role with another, or adding a new authorization to the template.

You don't need to change the **mspOfferName** if the managing tenant remains the same. In most cases, we recommend having only one **mspOfferName** in use by the same customer and managing tenant. If you do choose to create a new **mspOfferName** for your template, be sure that the customer's previous delegation is removed before deploying the new one.
In most cases, we recommend having only one **mspOfferName** in use by the same customer and managing tenant. You don't need to change the **mspOfferName** if the managing tenant remains the same. If you do change the **mspOfferName**, this will be considered a new, separate offer. Changing the **mspOfferName** is required if you're switching to a different the managing tenant.

## Remove the previous delegation

Before performing a new deployment, you may want to [remove access to the previous delegation](remove-delegation.md). This ensures that all previous permissions are removed, allowing you to start clean with the exact users/groups and roles that should apply going forward.

> [!IMPORTANT]
> If you use a new **mspOfferName** and keep any of the same **principalId** values, you must remove access to the previous delegation before deploying the new offer. If you don't remove the offer first, users who had previously granted permission may lose access completely due to conflicting assignments.
If you're changing the managing tenant, you should only leave the previous offer in place if you want both tenants to continue to have access. If you want the new managing tenant to be the only tenant that has access, the earlier offer must be removed. We generally recommend removing the previous offer before you deploy the new one.

If you are changing the managing tenant, you can leave the previous offer in place if you want both tenants to continue to have access. If you only want the new managing tenant to have access, the earlier offer must be removed. This can be done either before or after you onboard the new offer.

If you are updating the offer to adjust authorizations only, and keeping the same **mspOfferName**, you don't have to remove the previous delegation. The new deployment will replace the previous delegation, and only the authorizations in the newest template will apply.
> [!IMPORTANT]
> If you use a new **mspOfferName** and keep any of the same **principalId** values, you must remove access to the previous delegation before deploying the new offer. If you don't remove the previous offer first, users who had previously been granted permissions may lose access completely due to conflicting assignments.
:::image type="content" source="../media/update-delegation.jpg" alt-text="Diagram showing when to change mspOfferName and remove a previous delegation.":::
If you're updating the offer only to adjust authorizations, and keeping the same **mspOfferName**, you don't have to remove the previous delegation. The new deployment will replace the previous delegation, and only the authorizations in the newest template will apply.

Removing access to the delegation can be done by any user in the managing tenant who was granted the [Managed Services Registration Assignment Delete Role](/azure/role-based-access-control/built-in-roles#managed-services-registration-assignment-delete-role) in the original delegation. If no user in your managing tenant has this role, you can ask the customer to [remove access to the offer in the Azure portal](view-manage-service-providers.md#remove-service-provider-offers).

> [!TIP]
> If you have removed the previous delegation but are unable to deploy the new ARM template, you may need to [remove the registration definition completely](/powershell/module/az.managedservices/remove-azmanagedservicesdefinition). This can be done by any user with a role that has the `Microsoft.Authorization/roleAssignments/write` permission, such as [Owner](/azure/role-based-access-control/built-in-roles#owner), in the customer tenant.
> If you removed the previous delegation but are unable to deploy the new ARM template, you might need to [remove the previous registration definition completely](/powershell/module/az.managedservices/remove-azmanagedservicesdefinition). This can be done by any user with a role that has the `Microsoft.Authorization/roleAssignments/write` permission, such as [Owner](/azure/role-based-access-control/built-in-roles#owner), in the customer tenant.
## Deploy the ARM template

Your customer can [deploy the updated template](onboard-customer.md#deploy-the-azure-resource-manager-template) in the same way that they did previously: in the Azure portal, by using PowerShell, or by using Azure CLI.

After the deployment has been completed, [confirm that it was successful](onboard-customer.md#confirm-successful-onboarding). The updated authorizations will then be in effect for the subscription or resource group(s) that the customer has delegated.
After the deployment is complete, [confirm that it was successful](onboard-customer.md#confirm-successful-onboarding). If so, the updated authorizations are in effect for the subscription or resource group(s) that the customer has delegated.

## Updating Managed Service offers
## Update Managed Service offers

If you onboarded your customer through a Managed Service offer published to Azure Marketplace, and you want to update authorizations, you can do so by [publishing a new version of your offer](/azure/marketplace/update-existing-offer) with updates to the [authorizations](/azure/marketplace/create-managed-service-offer-plans#authorizations) in the plan for that customer. The customer will then be able to [review the changes in the Azure portal and accept the updated version](view-manage-service-providers.md#update-service-provider-offers).
If you onboarded your customer through a Managed Service offer published to Azure Marketplace, and you want to update authorizations, you can do so by [publishing a new version of your offer](/azure/marketplace/update-existing-offer) with updates to the [authorizations](/azure/marketplace/create-managed-service-offer-plans#authorizations) in the plan for that customer. The customer can then [review the changes in the Azure portal and accept the updated version](view-manage-service-providers.md#update-service-provider-offers).

If you want to change the managing tenant, you'll need to [create and publish a new Managed Service offer](publish-managed-services-offers.md) for the customer to accept.
To change the managing tenant for a delegation, you must [create and publish a new Managed Service offer](publish-managed-services-offers.md) for the customer to accept.

> [!IMPORTANT]
> We recommend not having multiple offers between the same customer and managing tenant. If you publish a new offer for a current customer that uses the same managing tenant, be sure that the earlier offer is removed before the customer accepts the newer offer.
> We recommend that you avoid having multiple Managed Service offers between the same customer and managing tenant. If you publish a new offer for a current customer that uses the same managing tenant, be sure that the earlier offer is removed before the customer accepts the newer offer.
## Next steps

Expand Down
Loading

0 comments on commit 3400292

Please sign in to comment.