There are four essential elements to consider when developing a governance structure for your cloud journey. Failure to address these points frequently leads to a variety of pains that are difficult to undo. These four elements are as follows:<\/p>\n
\u2022 Subscriptions matter.
\n\u2022 The network has to come first.
\n\u2022 Security is essential.
\n\u2022 Automation is required<\/p>\n
The fundamental container of resources in Azure is the subscription. How many subscriptions do you need? Start with three and grow beyond that based on these conditions:<\/p>\n
\u2022 Subscription capacity is exhausted.
\n\u2022 Acquisition and ownership (not just management) of Azure resources takes place in multiple geographical\/political\/regulatory jurisdictions.
\n\u2022 The \u201cthing\u201d being deployed to Azure is part of your company\u2019s \u201ccost of goods sold.\u201d<\/p>\n
This works for most companies. The first subscription is Production, where no standing security access exists (except for your CI\/CD runners) outside of Reader roles. The second is Not Production. This subscription is where coor\u2010 dinated nonproduction tiers exist (Dev, Test, Int, Stage, PreProd), with an increasing security posture as the tier level approaches production. The third is your Hub subscription, where core networking, ExpressRoute circuits, etc. are housed and heavily restricted. Visual Studio subscriptions should be pro\u2010 vided to developers and IT pros for them to learn and do playground-based work. Keep a tight policy lock on these to prevent data exfiltration. When the developer or IT pro is ready to integrate with others, they move into the con\u2010 trolled Not Production subscription.<\/p>\n
You cannot govern the cloud without a stable network topology. No amount of serverless or PaaSification of your environment eliminates the need for proper design, operation, and control of networking. These designs tell your application how to operate securely, fail over, and survive a data loss. Ignor\u2010 ing the network is a tragic and expensive mistake. You need not use hub\u0002and-spoke routing and record all traffic. Other solutions exist that better lend themselves to modern network security and intrusion\/breach preven\u2010 tion than forced tunneling, like Azure Security Center, Monitor, and Advisor for detailed, live introspection on what is happening in your environment in a correlated manner.<\/p>\n
Implementing least privilege access and regular account reviews is essential. RBAC, principally applied at the resource group level via automation with zero standing access to production, helps prevent a whole host of unwanted experiences. Adopting an \u201cassume breach\u201d stance for everything allows you to focus your data protection efforts where they matter most: in the source system. Subscription-level access should be limited to your automation accounts, break-glass account, and audit solutions (read-only). Privileged identity management and multifactor authentication (MFA) for sensitive operations should be the norm. The need to \u201csee\u201d things via the portal or CLI should diminish the closer you get to production. For example, it is not necessarily true that the SQL administrators need full permissions to the resource groups where the SQL servers are located. Perhaps they need only Reader rights, or no rights except to the emitted logs. You should never allow a change to production absent automation. If you do, your disaster recovery strategy is invalid.<\/p>\n
You cannot effectively manage the cloud via the portal. You cannot effec\u2010 tively govern or secure the cloud without automation. There are simply too many moving parts, too many places to make a mistake, and far too many neat little buttons to push. Starting in your development tier, teams should have portal access to help craft automation scripts that include not just the application, but also the infrastructure and the configuration. As you move closer to production, the rights should be reduced at each tier until nothing but access to the emitted logs remains. This final step is hard and represents an ongoing journey. Reasons will always exist for deviation from automa\u2010 tion, but those should be backported to your CI\/CD pipelines to return your environment to an automated state for deployments, monitoring, and recovery.<\/p>","protected":false},"excerpt":{"rendered":"
There are four essential elements to consider when developing a […]<\/p>","protected":false},"author":1,"featured_media":4985,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[121,126],"tags":[123,127],"class_list":["post-4929","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-computing","category-cloud-security","tag-cloud-computing","tag-cloud-security"],"yoast_head":"\n