Overview

This is the first blog post in a series that will cover the subject of break-glass for an OCI account. This post will give a brief introduction to the subject of break-glass, in general and from an OCI perspective. It will cover some common strategies for implementing an OCI break-glass mechanism and process. The rest of the series will present a detailed design and implementation of one of the introduced strategies.

Update : part two , part three, part four

In case of Emergency Break Glass  

In Case Of Emergency Break Glass

Break-glass is a term that describes the common practice of placing the trigger of an alarm behind a protective glass pane. The pane presents a physical barrier that has to be broken to allow access to the alarm. The idea is that the alarm is available when the steadfast intent is to sound the alarm in an actual emergency. At the same time, there is a barrier to prevent ( or at least strongly discourage ) non-emergency activation of the alarm.

In Information Technology (IT), the term is used metaphorically to refer to the processes, and mechanisms, that are used to obtain highly privileged access in the event an IT emergency occurs that cannot be addressed within the bounds of established Segregation of Duties (SOD) and least-privileged based access controls.
It is an apt metaphor in the sense that the effective IT break-glass process and mechanism has to be accessible in case of an emergency, yet must be protected against unauthorized, non-emergency use.

Emergency Access only

Break-glass is distinguished from other Privileged Account Management (PAM) use cases by its, ideally, exceedingly rare occurrence. It is only used in response to a critical emergency that requires full access privileges as a last resort. With this in mind, we can further define the desired features of an effective “break-glass” process.

The process should:

  • Be highly available and responsive.
  • Be highly restricted in terms of who can initiate it. In general, it should be restricted to the team ultimately responsible for getting the system back online in an absolute emergency.
  • Be risk assessed.
  • Facilitate expedited approval by a Change Advisory Board (CAB).
  • Ensure that assigned break-glass entitlements are short-lived. After the emergency is resolved the entitlement(s) must be de-provisioned immediately.
  • Ensure that changes made to the system, using the break-glass entitlement, are audited and reviewed after the emergency has been resolved.
  • Be tested regularly to verify availability and effectiveness.

Break-Glass from an OCI Point of View 

In an OCI tenancy, with a well-designed access model that follows Segregation of Duties (SOD) and least-privileged security principals, the day-to-day OCI admin activities will not require full access privileges that are concentrated in one or more OCI admin accounts. Furthermore, emergency access, which can reasonably be foreseen, will likewise distribute the privileges needed to fix the emergencies within the established access model.
However, even with such a carefully designed access model, we cannot eliminate the possibility that an unforeseen emergency might occur for which our model cannot account. In such an event, we need the option to bypass the established model and concentrate the highest level of access privileges in OCI into one or more break-glass accounts.

The OCI Administrators Group

All OCI accounts come with a default Administrators group, as well as a default IAM policy that allows members of the Administrators group full access to all resources in an OCI account. Furthermore, an OCI implementation user is added to this group by Oracle in order to perform the initial security build-out of the account, including the access model.
Membership to this existing Administrators group is therefore, a suitable OCI entitlement that will provide break-glass users the ability to transcend the established access model and gain full control over the resources in the account (including over the access model itself).

This initial implementation user is the “Cloud Account Administrator” and after establishing the foundation of the account’s security, this user’s access should be disabled to prevent the user from using their superpowers without going through the break-glass process. More on this later.
An alternative entitlement that could be assigned to a break-glass account is the OCI IAM Default domain’s Identity Domain Administrators role. A discussion on how to implement OCI break-glass using this role entitlement is beyond the scope of what we’ll cover in this series. Suffice it to say that the design and implementation that will be presented can be modified to accommodate other suitable OCI break-glass entitlements.

Break-Glass Mechanisms 

Having identified the group entitlement we want to grant to a break-glass user, we now consider some of the OCI mechanisms that are suitable for granting Administrators group membership in the course of the break-glass process:

Just in Time Provisioning (JIT) of the Break-Glass Identity and API Key credentials 

With this mechanism, a dedicated break-glass identity is created and added to the Administrators group. An OCI API key is also created and configured for this identity during the break-glass process. Furthermore, this OCI identity will be configured to only allow API key credentials. This will ensure that the relevant OCI API Key will be the only valid credential for the break-glass identity to authenticate to the OCI control plane. At the end of the break-glass event, the identity and the associated API key is de-provisioned, removing break-glass access.

JIT Group Entitlement 

This mechanism adds existing OCI account users to the Administrators group, during the break-glass process, thereby elevating their privileges in OCI. De-provisioning a break-glass entitlement entails removing the users from the Administrators group, thereby returning them to their pre-breakglass level of access in the account.
With this strategy, the break-glass account is a true user identity and the management of the credentials required to authenticate to the account can be performed by the established Identity Management processes in place in an organization.

The Break-Glass Process: ITIL Emergency Change Request 

Now that we understand some of the OCI mechanisms that are available to provision break-glass identities, credentials, and entitlements, we need a suitable process to embed these mechanisms into.
The Information Technology Infrastructure Library (ITIL) is a widely adopted framework of best practices for delivering IT services. Among other things ITIL defines common Information Technology Service Management (ITSM) processes. One such process of particular interest for the break-glass use case is the ITIL Emergency Change process that is presented in the following illustration:

ITIL Emergency Change Happy Path

 

We chose the ITIL Emergency Change rather than the ITIL (non-emergency) Change because of the time-critical nature of an emergency that warrants a break-glass event. The implication is that the authorization of the change cannot wait on a full CAB approval meeting being conducted. Rather, an expedited Emergency Change Advisory Board (ECAB) approval is required by on-call ECAB members.
Other desirable features of the ITIL Emergency Change (EC), in the context of our stated break-glass requirements, are that Emergency Change accommodates a pre-approval risk assessment as well as a post-implementation review (PIR) of the changes.

Conclusion

In the next blog post in the series we will discuss an OCI break-glass design that embeds one of the mechanisms that we discussed above within an implementation of the ITIL Emergency Change process provided by a market-leading ITSM solution.