5–4–3–2–1 — Cloud!

Scott Levac
Sep 20, 2019 · 5 min read

Co-authored in collaboration with Po T

The Government of Canada (GC) reached an important milestone with the launch of the GC Cloud Services Framework Agreement qualifying the first two providers, AWS and Azure, to host Protected B (PB)workloads.

Now that we have providers qualified, the question on everybody’s mind is “how and when can I access these providers?”. The Canadian Centre for Cyber Security, Shared Services Canada, and Treasury Board of Canada Secretariat have been working to describe that process. The result is the Operationalization Framework. Ooof, that’s a mouth full, isn’t it? I think we made up a word.

The goal of the Operationalization Framework is to implement a set of safeguards to protect GC cloud-based environments. This minimum set of guardrails will enable departments to maintain agility that is offered through cloud computing, but will also provide enterprise visibility.

Using the GC Cloud Services Framework Agreement alone does not make the environment ready to deploy PB data and systems. Through qualifying for the framework agreement, cloud providers services and operations have been security assessed. However, this is not a replacement for the departmental security and assessment activities. A department must still undertake those activities before deploying Protected B workloads into a production environment. The shared responsibility model is key in understanding why.

The shared responsibility model
The shared responsibility model
The shared responsibility model

In the shared responsibility model, everything you, as the consumer, layers on top of the providers’ platforms must be secured by departments. In an Infrastructure-as-a-Service (IaaS) model, consumers inherit the security services and controls of the cloud, but are also responsible for the security of the platform configuration, applications, data, and user access/identity. This is one reason why if you must build your own applications, we continue to advocate for using Platform-as-a-Service before IaaS. PaaS is a simpler model.

The Operationalization Framework will ensure key guardrails are established in every department’s tenant. Those guardrails focus primarily on:

  1. Identity and access management
  2. Data protection
  3. Network and perimeter
  4. Logging and monitoring

These guardrails are the focus as they can be applied without any workloads present and ensure that the environment is ready for future enterprise services.

Validation of these guardrails will be performed on a continuous basis through the GC Cloud Brokering services. Failure to respect these guardrails will be considered a violation of the terms of use of the GC Cloud Brokering service. Any violations will be escalated and in the worst case scenario, departments may lose their ability to self-service provision and configure some cloud services.

The framework’s minimum, mandatory guardrails can be found in the September 19th, 2019 attendee package for the Government of Canada Enterprise Architecture Review Board, but the process is as follows:

Operationalization Framework process

The guardrails originate from the Direction on the Secure Use of Commercial Cloud Services, which interprets existing GC security policy requirements in the context of cloud.

Again, the Operationalization Framework does not replace a security assessment and authority to operate. Implementation of these guardrails does not mean you can deploy PB data or systems to your cloud environment. (Are you tired of hearing that yet?)

The combination of the framework agreement, guardrails, the architecture found within the GC Accelerators, a department’s implementation of additional controls, processes, and policies will help your department achieve a secure foundation that is ready to host Protected B workloads.

Guardrails, not Gates

So why do we keep talking about guardrails? For some that may be a strange term to use. Traditionally, IT relies on process gating to police a user’s provisioning and configuration of a resource (compute, storage, network, etc…). Gates, however, often requires that the flow of work stops to allow for an external actor to arbitrate a decision point. This can lead to back logs as a queue of work waiting for arbitration accumulates. They are people intensive. Also, the arbitration can be based upon subjective criteria and lead to multiple interpretations of what is allowable and what is not. Gates interfere with the agility offered by cloud services.

Illustration of gating
Illustration of gating
In gating, flow must stop and wait for the gate keeper to arbitrate

This is why we prefer to implement guardrails. Guardrails keeps the flow of work within defined limits. These limits are typically enforceable through automation and monitoring. The boundaries can be quantitatively defined and applied equally across all flows of work. This is the perfect job for code. As long as the guardrails are respected work can continue uninterrupted. This allows the agility of cloud services to be maintained.

Illustration of guardrails
Illustration of guardrails
As long as guardrails are respected, flow can continue

Another way of thinking of gates versus guardrails is thinking back to the era of traffic police standing in intersections directing traffic. This person intensive gating did not scale well as traffic volumes grew. Additionally, a police person’s job was focused on repetitive compliance enforcement. With time, the practice of having a traffic police person in every intersection was replaced with automation; the traffic light. The police person’s job evolved to active monitoring for those who did not respect the gates enforced by traffic lights. Taken further, red light cameras are a new level of automation. This is an example of how governance can shift from gating to guardrails to maintain scalability and allow flow to continue.

What’s Next?

If your department is already using the existing public cloud services vehicle to build out a secure cloud-based environment that is aligned to the Government of Canada Security Control Profile for Cloud-based GC Services, then you’re probably in good shape to take the next steps towards using the new framework agreement. If you’re in a department with a legacy data centre closure on the horizon, you now have all the tools at your disposal to start migrating those workloads to cloud services. Policy, contracts, configurations,are all available. You as a department must build the skills and experience to use them with confidence.

Implementation of a trust, but verify model across the GC, like that Operationalization Framework, will enable departments to maintain agility, while enabling the central agencies to maintain visibility of GC information and assets that are now hosted in secure cloud service offerings.

Stratosphere

Unofficial online publication for the Government of Canada…

Scott Levac

Written by

Stratosphere

Unofficial online publication for the Government of Canada Core Technology and Cloud practice

More From Medium

More on Cloud from Stratosphere

Also tagged Government Of Canada

Top on Medium

Mar 25 · 22 min read

27K

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade