OT Cloud Enablement – Azure Active Directory Tenant

In our journey to help cloud enable Operational Technology (OT) environments, we have published the following articles:

• Extending Operational Technology to Azure
• OT Cloud Enablement - Cloud Adoption Models

Today we are going a little deeper into what was discussed in the OT Cloud Enablement - Cloud Adoption Models article by exploring Azure Active Directory (Azure AD) tenant design considerations for an OT environment. Once the Azure AD tenant design has been finalised, decisions on Identity and Access Management (IAM), network topology and connectivity, resource organisation, security, management, governance and, platform automation and DevOps can then be made.

 

The importance of the Azure AD tenant design and why we are looking at this first is explained in the Cloud Adoption Framework for Azure:

 

“Each Azure landing zone and its management group hierarchy is rooted in a single Azure Active Directory (Azure AD) tenant. This means that the first decision you need to make is which Azure AD tenant to use as the source of identities for managing your Azure resources. Identities in the Azure AD include users, groups, and service principals.”

 

The Cloud Adoption Framework for Azure also provides the following guidance:

 

“The guidance for Azure landing zones and Azure AD tenants strongly recommends using a single Azure AD tenant, and this is the correct approach for most situations.”

 

The key point to take away is that a single Azure AD tenant design is the recommend approach for “most situations”. For example, if an organisation had two Information Technology (IT) (aka Corporate) Active Directory forests and wanted to cloud enable them, it may make sense to go with a single tenant design. This has the benefit of simplifying the management of access to cloud-based resources, consolidating licenses and infrastructure resources. However, when it comes to OT it gets complicated because IT and OT have different operational priorities:

 

“The IT department is responsible for the informational infrastructure of an enterprise. IT teams focus on maintaining consistent policies and control across the organization. IT is responsible for the protection of sensitive applications and confidential data from unauthorized access.

 

The OT department is responsible for the equipment on industrial sites. It's focused on production output and worker safety. Because OT performance is key to the company revenues, the team pays particular attention to the uptime and maintenance of machinery”

 

What does this mean for the Azure AD tenant design if the organisation has an IT and OT environment? We can start by looking at some common OT standards to provide some guidance. The “NIST SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security” standard has the following to say regarding major security objectives for an OT implementation:

 

“Restrict logical access to the OT network, network activity, and systems. This may include using unidirectional gateways, utilizing a demilitarized zone (DMZ) network architecture with firewalls to prevent network traffic from passing directly between the corporate and OT networks, and having separate authentication mechanisms and credentials for users of the corporate and OT networks. The OT system should also use a network topology that has multiple layers, with the most critical communications occurring in the most secure and reliable layer”

 

NIST SP 800-82 Rev. 3 also states, as part of a defence-in-depth strategy, the following:

• Restricting OT user privileges to only those that are required to perform each user’s function (e.g., establishing role-based access control, configuring each role based on the principle of least privilege).
• Using separate authentication mechanisms and credentials for users of the OT network and the corporate network (i.e., OT network accounts do not use corporate network user accounts).
• Using modern technology, such as smart cards for user authentication.

This re-enforces that separate authentication mechanisms and credentials for users of the IT and OT network must be utilised. It does not specify the need to have separate identity services (e.g. Azure AD) for IT and OT.

 

This brings us back to the Azure AD tenant design decision for OT:

• Does the organisation adopt a Converged Model by having a single Azure AD tenant for IT and OT user accounts, groups, and service principals?
  or
• Does the organisation adopt a Segregated Model by having separate Azure AD tenants for IT and OT, where the user accounts, groups and service principals for each environment exist within their own tenant?

 

The decision will be based on how the organisation interprets “having separate authentication mechanisms and credentials” and what level of risk that they are willing to accept for operations in IT (e.g. security policies, patch management, control plane operations) to negatively impact OT operations. Below we will explore what the Converged and Segregated models for Azure AD tenants looks like in more detail.

Converged Model

 

Under the Converged Model, a single Azure AD tenant will be utilised to provide RBAC access to IT and OT cloud workloads. Separate user identities for IT and OT are provisioned for each Active Directory Forest and these identities are granted access to the appropriate cloud resources.

 

There are some constraints with this approach which have been documented under the Multiple forests, single Azure AD tenant hybrid identity topology.

 

In the below Azure AD tenant design, we have Active Directory Forests for IT (i.e. contoso.com) and OT (i.e. contoso.org) connected to a single Azure AD tenant (i.e. contoso.onmicrosoft.com). This tenant has been configured with custom domains to allow the identities in the tenant to maintain their relevant domain names (i.e. contoso.com or contoso.org).

 

 

As discussed in the OT Cloud Enablement - Cloud Adoption Models blog, the Converged approach has a number of benefits and drawbacks.

 

Benefits

• Reduced administrative overhead (e.g. single tenant to manage).
• Reduced infrastructure costs through shared services (e.g. shared hybrid connectivity, security appliances).
• Reduced license costs if the organisation chooses to use a single identity for IT and OT users and add additional controls to secure access to OT (e.g. Azure AD Privileged Identity Management).

Drawbacks

• OT is no longer segregated from IT, which increases the risk of IT impacting OT operations.
• Deviates from the traditional Purdue model.
• Makes separation/divestment operations more complex. Several Azure resources have a dependency on the Azure AD tenant and may require downtime to recover the resource in the new tenant as part of a divestment operation. A list of resources that could be impacted by a tenant transfer can be locate here.

Segregated Model

 

Depending on the size and complexity of the organisation, the Segregated Model has several approaches that could be adopted:

• IT tenant and OT tenant
• IT tenant and OT tenant per Operational Site
• IT tenant and OT tenant Operational Site (Hybrid)

 

Option 1: IT tenant and OT tenant

This involves having separate Azure AD tenants for IT (contoso.onmicrosoft.com) and OT (contosoot.onmicrosoft.com). Each Active Directory Forest is connected to the relevant Azure AD tenant and custom domains have been configured.

User accounts, groups and service principals would be independent of each environment. By default, there would be no trust/access to resources between the two tenants. This approach is suitable for organisations that have a single OT environment or are looking to consolidate their OT environments under a single tenant.

 

As discussed in the OT Cloud Enablement - Cloud Adoption Models blog, the segregate model has a number of benefits and drawbacks.

 

Benefits

• No impact to OT environments from IT security vulnerabilities.
• If there is a single OT operational site (aka product group, asset), this aligns with the Purdue model.
• Makes separation/divestment operations easier as there are no dependencies with the IT tenant.

Drawbacks

• If there are multiple OT operational sites, there is a risk that one OT operational site could impact another.
• Additional operational and management overhead as there are now two tenants to manage.
• Duplication of identities.  User will have identities on both the IT and OT environment. IT identities will be required to access enterprise IT provided services (e.g. Office 365), OT identities would be required to access OT services.
• Duplication of infrastructure workloads/services (e.g. security appliances, management servers, etc).
• Additional license requirements (e.g. IT identities may be licensed with Microsoft 365 Business Premium licenses to provide Conditional Access capabilities to secure access to Office 365 and Azure. To secure OT access to Azure with Conditional Access capabilities, OT identities may need to be licensed for Azure AD P1/P2 licenses).
• For organisations with multiple OT operational sites this makes separation/divestment operations more complex. Several Azure resources have a dependency on the Azure AD tenant and may require downtime to recover the resource in the new tenant. A list of resources that could be impacted by a tenant transfer can be located here.

 

Option 2: IT tenant and OT tenant per Operational Site

This option maintains a separate Azure AD tenant for IT (contso.onmicrosoft.com), however, expands upon the OT tenant design. Instead of a single OT tenant, separate tenants are provisioned for each of the organisations OT operational sites. For example, we have Azure AD tenants for the Iron Ore (contosofe.onmicrosoft.com) and Copper (contosocu.onmicrosoft.com) OT parts of the business.

 

 

User accounts, groups and service principals would be independent of each operational site. By default, there would be no trust/access to resources between the OT operational sites and the IT tenant. This approach is suitable for organisations that have multiple OT environments and are looking to follow the Purdue model for cloud adoption.

 

This approach has additional benefits and drawbacks along with the ones discussed under Option 1.

 

Benefits

• Aligns with the Purdue model as each OT operational site is independent from each another.
• Makes separation/divestment operations easier as there are no dependencies between the IT environment and OT operational sites.

Drawbacks

• Duplication of OT identities (User could have identities across several OT environments).
• Increased operational costs:
• License requirements for each OT operational site.
• Infrastructure requirements for each OT operational site.

 

Option 3: IT tenant and OT tenant per Operational Site (Hybrid)  

This represents a combination of both Option 1 and Option 2. Azure AD tenant separation between IT and OT operational sites is maintained, however, the concept of a shared OT tenant (contosorenewables.ot.onmicrosoft.com) is introduced.

 

The shared OT tenant approach could be applicable for several use cases:

1. Some operational sites may have the budget, technical capabilities, and isolation requirements to justify their own tenant, others may not. It may make more sense for some operational sites to utilise a shared tenant instead (e.g. the Wind and Solar operational sites are utilising the contosorenewables.onmicrosoft.com tenant because they are do not require the level of isolation that the Iron Ore and Copper operational sites require).
2. There may be a requirement to have an OT tenant for shared services to operate out of (e.g. the organisation may want to operate a SIEM service for all OT environments under a single tenant).

This approach has a combination of the benefits and drawbacks discussed in Option 1 and Option 2 and will depend on the level of segregation between the operational sites.

 

The Azure AD tenant design (Converged or one of the Segregated options) is the first design decision that needs to be made when considering the cloud enablement of OT as this will influence the below design areas:

• IAM
• Network topology and connectivity
• Resource organisation
• Security
• Management
• Governance and
• Platform automation and DevOps

This decision should not be taken lightly as it can be quite complex to change once an organisation has deployed resources into the tenant. If you are unsure of which approach is best suited for the organisation, we recommend consulting with experts to determine the best fit.