Azure security baseline for Azure Data Explorer

  • Článek
  • 22 min ke čtení

This security baseline applies guidance from the Azure Security Benchmark version 2.0 to Azure Data Explorer. The Azure 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 Azure Security Benchmark and the related guidance applicable to Azure Data Explorer.

Note

Controls not applicable to Azure Data Explorer, and those for which the global guidance is recommended verbatim, have been excluded. To see how Azure Data Explorer completely maps to the Azure Security Benchmark, see the full Azure Data Explorer security baseline mapping file.

Network Security

For more information, see the Azure Security Benchmark: Network Security.

NS-1: Implement security for internal traffic

Guidance: When you deploy Azure Data Explorer resources, create or use an existing virtual network. Make sure all Azure virtual networks follow an enterprise segmentation principle that aligns with the business risks. If a system incurs higher risk for the organization, isolate it within its own virtual network. Secure the virtual network sufficiently with a network security group (NSG) and/or Azure Firewall.

With Microsoft Defender for Cloud adaptive network hardening, recommend NSG configurations that limit ports and source IPs based on external network traffic rules.

Based on your applications and enterprise segmentation strategy, restrict or allow traffic between internal resources according to your NSG rules. For specific, well-defined applications (such as a three-tier app), this tactic can be a highly secure deny by default.

With NSGs, you can control network access within a virtual network. Azure Data Explorer requires a certain set of inbound and outbound network security rules to operate. To successfully deploy and use Azure Data Explorer, delegate the subnet that's used for injection to 'Microsoft.Kusto/clusters' before creating the cluster.

To disable access completely to Azure Data Explorer via the public IP address, create another inbound rule in the NSG. The rule should deny all port ranges from the source tag of 'Internet' and destination 'VirtualNetwork'. This rule has to have a lower priority (a higher number).

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

NS-2: Connect private networks together

Guidance: Use Azure ExpressRoute or Azure virtual private network (VPN) to create private connections between Azure datacenters and on-premises infrastructure in a colocation environment. ExpressRoute connections don't go over the public internet. The ExpressRoute connections offer more reliability, faster speeds, and lower latencies than typical internet connections. For point-to-site VPN and site-to-site VPN, you can connect on-premises devices or networks to a virtual network, using any combination of these VPN options and Azure ExpressRoute.

To connect two or more virtual networks in Azure together, use virtual network peering. Network traffic between peered virtual networks is private and is kept on the Azure backbone network.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

NS-3: Establish private network access to Azure services

Guidance: Azure Data Explorer supports deploying a cluster into a subnet in your virtual network. With this capability, you can:

  • Enforce network security group (NSG) rules on your Azure Data Explorer cluster traffic.
  • Connect your on-premises network to Azure Data Explorer cluster's subnet.
  • Secure your data connection sources.

Currently Azure Data Explorer is in preview for Private Endpoint support. Private Endpoint will be the preferred method of establishing private network access when generally available.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

NS-4: Protect applications and services from external network attacks

Guidance: Protect your Azure Data Explorer resources against attacks from external networks, such as:

  • Distributed denial of service (DDoS) attacks.
  • Application-specific attacks.
  • Unsolicited and potentially malicious internet traffic.

Use Azure Firewall to protect applications and services against potentially malicious traffic from the internet and other external locations. To protect your assets against DDoS attacks, enable DDoS standard protection on your Azure virtual networks. Use Microsoft Defender for Cloud to detect misconfiguration risks on your network-related resources.

Azure Data Explorer isn't intended to run web applications. It doesn't require you to configure any other settings or deploy any extra network services. Azure Data Explorer will still protect from external network attacks targeting web applications.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

NS-6: Simplify network security rules

Guidance: With Azure Virtual Network service tags, you can define network access controls on NSGs or Azure Firewall that are configured for your Azure Data Explorer resources. You may use service tags in place of specific IP addresses when you create security rules. If you specify the service tag name in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service. Microsoft manages the address prefixes that are encompassed by the service tag. As addresses change, the service tag is automatically updated.

Azure Data Explorer provides a services tag for inbound Management traffic (AzureDataExplorerManagement). The IP address that's responsible for health monitoring isn't available via a service tag. We highly recommend you operate ADX using the subnet delegation mechanism. To achieve this setup, delegate the subnet to Microsoft.Kusto/clusters.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Identity Management

For more information, see the Azure Security Benchmark: Identity Management.

IM-1: Standardize Azure Active Directory as the central identity and authentication system

Guidance: Azure Active Directory (Azure AD) is the only method for authenticating on Azure Data Explorer. Azure AD supports many authentication scenarios:

  • User authentication (interactive logon): Used to authenticate human principals.

  • Application authentication (non-interactive logon): Used to authenticate services and applications that have to run or authenticate without a human user being present.

For more information, see the following references:

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

IM-2: Manage application identities securely and automatically

Guidance: Azure Data Explorer supports managed identities for its Azure resources. Use managed identities with Azure Data Explorer instead of creating service principals to access other resources. Azure Data Explorer can natively authenticate to the Azure services or resources that support Azure AD authentication. The native authentication proceeds through a predefined access grant rule without using credentials that are hard-coded in source code or configuration files.

To configure service principals with certificate credentials and fallback to client secrets, Azure Data Explorer recommends that you use Azure AD to create a service principal with restricted permissions at the resource level. In both cases, you can use Azure Key Vault with Azure-managed identities, so that the runtime environment (such as an Azure function) can retrieve the credential from the key vault.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

IM-3: Use Azure AD single sign-on (SSO) for application access

Guidance: Azure Data Explorer uses Azure AD to provide identity and access management to:

  • Azure resources.
  • Cloud applications.
  • On-premises applications.

This management applies to:

  • Enterprise identities, such as employees.
  • External identities, like partners, vendors, and suppliers.

With this mechanism, single sign-on (SSO) can manage and secure access to your organization's data and resources on-premises and in the cloud. Connect all your users, applications, and devices to the Azure AD. This action provides seamless secure access, greater visibility, and more control.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

IM-7: Eliminate unintended credential exposure

Guidance: Azure Data Explorer allows customers to deploy its resources via Azure Resource Manager templates, which may contain embedded secrets. To protect against this potential risk, we recommend you implement Credential Scanner to identify credentials within your code. Credential Scanner will also encourage moving discovered credentials to more secure locations, such as Azure Key Vault.

For GitHub, you can use the native secret scanning feature, which identifies credentials or other forms of secrets within the code.

For more information, see the following references:

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Privileged Access

For more information, see the Azure Security Benchmark: Privileged Access.

PA-1: Protect and limit highly privileged users

Guidance: The most critical built-in roles for Azure AD are Global Administrator and Privileged Role Administrator. Users who are assigned to these two roles can delegate administrator roles:

  • Global Administrator or Company Administrator: Users with this role have access to all administrative features in Azure AD, and services that use Azure AD identities.

  • Privileged Role Administrator: Users with this role can manage role assignments in Azure AD, and within Azure AD Privileged Identity Management (PIM). This role also allows management of all aspects of PIM and administrative units.

Note: If you use custom roles with certain privileged permissions assigned, you might have other critical roles that need to be governed. You might also want to apply similar controls to the administrator account of critical business assets.

Limit the number of highly privileged accounts or roles. Protect these accounts at an elevated level. Users with this privilege can directly or indirectly read and modify every resource in your Azure environment.

You can enable just-in-time (JIT) privileged access to Azure resources and Azure AD using Azure AD PIM. JIT grants temporary permissions to do privileged tasks only when users need it. PIM can also generate security alerts when there's suspicious or unsafe activity in your Azure AD organization.

The highest privileged role for Azure Data Explorer in the Azure role-based access control (Azure RBAC) model is All Databases Admin. You can configure that role on the control plane of the service in the portal (Permissions tab). Create standard operating procedures around the use of dedicated administrative accounts such as All Databases Admin.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PA-2: Restrict administrative access to business-critical systems

Guidance: Azure Data Explorer uses a role-based access control model, under which authenticated principals are mapped to roles. The principals get access according to the roles they're assigned.

Customers can use group membership or execution context to control access to rows in a database table.

Row Level Security (RLS) simplifies the design and coding of security. It lets you apply restrictions on data row access in your application. For example, you may limit user access to rows relevant to their department, or restrict customer access to only the data relevant to their company.

The access restriction logic is located in the database tier, rather than away from the data in another application tier. The database system applies the access restrictions whenever data access is attempted from any tier. This logic makes your security system more reliable and robust, because it reduces the surface area of your security system.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PA-3: Review and reconcile user access regularly

Guidance: To make sure that the accounts and access of users is valid, Azure Data Explorer uses Azure Active Directory (Azure AD) accounts to:

  • Manage its resources.
  • Review user accounts.
  • Access assignments regularly.

You can use Azure AD and access reviews to review:

  • Group memberships.
  • Access to enterprise applications.
  • Role assignments.

Azure AD reporting can provide logs to help discover stale accounts. You can also use Azure AD Privileged Identity Management (PIM) to create access review report workflows. The report workflows make the review process easier.

You can configure Azure AD PIM to alert you when an excessive number of administrator accounts are created. It can identify administrator accounts that are stale or improperly configured.

Note: Some Azure services support local users and roles that aren't managed through Azure AD. You'll need to manage these users separately.

Azure Data Explorer uses a role-based access control model. Authenticated principals are mapped to roles. The principals get access according to the roles they're assigned.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PA-7: Follow only enough administration (least privilege principle)

Guidance: Azure Data Explorer is integrated with Azure role-based access control (Azure RBAC) to manage its resources. Azure RBAC allows you to manage Azure resource access through role assignments. You can assign these roles to:

  • Users.
  • Groups.
  • Service principals.
  • Managed identities.

There are predefined built-in roles for certain resources. These roles can be inventoried or queried through tools, such as:

  • Azure CLI.
  • Azure PowerShell.
  • Azure portal.

If you assign privileges to resources through the Azure RBAC, they should be always limited by what's required by the roles. This practice complements the just-in-time (JIT) approach of Azure AD Privileged Identity Management (PIM), and it should be reviewed periodically.

Use built-in roles to give permissions. Only create custom roles when required.

Azure Data Explorer also enables you to control access to databases and tables, using an Azure RBAC model. The model maps authenticated principals to roles. The principals get access according to the roles they're assigned.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PA-8: Choose approval process for Microsoft support

Guidance: In support scenarios where Microsoft needs to access customer data, Azure Data Explorer supports Customer Lockbox. Customer Lockbox provides an interface for you to review, and then approve or reject customer data access requests.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Data Protection

For more information, see the Azure Security Benchmark: Data Protection.

DP-1: Discover, classify, and label sensitive data

Guidance: Azure Data Explorer integrates with Azure Purview. Azure Purview supports 100+ built-in classifications, including:

  • Credit cards.
  • Account numbers.
  • Government IDs.
  • Location data.

Customers can create custom classifications. Using built-in and custom classification rules, customers can apply these classifications at scale.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

DP-2: Protect sensitive data

Guidance: Protect sensitive data by restricting access using:

  • Azure role-based access control (Azure RBAC).
  • Network-based access controls.
  • Specific controls in Azure services (such as encryption).

To ensure consistent access control, align all types of access control with your enterprise segmentation strategy. Use the location of sensitive or business critical data and systems when you devise an enterprise segmentation strategy.

Azure Data Explorer offers various features to protect customer content. For sensitive information, you should turn on encryption on all levels (data in cache, at rest, and double encryption of storage accounts). Separate those clusters from other resources by virtual network or subnet. Tag the clusters appropriately, and secure them within an NSG or Azure Firewall. Sufficiently isolate Azure Data Explorer clusters that store or process sensitive data. To provide access on the data plane via Azure Data Explorer RBAC, consider the principle of least privilege.

For the underlying platform (managed by Microsoft), we treat all customer content as sensitive, and we guard against customer data loss and exposure. To ensure customer data within Azure remains secure, we've implemented some default data protection controls and capabilities.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

DP-4: Encrypt sensitive information in transit

Guidance: To complement access controls, protect data in transit against 'out of band' attacks (such as traffic capture) using encryption. This practice ensures attackers can't easily read or modify the data.

Azure Data Explorer supports data encryption in transit with Transport Layer Security (TLS) protocol version 1.2 or greater.

Although data encryption is optional for traffic on private networks, it's critical for traffic on external and public networks. For HTTP traffic, make sure any clients that connect to your Azure resources can negotiate TLS v1.2 or greater. For remote management, use SSH (for Linux) or RDP/TLS (for Windows) instead of an unencrypted protocol. Disable the following items:

  • Obsolete SSL
  • TLS
  • SSH versions and protocols
  • Weak ciphers

By default, Azure provides encryption for data in transit between Azure data centers.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: None

DP-5: Encrypt sensitive data at rest

Guidance: To complement access controls, Azure Data Explorer encrypts data at rest to protect against 'out of band' attacks (such as accessing underlying storage) using encryption. This practice helps ensure attackers can't easily read or modify the data.

Azure provides encryption for data at rest by default. For highly sensitive data, you have options to implement more encryption at rest on all Azure resources where available. Azure manages your encryption keys by default. But Azure also provides options to manage your own keys (customer-managed keys) for certain Azure services, to meet regulatory requirements.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Asset Management

For more information, see the Azure Security Benchmark: Asset Management.

AM-1: Make sure security team can monitor risks in your assets

Guidance: Grant security teams Security Reader permissions in your Azure tenant and in subscriptions that house your Azure Data Explorer resources. With these permissions, the tenant and subscriptions can monitor for security risks using Microsoft Defender for Cloud.

Depending on how you structure security team responsibilities, a central security team or a local team could be responsible for monitoring security risks. But you must always aggregate security insights and risks centrally within an organization.

Security Reader permissions can be applied broadly to an entire tenant (Root Management Group) or scoped to management groups or specific subscriptions.

Note: Other permissions might be required to get visibility into workloads and services.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

AM-2: Make sure security team has access to asset inventory and metadata

Guidance: Make sure your security teams have access to a continuously updated inventory of assets on Azure, like Azure Data Explorer. Security teams often need this inventory to evaluate their organization's potential exposure to emerging risks. It's also needed as an input to continuous security improvements. Create an Azure Active Directory (Azure AD) group to contain your organization's authorized security team. Then assign the team read access to all Azure Data Explorer resources. This access can be simplified by a single high-level role assignment within your subscription.

To organize your inventory into a taxonomy, apply tags to your Azure:

  • Resources.
  • Resource groups.
  • Subscriptions.

Each tag consists of a name and a value pair. For example, you can apply the name "Environment" and the value "Production" to all the resources in production.

Azure Data Explorer doesn't allow running an application or the installation of software on its resources.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: None

Logging and Threat Detection

For more information, see the Azure Security Benchmark: Logging and Threat Detection.

LT-1: Enable threat detection for Azure resources

Guidance: Azure Data Explorer doesn't provide native capabilities to monitor the security threats related to its resources.

Configure resource logs and forward logs from Azure Data Explorer to your SIEM, which you can use to set up custom threat detections. Make sure you're monitoring different types of Azure assets for potential threats and anomalies. Focus on getting high-quality alerts to reduce false positives for analysts to sort through. Alerts can be sourced from log data, agents, or other data.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

LT-3: Enable logging for Azure network activities

Guidance: Enable and collect the following logs for network security analysis that's related to your Azure Data Explorer resources:

  • NSG resource logs
  • NSG flow logs
  • Azure Firewall logs

You can send the flow logs to an Azure Monitor Log Analytics workspace. Then use Traffic Analytics to provide insights.

Azure Data Explorer doesn't produce or process DNS query logs.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

LT-4: Enable logging for Azure resources

Guidance: Activity logs, which are automatically available, contain all write operations (PUT, POST, and DELETE) for your Azure Data Explorer resources. The logs don't contain read operations (GET), though. You can use activity logs to find an error when troubleshooting, or to monitor how a user in your organization modified a resource.

Enable Azure resource logs for Azure Data Explorer. You can use Microsoft Defender for Cloud and Azure Policy to enable resource logs and log data collecting. These logs can be critical when you investigate security incidents and do forensic exercises.

Azure Data Explorer security principals can run a command that returns a table with admin commands and queries that have reached a final state. These commands and queries are available for 30 days.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

LT-6: Configure log storage retention

Guidance: For any storage accounts or Log Analytics workspaces that are used for storing Azure Data Explorer logs, set the log retention period according to your organization's compliance regulations.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Posture and Vulnerability Management

For more information, see the Azure Security Benchmark: Posture and Vulnerability Management.

PV-1: Establish secure configurations for Azure services

Guidance: With a single blueprint definition, use Azure Blueprints to automate the deployment and configuration of services and application environments, including:

  • Azure Resources Manager templates.
  • Azure RBAC controls.
  • Policies.

Azure Data Explorer supports configuration enforcement via Azure Policy definitions. It provides a set of built-in Azure Policy definitions for out-of-the-box use.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PV-2: Sustain secure configurations for Azure services

Guidance: Use Microsoft Defender for Cloud to monitor your configuration baseline. Also use Azure Policy [deny] and [deploy if not exist] to enforce secure configuration across your Azure Data Explorer resources.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PV-3: Establish secure configurations for compute resources

Guidance: Use Microsoft Defender for Cloud and Azure Policy to establish secure configurations for Azure Data Explorer.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

PV-6: Do software vulnerability assessments

Guidance: Vulnerability management is done on the underlying systems that support Azure Data Explorer.

Responsibility: Microsoft

Microsoft Defender for Cloud monitoring: None

Endpoint Security

For more information, see the Azure Security Benchmark: Endpoint Security.

ES-1: Use endpoint detection and response (EDR)

Guidance: Azure Data Explorer doesn't deploy any customer-facing compute resources that would require customers to configure EDR protection. The underlying infrastructure for Azure Data Explorer is handled by Microsoft, and it includes antimalware and EDR handling.

Responsibility: Microsoft

Microsoft Defender for Cloud monitoring: None

ES-2: Use centrally managed modern antimalware software

Guidance: The compute resources of Azure Data Explorer use antimalware protection, which is regularly updated. Configuration changes, other settings, or deployment of any extra services is unnecessary to protect the compute resources from malware.

Responsibility: Microsoft

Microsoft Defender for Cloud monitoring: None

ES-3: Ensure antimalware software and signatures are updated

Guidance: The compute resources of Azure Data Explorer use antimalware protection, which is regularly updated. Configuration changes, other settings, or deployment of any extra services is unnecessary to protect the compute resources from malware.

Responsibility: Microsoft

Microsoft Defender for Cloud monitoring: None

Backup and Recovery

For more information, see the Azure Security Benchmark: Backup and Recovery.

BR-1: Ensure regular automated backups

Guidance: For customer backup requirements, customers can configure native capabilities (such as continuous export) to enable their own custom backup processes.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

BR-2: Encrypt backup data

Guidance: Azure Data Explorer doesn't support data backups natively and instead is designed to be highly available, Azure Data Explorer applies Azure Storage as its durable persistence layer. Azure Storage automatically provides fault tolerance, with the default setting offering Locally Redundant Storage (LRS) within a data center. Data is encrypted with Microsoft-managed keys.

Responsibility: Microsoft

Microsoft Defender for Cloud monitoring: None

BR-3: Validate all backups, including customer-managed keys

Guidance: Periodically make sure you can restore backed-up, customer-managed keys that are used to encrypt Azure Data Explorer data at rest.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

BR-4: Mitigate risk of lost keys

Guidance: Take measures to prevent and recover from the loss of keys that are used to encrypt your Azure Data Explorer data at rest. Enable soft delete and purge protection in Azure Key Vault, which protects keys against accidental or malicious deletion.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: None

Next steps