Control and Governance

Introduction

Control and governance provide the foundation for how to secure your cloud. The implications of control and governance will be reflected throughout your cloud architecture design.

At its most simple level, governance is about deciding and controlling who is allowed to do what.

Organizations typically have a governance model that has been designed and implemented over many years. It incorporates many different aspects of governance. When moving to the cloud, the new cloud environment opens up entirely new challenges. Initially, you could re-use or extend the existing governance model. However, to get the maximum benefits, we recommend explicitly designing an appropriate cloud model. This will allow the benefits of standardization and automation to be fully realized.

Harnessing the Power of Automation

The new cloud model offers a shift from manual administration (e.g. by DBAs, System Admin) to a much more automated model. This is commonly referred to as “infrastructure-as-code” (IaC).

In the cloud, we consider any resource that can be managed through an infrastructure API to be a candidate for automation and IaC. In Oracle terms, this means any Oracle Cloud Infrastructure (OCI) service that can be deployed and managed through a recognized OCI API.

The power of IaC is a double-edged sword. The same automation that allows massive deployments from single user interactions can also destroy complete systems. The objective of any governance model then is to segment responsibilities into sets. These can then be allocated to groups of people such that accidental or deliberate damage is minimized. This is sometimes called the “blast radius” of a change.

Determining Levels of Control

A good governance model will also provide “safe” environments where people can work without fear of damaging other settings. This results in a strong level of effectiveness and relevant autonomy across the organization.

When we define the governance model, we need to think about which groups of people should be allowed to do which tasks. This is not always as straightforward as it might appear.

For example, some permissions will differ between environments, even for the same application. It might be reasonable for developers to create and drop virtual networks in a development environment. The same would not be true for production. There will likely be multiple sign-offs required before such a destructive change is authorized.

When we talk about a “task” in this context, we mean executing a change on a specific resource. A resource is typically an instance of a cloud service. It might be to execute a change to open a network port, or it might be to deploy or destroy a service.

OCI Control Structures

In OCI, there are several logical and physical structures that enable us to design an organizational hierarchy. Building this extendable hierarchy is the core implementation of the control and governance model.

Logo

The principle structures to consider are;

This topic will consider how these structures, when combined, deliver the control and governance you need. This has relevance for all OCI deployments from the smallest to the very largest enterprise deployments.