How your users are authorized and authenticated is often one of the first considerations. Will you use a single Active Directory for all users? Will you have multiple directories for different environments? Will you combine internal users and external clients using guest accounts or separate them? For example, Azure offers B2B and B2C integrations that allow you to connect users in other Azure tenants (B2B) or users using different identity providers, such as Facebook and Google (B2C). We cover the different options in Chapter 3, Understanding User Authentication.
Network topology
Will your solutions all be externally facing only? Or is there a need to integrate with an on-premises network?
Companies born in the cloud often expose services directly to the internet using native options, especially if all those services are client-facing. Established organizations may have a desire to integrate with existing traffic control and protection measures, such as utilizing existing firewalls, or perhaps a hybrid approach where Azure traffic leverages native Azure firewalls and you wish to route all traffic through such a device.
Governance
Many organizations have strict policies on auditing and enforcing specific security models. Will these policies be implemented in each subscription, and if so, how can we control it and ensure that those policies are adhered to?
Disaster recovery and backup
What will your backup strategy look like from a point of view of control and monitoring? Does each application have responsibility for ensuring adequate backups are taken, and each solution defines its own disaster recovery solution? Or will you design a central strategy and ensure that it is followed? As services such as Azure Backup are charged according to the amount of storage used, you need to decide who will be responsible for costs.
For example, will you use a central backup strategy with costs picked up by the operations teams? Or will you opt for a decentralized model whereby each solution is paid for, and backups managed by, the individual service owner?
Monitoring and operations
Do you use existing monitoring tools such as Microsoft’s Service Center Operations Manager (SCOM)? Or will you leverage existing tools? Will all your components log to a central log analytics workspace, or will you decentralize logging and have each service owner be responsible? How will this affect security monitoring?
Ultimately, many areas come down to a choice between centralization or de-centralization. This affects costs as well as operational responsibility. For example, having a centralized log analytics workspace means costs and operations are also centralized.
We also need to consider how we configure each element to utilize our chosen strategy – for example, if we want all components to log diagnostics to a central log analytics workspace, we can create policies that will perform a deployIfNotExists action whenever the resource is created.
The following diagram shows one such example architecture that considers all these ideas in a single, high-level blueprint:
Figure 19.1 – Example landing zone blueprint
The final point to consider is whether you will define and build your landing zone strategy before any deployments are allowed, or whether you will build up your overall solution over time, which we will consider next.
Leave a Reply