Azure Least Privileged Access (LPA)

An overview of the Azure LPA feature

The Azure Least Privileged Access (LPA) feature within InsightCloudSec collects and presents the actions executed by a given user or role within a given time period. These logged actions are collected and analyzed to provide insights to the customer. The data collected by InsightCloudSec for Azure LPA is similar to the data collected by InsightCloudSec for the AWS LPA/Access Explorer function. This feature is documented in three sections:

  • Overview (this page), which presents feature designs and general details
  • Setup, which presents deployment and configuration instructions
  • Usage, which presents how to view and utilize the data collected within InsightCloudSec

Note: If you are looking for LPA functionality related to AWS (Cloud IAM Governance - Access Explorer) check out the content around our AWS Least-Privileged Access (LPA) - Setup & Config. As always, if you have questions about this feature or any others, reach out us through any of the options identified under Getting Support.

Azure LPA Design

The Azure LPA feature relies on a specific set of Azure infrastructure to collect and send data to InsightCloudSec. All of the necessary infrastructure can be deployed automatically using a provided Python script, or existing resources can also be used. For more information on automatic deployment, see Azure LPA Setup. Below is an outline of the infrastructure and data flow for Azure LPA:


Azure LPA data flow

Infrastructure Overview

The following resource types are the main objects of consideration:

  • Event Grid System Topic
  • Event Grid Subscription
  • Event Namespace, Event Hub, Consumer Group
  • Azure Data Explorer (ADX) / Kusto, Data Flow Connector
  • Azure Logic Apps/Workflow, Connectors, Integration Service Environment (ISE)
  • Azure Storage
  • Virtual Network, Subnets, Network Security Groups

For more detailed information about any of these resource types refer to the Azure documentation.

Event Grid System Topic

Data for the Azure LPA feature is collected at the Azure subscription level. Azure allows only one Event Grid System Topic for a given subscription with the topic Microsoft.Resources.Subscriptions. This may already exist for a given subscription. Existence of this system topic can be determined via the Azure CLI:

(ics-azure-lpa) ics-azure-lpa % az eventgrid system-topic list -o jsonc
    "id": "/subscriptions/12345a6b-123b-1234-a12b-a12345b6c78d/resourceGroups/my-resource-group/providers/Microsoft.EventGrid/systemTopics/azure-lpa-topic",
    "identity": null,
    "location": "global",
    "metricResourceId": "23456a7b-234b-2345-a23b-a23456b7c89d",
    "name": "azure-edh-test",
    "provisioningState": "Succeeded",
    "resourceGroup": "dm-test-rg-qa",
    "source": "/subscriptions/12345a6b-123b-1234-a12b-a12345b6c78d",
    "systemData": null,
    "tags": null,
    "topicType": "Microsoft.Resources.Subscriptions",
    "type": "Microsoft.EventGrid/systemTopics"

Event Grid Subscription

The Event Grid Subscription connects the Event Grid System Topic to the resource that will be receiving the events. In addition, the Event Grid Subscription chooses the Event Delivery Schemas as well as the included events types. Azure LPA is currently using the CloudEventSchemaV1_0 event schema. Azure LPA is currently looking at the following event types:

  • Microsoft.Resources.ResourceWriteSuccess
  • Microsoft.Resources.ResourceDeleteSuccess
  • Microsoft.Resources.ResourceActionSuccess

The Event Grid Subscription is part of the same resource group as the (potentially pre-existing) Event Grid System Topic. In addition the Event Grid Subscription requires a target for the data. In Azure LPA, the target is an Event Hub. Because the Event Grid Subscription can reference a different subscription than the Event Hub's subscription, "add subscription" must be done at the Azure subscription level.

Virtual Network

A Virtual Network provides a secure, non-shared environment for the cross-communication of the LPA component resources. This must be deployed prior to the other components, as it is the networking landscape they will inhabit. Addition features of the Virtual Network deployment include a Subnet, a Routing Table, and a Network Security Group.

Event Hub

The Event Hub is Azure LPA's central clearinghouse for all incoming Event Grid Subscription events and is one of the more common targets of Azure events in general. Azure LPA's Event Hub can receive multiple sets of events from distinct Event Grid Subscriptions, each associated with a separate tenant and/or subscription. Event Hubs exist within a unique Event Hub Namespace and filter messages outward to the Consumer Group(s) they target.

The Event Hub Namespace, Event Hub, and Consumer Groups(s) are deployed internal to the LPA resource group. The Event Hub must be created before the Event Grid Subscription is added because the Event Grid Subscription requires an existing Event Hub as a target for its messages.

Azure Data Explorer (ADX) / Kusto Cluster

The Azure Data Explorer (ADX) Cluster (more briefly known as the Kusto Cluster) is Azure LPA's main data processing resource. All Azure LPA computations are performed in the cluster and messages arrive there from one or more Event Hubs. The cluster is essentially a SQL database that is created, updated, and queried in the Kusto query language. The cluster expects typical cluster configuration parameters (instance size, zones, for example), but also allows for the underlying configuration of the tables, ingest, and data connections via Bicep (Azure templating language for automation). The Kusto Cluster is deployed internal to the LPA resource group. The cluster's database, table, and connection configurations are identical in the shared environment and Virtual Network versions.

Azure Logic App

Logic App allows the construction of automated workflows that can operate via cues or off a schedule. Within the context of LPA, the workflow is a scheduled action that queries the Kusto Cluster, manipulates the computed summary data into the appropriate summary format, and pushes the data to Azure Storage. Here is the structure of the logic flow:


Logic App Flow

Azure Storage

Azure Storage is the Azure equivalent of Amazon's S3 bucket, so it is the preferred location for interactive storage. Within the context of Azure LPA, Azure Storage is the destination of the summary data.

Did this page help you?