BU.1.03_alternate_storage.html.md 4.49 KB
Newer Older
Melissa Farber's avatar
Melissa Farber committed
1
---
2
layout: handbook-page-toc
Melissa Farber's avatar
Melissa Farber committed
3 4 5 6
title: "BU.1.03 - Backup Management: Alternate Site Control Guidance"
---
 
## On this page
7 8
{:.no_toc .hidden-md .hidden-lg}

Melissa Farber's avatar
Melissa Farber committed
9
- TOC
10
{:toc .hidden-md .hidden-lg}
Melissa Farber's avatar
Melissa Farber committed
11
 
12

Melissa Farber's avatar
Melissa Farber committed
13 14
# BU.1.03 - Backup Management: Alternate Storage
 
15

Melissa Farber's avatar
Melissa Farber committed
16 17 18
## Control Statement
GitLab backups are securely stored in an alternate location from source data.
 
19

Melissa Farber's avatar
Melissa Farber committed
20
## Context
21
GitLab backup copies of information, software and system images need to be stored in an alternate site in the event of a disruption to the primary storage location. This supports system availability and redundancy. The main take-aways are listed below: 
22 23 24 25 26 27 28

* GitLab establishes an alternate storage site including necessary agreements to permit the storage and retrieval of information system backup information;
* GitLab ensures that the alternate storage site provides information security safeguards equivalent to that of the primary site.
* Alternate storage sites must be geographically distinct from primary storage sites.
* An alternate storage site should maintain duplicate copies of information and data in the event that the primary storage site is not available.
* The alternate storage site should include agreements, such as: environmental conditions at alternate sites, access rules, physical and environmental protection requirements, and coordination of delivery/retrieval of backup media.
* The Alternate storage site's requirements must be reflected in the corresponding contingency plan, so that GitLab can maintain essential missions/business functions despite disruption, compromise, or failure in GitLab's information systems.
Melissa Farber's avatar
Melissa Farber committed
29
 
30

Melissa Farber's avatar
Melissa Farber committed
31 32 33 34
## Scope
Alternate storage controls should cover:
* gitlab.com
* customers.gitlab.com (Azure)
35
* licenses.gitlab.com (AWS)
Melissa Farber's avatar
Melissa Farber committed
36 37 38


## Ownership
39 40
* Control owner:  `Infrastructure`
* Process owner:  `Infrastructure`
Melissa Farber's avatar
Melissa Farber committed
41
 
42

Melissa Farber's avatar
Melissa Farber committed
43
## Guidance
44 45 46 47
Backup copies of GitLab information, software and system images need to be stored in an alternate site in the event of a disruption to the primary storage location. This supports system availability and redundancy. Before choosing an alternate site, the following points should be considered:

* Identify an alternate storage site that is separated from the primary storage site to reduce susceptibility to the same threats.
* Threats that affect alternate storage sites are to be defined in GitLab Risk assessments and must include, the following such as: natural disasters, structural failures, hostile cyber attacks, and errors of omission/commission.
Jeff Burrows's avatar
Jeff Burrows committed
48
* Based on the types of threat that are of concern, GitLab can determine what is considered a sufficient degree of separation between primary and alternate storage sites; but for the hostile cyber attack threat, the degree of separation between sites is less relevant.
49 50
* RTO/RPO for Alternate storage sites - The alternate storage site should be configured so as to facilitate recovery operations in accordance with GitLab's recovery time and recovery point objectives.
* The alternate processing site agreements must contain priority-of-service provisions, in accordance with GitLab's availability requirements (including recovery time objectives).
51 52 53
* Identify any potential accessibility problems to the alternate storage site, in the event of an area-wide disruption or disaster and outline explicit mitigation actions. 
* Area-wide disruptions refer to those types of disruptions that are broad in geographic scope (such as, hurricane, regional power outage etc). These determinations are based on GitLab's risk assessment policy.
* Duplicating backup information at other alternate storage sites if access problems occur at originally designated alternate sites
Jeff Burrows's avatar
Jeff Burrows committed
54
* Comprehensive plan & procedure documentation on GitLab alternate site information needs to be in the handbook   
55

Melissa Farber's avatar
Melissa Farber committed
56 57

## Additional control information and project tracking
Jeff Burrows's avatar
Jeff Burrows committed
58
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the [Backup Management: Alternate Storage issue](https://gitlab.com/gitlab-com/gl-security/security-assurance/sec-compliance/compliance/issues/780) . 
Melissa Farber's avatar
Melissa Farber committed
59 60
 
### Policy Reference
61
*  [GitLab Geo](https://docs.gitlab.com/ee/administration/geo/)
emilie's avatar
emilie committed
62
*  [Geo Enablement](/handbook/engineering/development/enablement/#geo)
63 64
*  [Enablement Team: Jobs to Be Done for Geo](/handbook/engineering/ux/stage-group-ux-strategy/enablement/#ux-scorecards)
*  [Geo Planning](/handbook/engineering/development/enablement/geo/process.html)
65

Melissa Farber's avatar
Melissa Farber committed
66 67 68 69 70 71
## Framework Mapping
* ISO
  * A.12.3.1
* SOC2 CC
* SOC2 Availability
* PCI
Nik Sarosy's avatar
Nik Sarosy committed
72
    *  9.5.1
73 74
* NIST
    *  CP-6 
Nik Sarosy's avatar
Nik Sarosy committed
75