Questions about governance are frequently asked by users who are new to the public cloud. Before focusing on the public cloud environment, which is a bit different from enterprise (on premises) environments, let’s discuss governance. If you have ever worked as part of a management team in an enterprise environment, you know very well the significance of governance. Those who work in technical roles also know the importance of governance as it’s applicable organization-wide. The common questions addressed by governance are:
- How do you run/operate an organization?
- Who should be performing roles and what authorization privileges should a particular employee have?
- What is your organizational hierarchy (how many business units, departments, branches, sub-units and so on)?
- Which standards (legal, industry-specific, trade and so on) and organizational policies are enforced and how do you ensure their compliance?
- How do you allocate the budget across the organization and its units?
- The list goes on…
How do you govern if your organization has partially or completely migrated its assets, resources, services, apps, and/or workloads to the public cloud like Azure, AWS, GCP, or similar? Depending on your nature of business and industry, you may be subject to compliance with standards like HIPAA (healthcare industry-specific standard), PCI-DSS (trade merchants), ISO 27001, NIST, and so on. Remember, the public cloud consists of global chains of hyperscale data centres where you can deploy rented resources, assets, services, apps, and workloads remotely and don’t have physical access. How do public cloud customers incorporate governance in these scenarios? Let’s investigate typical factors that help customers govern their assets in the public cloud.
Organization-wide hierarchy
Every organization’s size and hierarchy is different. Non-operational groups can be created to represent the hierarchy of your organization in the public cloud. These groups do not include users, they just represent the scope and boundary where roles, policies, and billing restrictions can be applied. These groups, which represent the branches of your organization, can be defined by a parent/child tree structure. There are generally no restrictions to the number of groups being created, however they all fall under your main tenant group. Child groups inherit policies from their parent group so care must be taken when selecting the scope of a particular standard, policy, role, and/or billing subscription.
Enforcing standards
Depending on its nature, your business can be subject to legal, industrial, or trade-specific standards and remaining in compliance is a mandatory requirement. You can enforce these standards at the appropriate level by defining the scope of each hierarchical group created. Templates for common standards are usually fed into the public cloud by operators and can be invoked by customers. Standards like NIST, HIPAA, PCI-DSS, and ISO 27001 are usually available but if you have custom requirements, you can also use your own templates. Once a standard is invoked at an appropriate scope, you (as the customer) can monitor its compliance for audit purposes on a regular basis.
Applying policies
Customers can also invoke policies that cater to their organization’s directions, guidelines, recommendations, and so on. Just like an enterprise organization has policies like bring your own device (BYOD), personal use of corporate phones and computers, Internet access for visitors, and so on, there can also be policies relevant to your public cloud resources and assets. For example, a common public cloud policy is to deploy resources/assets in a specific geographical location only. Another example would be to order only a specific size of virtual machine (CPU/RAM) or to apply labels to all newly created resources. The customer will need to find the required policy template from a built-in pool of policies and apply it at an appropriate scope or produce their own custom policy template if the required one is unavailable. Exclusions can be included if you want this policy to not affect a specific group of your organization. Once applied, compliance to this policy can be monitored.
Authorization (who can access what?)
Not every employee in your organization requires the same authorization when it comes to accessing resources. Depending on what you do or what your job description is, you are given appropriate authorization to use, configure, consume, and manage resources based on a least-privilege rule. For example, as a blog writer, I don’t have authorization to access HR records. Similarly, database operators have read-only permissions (no write privileges). Like the enterprise environment, authorizations can be granted for employees according to the organization’s public cloud hierarchical structure and policies. These authorizations can be reviewed from time to time to ensure security, compliance, and safety as employees leave organizations, get transferred to other departments, or promoted to new roles.
Use of labels
Labels are very helpful for identifying particular resources. Labels can also help with controlling the cost of resources acquired over the public cloud. You can also reference labels from within scripts when running automation tasks, including keeping track of the expenditure of your project(s) at various stages of completion.
Billing and subscriptions
How do you pay for your organization’s deployed public cloud resources, assets, workload, services, and apps? It’s usually through subscription accounts. Typically, there are various levels of subscription offered by cloud operators ranging from enterprise grade to free trial. Your organization may have just one or several subscriptions. Separate subscriptions are useful for different departments. Applying these subscription accounts at the appropriate scope (hierarchical group) in your organizational tree is important.
Infrastructure as code templates
One of the best features of the public cloud is that you can deploy resources via coded templates, written in data exchange formats. Use of these templates brings consistency, speed, and an error-free deployment experience. As an organization, you can restrict your users to deploying resources only from an available set of templates kept in either a local or remote repository.
Import and export of environment
For large organizations, having various branches and a global presence in the public cloud, the environments can also be imported and exported. These environments bring consistency of authorization rules, policies, labels, standards, organizational hierarchy, templates, and so on. Import and export makes it easier for various branches of the same organization to maintain consistent governance.
I hope you enjoyed reading this blog and that it has answered at least some of your questions. Comment below if you need more specific help, and please keep learning and broadening your knowledge using the resources and training available offered by APNIC.
Azhar Khuwaja is a Telecom/IT Trainer with over 20 years of industry and training experience.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.