Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security design #12

Merged
merged 2 commits into from
Oct 8, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
<!-- markdownlint-disable MD041 -->

## Description

Please provide a brief summary of the changes made in this pull request.
Expand Down
Binary file removed docs/assets/nhs-logo.png
Binary file not shown.
702 changes: 702 additions & 0 deletions docs/assets/security-design.drawio.svg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
114 changes: 113 additions & 1 deletion docs/design.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,6 @@

<!-- markdownlint-disable MD024 -->

# Design

## Overview
Expand Down Expand Up @@ -25,14 +28,123 @@ The following diagram illustrates the high level architecture:

1. The **backup vault** accesses resources to be backed up through a **System Assigned Managed Identity** - a secure way of enabling communication between defined resources without managing a secret/password, which is assigned the necessary roles to the resources that require backup.

1. **Backup administrators** are a group of identities that will have time limited read only access to the **backup vault** in order to access and restore backups as required. Assignment of the role will be secured by **PIM** - Privileged Identity Management, which requires a second identity to authorise the role assignment, which is then assigned on a time limited bases. The **backup administrators** will also be responsible for monitoring and auditing backup activity via **Azure Monitor** (see **point 6** for more details).
1. **Backup administrators** are a group of identities that will have time limited read only access to the **backup vault** in order to access and restore backups as required. The **backup administrators** will also be responsible for monitoring and auditing backup activity via **Azure Monitor** (see **point 6** for more details), although this task may be delegated to service staff performing the role of **backup monitors**.

1. The solution requires a user account with elevated subscription contributor permissions that can create the backup resources (such as the backup **resource group** and **backup vault**) and assign roles to the resources that require backup. This identity should be implemented as a **federated credential** of an **app registration**, which is like a passport that lets you access different services without needing to manage a separate password. The identity also needs writer access to a dedicated **Storage Account** in order to read and write the **terraform** infrastructure state. See the [deployment identity](usage.md#deployment-identity) section for more details.

1. All backup telemetry will flow into **Azure Monitor** for monitoring and auditing purposes. This will provide access to data such as backup logs and metrics, and provide observability over the solution. Should the need arise, the telemetry could also be integrated into an external monitoring solution.

1. Some resources such as Azure SQL and Azure Key Vault are not directly supported by Azure **backup vault**, but can be incorporated via a supplementary process that backs up the data to Azure Blob Storage first. In the case of Azure SQL, a typical scenario could be an Azure Logic App that takes a backup of Azure SQL on a regular basis and stores the data in Azure Blob Storage. It is the aspiration of this solution to provide guidance and tooling that teams can adopt to support these scenarios.

## Security Design

The following diagram illustrates the security design of the solution:

![Security Design](assets/security-design.drawio.svg)

See the following links for further details on some concepts relevant to the design:

* [Azure Multi-user Authorisation (MUA) and Resource Guard](https://learn.microsoft.com/en-us/azure/backup/multi-user-authorization-concept)
* [Backup Operator Role](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/storage#backup-operator)
* [Azure Privileged Identity Management (PIM)](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management)

### Actors

> NOTE: The roles listed below are not an exhaustive list, and are only those which are of relevance to the backup solution.

1. Tenant Admin

The tenant admin, aka the "global administrator", is typically a restricted group of technical specialists and/or senior engineering staff. They have full control over the Azure tenant including all subscriptions and identities.

The actor holds the following roles:

* Tenant Owner
* Tenant RBAC Administrator

The following risks and mitigations should be considered:

| Risks | Mitigations |
|-|-|
| Backup instance tampered with. | Use of PIM for temporary elevated privileges. |
| Backup policy tampered with. | Use of MUA for restricted backup operations. |
| Role based access tampered. | Dedicated admin accounts. |
| No other account able to override a malicious actor. | |

1. Subscription Admin

The subscription admin is typically a restricted group of team leads who are deploying their teams solutions to the subscription. They have full control over the subscription, including the backup vault and the backup resources.

The actor holds the following roles:

* Subscription Owner
* Subscription RBAC Administrator

The following risks and mitigations should be considered:

| Risks | Mitigations |
|-|-|
| Backup instance tampered with.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Use of PIM for temporary elevated privileges. |
| Backup policy tampered with. | Use of MUA for restricted backup operations. |
| Role based access tampered. | |

1. Deployment Service Principal

The deployment service principal is an unattended credential used to deploy the solution from an automated process such as a pipeline or workflow. It has the permission to deploy resources (such as the backup vault) and assign the roles required for the solution to operate.

The actor holds the following roles:

* Subscription Contributor
* Subscription RBAC Administrator limited to the roles required by the deployment

The following risks and mitigations should be considered:

| Risks | Mitigations |
|-|-|
| Backup instance tampered with.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Use of PIM for temporary elevated privileges. |
| Backup policy tampered with. | Use of MUA for restricted backup operations. |
| Role based access tampered. | Secret scanning in pipeline. |
| Poor secret management. | Robust secret management procedures. |

1. Backup Admin

The backup admin is typically a group of team support engineers and/or technical specialists. They have the permission to monitor backup telemetry, and restore backups in order to recover services.

The actor holds the following roles:

* Subscription Backup Operator

1. Backup Monitor

The backup monitor is typically a group of service staff. They have the permission to monitor backup telemetry in order to raise the alarm if any issues are found.

The actor holds the following roles:

* Monitoring Reader

1. Security Admin

The security admin is typically a group of cyber security specialists that are isolated from the other actors, by being in a different tenant or a highly restricted subscription. They have permissions to manage Resource Guard, which provide multi user authorisation to perform restricted operations on the backup vault, such as changing policies or stopping a backup instance.

The actor holds the following roles:

* Subscription Backup MUA Administrator

| Risks | Mitigations |
|-|-|
| Elevated roles note revoked.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Use of PIM for temporary elevated privileges. |
| | Robust and well documented processes. |

**NOTE: MUA without PIM requires a manual revocation of elevated permissions.**

1. Backup Vault Managed Identity

The backup vault managed identity is a "System Assigned" managed identity that performs backup vault operations. It is restricted to just the services defined at deployment, and cannot be compromised at runtime.

The actor holds the following roles:

* Backup Vault Resource Writer
* Reader role on resources that require backup

## Terraform Design

The following diagram illustrates the terraform design:
Expand Down
Loading