In our journey to help cloud enable Operational Technology (OT) environments, we have published the following articles:
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:
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:
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.
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.
Depending on the size and complexity of the organisation, the Segregated Model has several approaches that could be adopted:
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.
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.
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:
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.