Access Management

• Introduction

• Azure Lighthouse

• Azure Privileged Identity Management

• Implementation

  • Architectural Overview

• Azure Delegated Resource Management

  • How does ADRM work

  • RBAC overview

  • Scope and limitations of ADRM

• Azure Privileged Identity Management

• Logging & Tracing

  • Azure Activity Log

  • Example

• Access Management Process

• Microsoft Reference

Introduction

This document provides an overview of the security model used in SoftwareONE’s AzureSimple and Unified Support for Azure Service based on Azure Lighthouse and Azure privileged Identity Management technology.

Azure Lighthouse

Azure Lighthouse provides capabilities for cross-customer management at scale, letting partners differentiate services based on greater efficiency and automation. Extend these capabilities consistently across marketplace offers, Azure services, APIs, and licensing models.

More information on Azure Lighthouse on Microsoft Docs

Azure Privileged Identity Management

Privileged Identity Management provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources that we care about. The key features of Privileged Identity Management:

• Provide just-in-time privileged access to Azure resources

• Assign time-bound access to resources using start and end dates

• Require approval to activate privileged roles

• Enforce multi-factor authentication to activate any role

• Use justification to understand why users activate

• Get notifications when privileged roles are activated

• Conduct access reviews to ensure users still need roles

• Download audit history for internal or external audit

Implementation

Architectural Overview

The below diagram shows the Azure Lighthouse implementation in SoftwareONE based on 3 layered security domains concept.

The 3 layered security domains in SoftwareONE.

Azure Delegated Resource Management

With Azure delegated resource management aka ADRM, authorized SoftwareONE can work directly in the context of a customer subscription without having an account in the customer's tenant or being a co-owner of the customer's tenant.

How does ADRM work

With Azure Lighthouse, we can assign different groups to different customers or roles, as shown in the following diagram. Because users will have the appropriate level of access through Azure delegated resource management, we improve security by limiting unnecessary access to customers’ resources.

RBAC overview

The current security model is based upon two Security Groups with specific RBAC permissions on the subscription level. When a SoftwareONE engineer is part of the Security Group the permissions assigned to that Security Group are granted to the SoftwareONE engineer on subscription level.

Steps:

1. Customer subscriptions are delegated to the SoftwareONE Azure Lighthouse tenant

2. SoftwareONE engineer signs in using the MSP tenant (Azure Lighthouse)

3. Based on the Security Group membership the engineer can access the delegated subscription

This works for Portal access, PowerShell, and the Azure CLI.

Scope and limitations of ADRM

Azure Delegated Resource Management (ADRM) is scoped to Azure management operations and not to data operations. In other words, SoftwareONE can manage the resource under Azure Resource Manager but cannot access the data stored in the resource as this type of access falls under data operations.

Azure Active Directory cannot be managed under ADRM, it means SoftwareONE cannot see customer users or make changes in customer Azure AD aka Azure Tenant.

Azure Privileged Identity Management

The Security Groups defined under the RBAC overview are protected by Azure Privileged Identity Management (PIM). The following table shows the settings per Security Group.

The Security Groups can only contain people that are a member of a delivery team that is part of the Service Offer.

To again Write access to a customer environment, an engineer must go through a privileged access process to temporarily join the Customer specific RW group.

The process includes documenting the Ticket number and giving a summary reason for the access. The access is Self Approved for speed but tracked and logged in SoftwareONE’s event management solution.

The access is temporary and is automatically removed after not more than four hours.

Logging & Tracing

Azure Activity Log

The Azure Activity Log operates at the subscription layer and provides insight into the operations on each Azure resource in the subscription from the outside (the management plane) in addition to updates on Service Health events. Use the Activity Log, to determine the what, who, and when for any write operations (PUT, POST, DELETE) taken on the resources in your subscription.

There is a single Activity log for each Azure subscription. An Activity log is kept for 90 days and entries in the Activity Log are system generated and cannot be changed or deleted.

Example

In this example, both the customer (left side) and the MSP providers (right side) have created a Virtual Machine.

1 - Start with an empty Activity Log

2 - Virtual Machines have been created.

Both events are logged under their own name in the Activity Log of the subscription.

A typical scenario is to collect all Azure Activity Log events into Azure Monitor Log Analytics Workspace. You can have a retention time beyond 90 days or create alerts when an event occurs based on “Event initiated by” or “Operation name”.

Access Management Process

Microsoft Reference

What is Azure delegated resource management?

Role support for Azure Lighthouse

Enhanced services and scenarios

Azure Lighthouse and the Cloud Solution Provider program