Introduction
These standards of governance for cloud computing resources are intended to set expectations regarding the controls that Connor Group’s IT operation team uses to ensure proper management of these resources in terms of cost control, fitness of purpose, accountability, and security.
These governance standards are grouped primarily by three environmental classifications: development, beta, and production. Each environment has independent expectations for access control, availability, lifecycle, and recoverability.
Access Control
Access controls determine who or what entities can access a resource and under what conditions access is allowed. Standard identity access management (IAM) tooling, such as Entra ID, is preferred. Other mechanisms for verifying the identity of persons or services may be used depending on a system's technical capabilities.
Lifecycle
Lifecycle controls are used to set an end date for when a service is expected to be in place. These are necessary to reduce the effect of cost creep and keep the security profile of company resources in check. We help keep overall costs in check and reduce the risk profile of the company by turning down resources that have an unknown or ambiguous purpose.
The lifecycle control is implemented through an attestation by the resource owner for the business process that the resource facilitates. The resource owner shall evaluate the resource for fitness of purpose, cost, and security profile. Following that evaluation, the resource owner shall indicate when the next attestation for the resource shall occur based on their assessment of the resource's expected lifecycle. This attestation shall be made on a regular recurring basis through a process that produces an artifact indicating when the next evaluation of the resource should occur.
Availability
Setting clear expectations for the availability of a resource with distinctions between environments allows for the maintenance of existing systems, the addition of new features, and helps ensure that hidden dependencies for production systems are not created, or do not linger. Along with lifecycle controls, clear expectations about availability are communicated to developers and systems engineers where there are clear lines of demarcation between environments that must not be crossed. Clear expectations for availability also help developers and system engineers identify when additional needs for backups of data shall be implemented as well as set acceptable recovery windows.
Furthermore, “uptime” comes at a cost. Software developers and system engineers need to reach a consensus about an appropriate environmental fit for a resource and what related resources need to be considered to meet expectations.
Recoverability
Recoverability expectations for cloud resources are made explicit to set expectations for what resources need to be backed up and who is responsible for assessing the risk to data or configuration.
Generally, cloud computing platforms do not include any expectation for data protection and recoverability in their platforms. The platforms explicitly state that data protection is a shared responsibility.
Shared responsibility in the cloud - Microsoft Azure | Microsoft Learn
Governance Standards
Environments
Production
Production environments imply an expectation of availability and data integrity consistent with the ongoing and nearly uninterrupted use of resources for supporting business operations.
Access Control
Production systems implement access controls with established identity and access management (IAM) systems in a manner consistent with the principle of “least privileges necessary”. “Owner” rights on resources are limited to only IT management or their delegates to the extent this is technically feasible.
In simpler terms, Only IT manages access controls in production systems. Even if you have the technical ability to grant rights to a production resource, you are not permitted to do so unless you have specific documented permission from IT management to do so.
Lifecycle
For production systems, generally, this evaluation cadence will happen semi-annually but may be designated for up to two years.
Availability
Production systems are expected to be sufficiently reliable for the general user base of the company such that downtime does not cause a material disruption to business productivity.
Recoverability
Production systems that support business operations should be fully recoverable from a disaster, including infrastructure and data. Infrastructure is primarily recoverable through infrastructure as code (IaC) tooling, such as Terraform configuration stored in Git source control repositories. Data should be recoverable to the degree that it impacts business operations.
Beta
Beta environments exist for testing or validating changes to systems or processes prior to release into the production environment. Nothing in the Beta environment may be a dependency for anything in production or vice-versa.
Access Controls
The Beta environment follows the same access control policy as production. Beta systems implement access controls with established identity and access management (IAM) systems in a manner consistent with the principle of “least privileges necessary”. “Owner” rights on resources are limited to only IT management or their delegates to the extent this is technically feasible.
In simpler terms, Only IT manages access controls in Beta systems. Even if you have the technical ability to grant rights on a Beta resource, you are not permitted to do so unless you have specific documented permission from IT management to do so. IT may be more flexible in granting permissions to resources in this environment, but doing so is still under the discretion of IT management.
Lifecycle
Evaluation cadence will happen semi-annually, in line with production, and may be designated for up to two years.
Availability
Beta systems are expected to be sufficiently reliable for the beta user base. Beta downtime should not cause a material disruption to business productivity for beta environment consumers or contributors. While the expectation is that Beta stakeholders be made aware of planned downtime, Beta resources may occasionally undergo unexpected maintenance and downtime without notice.
Recoverability
Beta infrastructure is recoverable from a disaster through IaC configuration repos. There is no expectation of recoverability for data that exists in this environment. Data in this environment is transient and can be recovered from production in the event of a disaster.
Dev
Development (Dev) environments are for creating and testing new processes or systems that do not exist in Production. Sandbox environments are synonymous with Dev environments.
Access Controls
Access controls and identity management are individually managed by the Dev owner, including the possibility of anonymous access. Dev environments can allow connections to external systems for pulling data in or out but cannot contain any sensitive data.
Lifecycle
Resource evaluation will happen every 12 weeks. When properly tagged resources are evaluated, users of the resource will be notified. Resources that are not properly tagged are subject to deletion without notice.
Availability
There is no expectation of stability or uptime for the Dev environment as a management concern from IT unless otherwise agreed upon in advance. We recommend that users save their work frequently and be aware that downtime may occur unexpectedly.
Recoverability
There is no expectation of data or resource recoverability in the Dev environment as a management concern from IT unless otherwise agreed upon in advance. Users must be prepared to recover their resources and data if necessary. We recommend that users document the process they followed to create their resources and backup their [non-sensitive] data to other locations (e.g. OneDrive or Local). Using IaC tooling and automation platforms, such as Terraform, Ansible, Puppet, templates, or Desired State Configuration, can make configurations and environments easily disposed of and reproducible in a consistent fashion.
Subscriptions
Tenants or subscriptions must be registered with and approved by Connor Group IT.
Development Subscriptions
O365AF [o365af]
- This Azure tenant and subscription are for short-term learning and experimentation ONLY.
- Short-term means 2 weeks or less in the context of this subscription.
- This is NOT an environment for hosting pre-beta development projects and should NEVER be tied into resources used with any other tenant or subscription.
- Resources and experiments in this subscription shall not be used as a stopgap for getting a configuration implemented in a proper subscription.
- All resources in this tenant are considered ephemeral and may be deleted at any time without notice.
- There is no expectation that data in this tenant has any backup or disaster recovery controls in place.
Visual Studio License Grant Subscriptions
- These subscriptions default to an association with the GP1 Entra ID tenant. They're granted through activation of a Visual Studio subscription benefit through my.visualstudio.com. They include $50 per month in credits for the Visual Studio subscriber to use to explore and test Azure services. The subscriber can activate this subscription without needing to provide payment card information. When the included credits are exhausted in a billing cycle, Azure shuts down the resources until the next billing cycle starts.
- There are no tagging policies with these subscriptions, and they are not managed by IT.
- Resources in these subscriptions must NEVER be used to support projects and applications that anyone other than the assigned Visual Studio subscriber interacts with.
Beta Subscriptions
Connor Group Global Services Beta [connorggs]
- The purpose of this subscription is to mimic the Connor Group Global Services Production subscription as closely as possible.
- This subscription is not a playground/sandbox, but a test environment for resources intended to roll out in the “Connor Group Global Services Production” subscription.
- This subscription follows the governance standards of the Beta environment
Connor Group R&D Pre-Production [connorgp1]
- The purpose of this subscription is to mimic the Connor Group R&D Production subscription as closely as possible.
- This subscription may be used as a short-term dev environment for resources. Any resources with missing or stale lifecycle or ownership tags may be deleted at any time without prior notice.
- More generally, this subscription is a test environment for resources intended to roll out in the “ConnorGroup R&D Production” subscription.
- This subscription follows the governance standards of the Beta environment
Production Subscriptions
Connor Group Azure [connorgp1]
- This subscription contains various Beta and Production resources needed for the business to function.
- The long-term deployment or decommissioning of resources must receive IT management approval.
- Resources created in this subscription are created with the intention to work in production environments
- Any temporary testing or production resources must be documented and appropriately tagged
- This subscription follows the governance standards of the Prod environment
Connor Group – Digital Solutions [connorgp1]
- This subscription primarily contains resources for FinOps / Digital Solutions business activities.
- The long-term deployment or decommissioning of resources must receive IT management approval.
- This subscription follows the governance standards of the Prod environment
Connor Group R&D Production [connorgp1]
- Resources in this subscription have been previously tested in the Connor Group R&D Pre-Production subscription.
- This subscription follows the governance standards of the Prod environment
Connor Group Global Services Production [connorggs]
- Resources in this subscription have been previously tested in the Connor Group Global Services Beta subscription.
- The long-term deployment or decommissioning of resources must receive IT management approval.
- This subscription follows the governance standards of the Prod environment