일반적인 하드닝 가이드라인은 메인 하드닝 문서를 참고합니다.

GitLab 인스턴스에 대한 하드닝 권장 사항은 웹 인터페이스를 통해 제어합니다.

Prerequisites#

관리자 액세스 권한이 있어야 합니다.

System hooks#

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 System hooks를 선택합니다.

일반적인 하드닝 환경에서는 내부 정보가 시스템 외부로 전송되거나 저장되지 않습니다. 오프라인 환경 시스템의 경우 이는 당연한 전제입니다. 시스템 훅은 트리거를 기반으로 환경 내 로컬 이벤트 정보를 환경 외부로 전달하는 방법을 제공합니다.

이 기능의 사용 사례는 지원되며, 특히 원격 시스템을 통한 시스템 모니터링에 활용됩니다. 다만 시스템 훅을 배포할 때는 극도로 주의해야 합니다. 하드닝된 시스템이 오프라인 환경을 목표로 한다면, 서로 통신이 허용되는 신뢰할 수 있는 시스템의 경계를 강제해야 하며, 이에 따라 모든 훅(시스템, 웹, 파일)은 해당 신뢰할 수 있는 시스템하고만 통신해야 합니다. 시스템 훅을 통한 통신에는 TLS 사용을 강력히 권장합니다.

Push rules#

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Push rules를 선택합니다.

다음 항목이 선택되어 있는지 확인합니다.

• Reject unverified users
• Do not allow users to remove Git tags with git push
• Check whether the commit author is a GitLab user
• Prevent pushing secret files

이러한 설정을 조정하면 푸시를 기존에 등록된 승인된 사용자로 제한하는 데 도움이 됩니다.

Deploy keys#

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Access > Deploy keys를 선택합니다.

퍼블릭 배포 키는 인스턴스의 모든 프로젝트에 읽기 또는 읽기/쓰기 액세스 권한을 부여하는 데 사용되며, 원격 자동화가 프로젝트에 접근할 수 있도록 하기 위한 용도입니다. 하드닝 환경에서는 퍼블릭 배포 키를 사용하지 않아야 합니다. 배포 키를 반드시 사용해야 한다면 프로젝트 배포 키를 대신 사용합니다. 자세한 내용은 배포 키 및 프로젝트 배포 키 문서를 참고합니다.

General#

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.

하드닝 관련 설정은 4개 섹션에서 조정할 수 있습니다.

Visibility and access control#

다음 설정의 기본값은 Private 입니다.

• Default project visibility
• Default snippet visibility
• Default group visibility

프로젝트, 스니펫, 그룹에 대한 특정 액세스 권한을 부여받은 사용자만 해당 리소스에 접근할 수 있습니다. 이 설정은 생성 시점이나 이후 필요에 따라 조정할 수 있습니다. 이는 실수 또는 악의적인 정보 노출을 방지하는 데 도움이 됩니다.

보안 정책과 태세에 따라 Restricted visibility level을 Public으로 설정할 수 있습니다. 이렇게 하면 인증되지 않은 사용자가 사용자 프로필을 조회하지 못하도록 방지할 수 있습니다.

Import sources에서는 실제로 필요한 소스만 선택합니다.

일반적인 배포 환경에서는 Enabled Git access protocols가 **Both SSH and HTTP(S)**로 설정되어 있습니다. 다만 사용자가 두 Git 프로토콜 중 하나를 사용하지 않는다면 상황에 맞게 Only SSH 또는 **Only HTTP(S)**로 설정합니다. 이렇게 하면 공격 표면을 줄이는 데 도움이 됩니다.

SSH 키 유형은 ED25519(및 ED25519-SK), RSA, ECDSA(및 ECDSA-SK) 순으로 사용을 권장합니다. RSA를 2048비트 이상으로 설정하면 ED25519 는 RSA와 동등한 수준으로 안전한 것으로 간주됩니다. 다만 ED25519 키는 크기가 더 작고 알고리즘 속도도 훨씬 빠릅니다.

ED25519-SK와 ECDSA-SK는 모두 "Security Key"를 뜻하는 -SK로 끝납니다. -SK 유형은 FIDO/U2F 표준과 호환되며, YubiKey와 같은 하드웨어 토큰 사용과 관련이 있습니다.

DSA는 "Are forbidden" 으로 설정해야 합니다. DSA에는 알려진 결함이 있으며, 다수의 암호학자가 ECDSA 사용에 대해서도 의구심을 갖고 지지하지 않습니다.

GitLab 이 FIPS 모드인 경우 다음을 사용합니다.

• FIPS 모드로 실행 중인 경우:
  • RSA를 사용하며, Must be at least 2048 bits로 설정합니다.
  • ECDSA(및 ECDSA-SK)를 사용하며, Must be at least 256 bits로 설정합니다.
  • 그 외 모든 키 유형은 Are forbidden으로 설정합니다. RSA와 ECDSA는 모두 FIPS 사용이 승인되어 있습니다.
• FIPS 모드로 실행 중이 아닌 경우 ED25519를 사용해야 하며, RSA도 함께 사용할 수 있습니다.
  • ED25519(및 ED25519-SK)를 Must be at least 256 bits로 설정합니다.
  • RSA를 사용하는 경우 Must be at least 2048 bits로 설정합니다.
  • 그 외 모든 키 유형은 Are forbidden으로 설정합니다.
• 신규 사용자 그룹을 위한 인스턴스를 구성하는 경우, 보안을 강화하기 위해 최대 비트 설정으로 사용자 SSH 키 정책을 정의합니다.

하드닝 환경에서는 일반적으로 RSS 피드가 필요하지 않으므로, Feed token 에서 Disabled feed token 체크박스를 선택합니다.

모든 사용자가 특정 IP 주소에서 접속하는 경우, Global-allowed IP ranges 를 사용해 해당 주소만 명시적으로 허용합니다.

Visibility and access control에 대한 자세한 내용은 가시성 및 액세스 제어를 참고합니다. SSH 설정에 대한 정보는 SSH 키 제한 사항을 참고합니다.

Account and limit#

하드닝 목적상 Gravatar enabled 옆의 체크박스가 선택되어 있지 않은지 확인합니다. 불필요한 외부 통신은 모두 줄여야 하며, 일부 환경에서는 이를 제한해야 할 수도 있습니다. 계정 아바타는 사용자가 직접 업로드할 수 있습니다.

이 섹션의 설정은 사용자에게 자체적으로 정한 표준을 맞춤 적용하는 데 도움을 주기 위한 것입니다. 시나리오가 매우 다양하므로 계정 및 제한 설정 문서를 검토하고, 자체 정책을 적용하기 위한 변경 사항을 반영합니다.

New account restrictions#

Allow new user accounts 체크박스가 선택 해제되어 있는지 확인하여, 하드닝된 인스턴스에서 신규 사용자 계정이 생성되지 않도록 합니다.

Email confirmation settings에서 Hard가 선택되어 있는지 확인합니다. 이렇게 하면 액세스 권한이 부여되기 전에 사용자의 이메일 주소 인증이 강제됩니다.

**Minimum password length (number of characters)**의 기본값은 12이며, 추가 인증 기법을 함께 사용하는 한 이 값으로도 충분합니다. 비밀번호는 복잡해야 하므로 다음 4개 체크박스가 모두 선택되어 있는지 확인합니다.

• Require numbers
• Require uppercase letters
• Require lowercase letters
• Require symbols

모든 사용자가 특정 이메일 도메인을 사용하는 동일 조직에 속해 있다면, Domains allowed for new users에 해당 도메인을 등록합니다. 이렇게 하면 다른 도메인의 이메일 주소를 가진 사용자의 가입을 막을 수 있습니다.

자세한 내용은 신규 사용자 계정 제한 사항을 참고합니다.

Sign-in restrictions#

모든 사용자에 대해 2단계 인증(2FA)을 활성화해야 합니다. Two-factor authentication(2FA) 옆의 체크박스가 선택되어 있는지 확인합니다.

Two-factor grace period의 기본값은 48시간입니다. 이 값은 8시간과 같이 훨씬 낮은 값으로 조정해야 합니다.

Enable Admin Mode 옆의 체크박스가 선택되어 Admin Mode가 활성화되어 있는지 확인합니다. 이렇게 하면 Admin 액세스 권한을 가진 사용자가 관리 작업을 수행할 때 추가 인증을 거쳐야 하므로, 사용자에게 추가 2FA가 강제됩니다.

Email notification for unknown sign-ins에서 Enable email notification 이 선택되어 있는지 확인합니다. 이렇게 하면 인식되지 않은 위치에서 로그인이 발생할 때 사용자에게 이메일이 전송됩니다.

자세한 내용은 로그인 제한 사항을 참고합니다.

Integrations#

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Integrations을 선택합니다.

일반적으로 관리자가 사용 현황을 통제하고 모니터링하는 한, 하드닝 환경에서도 인테그레이션 사용에는 문제가 없습니다. 다만 로컬 프로세스나 인증된 사용자가 수행할 경우 제한하거나 감사할 만한 수준의 액세스 권한을 요구하는 작업·프로세스를, 외부 시스템에서 트리거할 수 있도록 허용하는 인테그레이션은 주의해야 합니다.

Metrics and profiling#

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Metrics and profiling을 선택합니다.

하드닝에서 중점적으로 다룰 부분은 Usage statistics 입니다.

• Enable version check 이 선택되어 있는지 확인해야 합니다. 이 기능은 현재 최신 버전의 GitLab을 사용 중인지 확인하며, 새로운 기능과 보안 패치가 포함된 새 버전이 자주 출시되므로 최신 상태를 유지하는 데 도움이 됩니다.

• 환경이 격리되어 있거나, 조직의 요구 사항상 소프트웨어 벤더로의 데이터 수집 및 통계 보고가 제한되는 경우에는 Enable service ping 기능을 꺼야 할 수 있습니다.

Network#

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Network을 선택합니다.

요청 속도 제한을 활성화하는 설정은 모두 선택되어 있는지 확인합니다. 기본값을 그대로 사용해도 무방합니다. 그 외에도 액세스를 허용하는 다양한 설정이 있으며, 이들은 모두 선택 해제해야 합니다.

이러한 설정을 조정한 뒤에는 성능과 사용자 요구 사항에 맞춰 시스템을 세부 조정할 수 있으며, 이 과정에서 속도 제한을 비활성화·조정하거나 액세스를 허용해야 할 수 있습니다. 다음 몇 가지 주의할 점을 염두에 둡니다.

• Outbound requests에서 제한된 수의 시스템에 대한 액세스를 열어야 하는 경우, IP 주소나 호스트명을 지정하여 해당 시스템으로만 액세스를 제한할 수 있습니다. 또한 이 섹션에서 조금이라도 액세스를 허용한다면 Enforce DNS rebinding attack protection 이 선택되어 있는지 확인합니다.

• Notes rate limit과 Users API rate limit에서는 필요한 경우 특정 사용자를 해당 제한에서 제외할 수 있습니다.