diff options
Diffstat (limited to 'doc/administration/geo/replication/security_review.md')
-rw-r--r-- | doc/administration/geo/replication/security_review.md | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/doc/administration/geo/replication/security_review.md b/doc/administration/geo/replication/security_review.md index 832d02be9a5..68bf5b5d23a 100644 --- a/doc/administration/geo/replication/security_review.md +++ b/doc/administration/geo/replication/security_review.md @@ -1,9 +1,9 @@ # Geo security review (Q&A) **(PREMIUM ONLY)** -The following security review of the Geo feature set focuses on security -aspects of the feature as they apply to customers running their own GitLab -instances. The review questions are based in part on the [application security architecture](https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet) -questions from [owasp.org](https://www.owasp.org). +The following security review of the Geo feature set focuses on security aspects of +the feature as they apply to customers running their own GitLab instances. The review +questions are based in part on the [OWASP Application Security Verification Standard Project](https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project) +from [owasp.org](https://www.owasp.org/index.php/Main_Page). ## Business Model @@ -30,7 +30,7 @@ questions from [owasp.org](https://www.owasp.org). private projects. Geo replicates them all indiscriminately. “Selective sync” exists for files and repositories (but not database content), which would permit only less-sensitive projects to be replicated to a **secondary** node if desired. -- See also: [developing a data classification policy](https://gitlab.com/gitlab-com/security/issues/4). +- See also: [GitLab data classification policy](https://about.gitlab.com/handbook/engineering/security/data-classification-policy.html). ### What data backup and retention requirements have been defined for the application? @@ -49,9 +49,9 @@ questions from [owasp.org](https://www.owasp.org). ### How do the end‐users interact with the application? - **Secondary** nodes provide all the interfaces a **primary** node does - (notably a HTTP/HTTPS web application, and HTTP/HTTPS or SSH git repository + (notably a HTTP/HTTPS web application, and HTTP/HTTPS or SSH Git repository access), but is constrained to read-only activities. The principal use case is - envisioned to be cloning git repositories from the **secondary** node in favor of the + envisioned to be cloning Git repositories from the **secondary** node in favor of the **primary** node, but end-users may use the GitLab web interface to view projects, issues, merge requests, snippets, etc. @@ -229,7 +229,7 @@ questions from [owasp.org](https://www.owasp.org). - A static secret shared across all hosts in a GitLab deployment. - In transit, data should be encrypted, although the application does permit communication to proceed unencrypted. The two main transits are the **secondary** node’s - replication process for PostgreSQL, and for git repositories/files. Both should + replication process for PostgreSQL, and for Git repositories/files. Both should be protected using TLS, with the keys for that managed via Omnibus per existing configuration for end-user access to GitLab. |