This is a Controlled Document
Inline with GitLab's regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.
These specific requirements are related to the protection of GitLab information systems and other resources from unauthorized use. Our intention in publishing this procedure is to outline information security guidelines intended to protect GitLab assets, not to impose restrictions.
Constructing secure passwords and ensuring proper password management is essential. GitLab's password guidelines are based, in part, on the recommendations by NIST 800-63B. To learn what makes a password truly secure, read this article or watch this conference presentation on password strength.
Applies to all GitLab team-members, contractors, advisors, and contracted parties interacting with GitLab computing resources and accessing company or customer data.
Role | Responsibility |
---|---|
GitLab Team Members | Responsible for following the requirements in this procedure |
Security | Responsible for implementing and executing this procedure |
Security Management (Code Owners) | Responsible for approving significant changes and exceptions to this procedure |
All GitLab team members should use Two Factor Authentication (2FA) whenever possible. Usage of 2FA by GitLab team members is required for access to the production environment. It should be noted that references to MFA (Multi-Factor Authentication) are often included in language associated with third party products and certain Compliance references, but the general concept is still covered by the term "2FA". There are different 2FA methods that can be used by GitLab team members. These are ranked by security strength:
There is a reason that multiple 2FA methods are supported (e.g. Okta supports U2F, Push, and TOTP). Situations are different for different team members. For team members that travel a lot, they might feel more comfortable using Push instead of U2F if they are concerned about losing the hardware token during their travels. Many team members use 1Password and TOTP for the convenience. Many services support configuring multiple methods, which can be used for different situations or as a backup if a factor is lost. The idea is that we give team members a choice so that they can adapt a 2FA solution that best suits their needs. Again, contact the Security Department if you have questions.
For a better understanding of how 2FA fits into GitLab, refer to the Accounts and Passwords section, which includes pointers to setting up passwords, acquiring U2F tokens, and links to further resources. Refer to the Tools and Tips page for more detailed information regarding U2F and other 2FA methods.
Any application that can not meet MFA and or Password requirements needs to submit an exception for the Compliance team to review. A duration of an exception is valid for 90 days followed by a proper remediation plan. After 90 days the exception will be reevaluated.
Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.