NGINX
Consul
환경 변수
Git 프로토콜
수신 이메일
Redis 복제 및 장애 조치
Sidekiq 설정
이메일의 S/MIME 서명
컨테이너 레지스트리

Hardening - 구성 권장 설정

일반 강화 가이드라인은 메인 강화 문서에 개요되어 있습니다.

GitLab 인스턴스에 대한 강화 권장 설정 중 일부는 추가 서비스나 설정 파일을 통한 제어가 관련됩니다. 설정 파일을 변경할 때는 편집하기 전에 백업 복사본을 만들어야 함을 상기하세요. 또한 많은 변경사항을 수행 중이라면 한꺼번에 모든 변경을 하지 말고 각 변경 후에 테스트하여 모든 것이 작동하는지 확인하는 것이 권장됩니다.

NGINX

NGINX은 GitLab 인스턴스 접근에 사용되는 웹 인터페이스를 제공하는 데 사용됩니다. NGINX는 GitLab에 제어 및 통합되므로 /etc/gitlab/gitlab.rb 파일을 수정하는 것으로 조정이 가능합니다. NGINX 자체의 보안을 향상시키기 위한 몇 가지 권장 사항은 다음과 같습니다:

디피-헬만 키 만들기:

sudo openssl dhparam -out /etc/gitlab/ssl/dhparam.pem 4096

/etc/gitlab/gitlab.rb 파일을 편집하여 다음을 추가합니다:

#
# 강력한 암호만 사용
#
nginx['ssl_ciphers'] = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256"
#
# 우선하는 암호 및 나열된 순서 따르기
#
nginx['ssl_prefer_server_ciphers'] = "on"
#
# TLSv1.2 및 TLSv1.3만 허용
#
nginx['ssl_protocols'] = "TLSv1.2 TLSv1.3"
   
##! **https://nginx.org/en/docs/http/ngx_http_ssl_module.html**에서 권장됨
nginx['ssl_session_cache'] = "builtin:1000  shared:SSL:10m"
   
##! **https://nginx.org/en/docs/http/ngx_http_ssl_module.html**에 따른 기본 설정
nginx['ssl_session_timeout'] = "5m"
   
# 로그잼 공격 방지
nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparams.pem" # nil에서 변경함
   
# 세션 티켓 재사용 비활성화
nginx['ssl_session_tickets'] = "off"
# openssl의 전답과 상관없이 직접 곡선 선택
nginx['ssl_ecdh_curve'] = "secp384r1"

GitLab 재구성:
```
sudo gitlab-ctl reconfigure
```

Consul

Consul은 GitLab 환경에 통합될 수 있으며, 대규모 배포를 위한 것입니다. 일반적으로 Self-Managed형 및 독립형 배포에서는 1000명 미만의 사용자인 경우 Consul이 필요하지 않을 수 있습니다. 필요할 경우 먼저 통신 중에 암호화가 사용되었는지 확인하고 Consul 문서를 먼저 검토하세요. 더 중요한 것은 해시코프 웹사이트에서 작동 방식을 이해하고 암호화 보안 정보를 검토하는 것입니다.

환경 변수

Self-Managed형 시스템에서는 다양한 환경 변수를 사용자 정의할 수 있습니다. 보안 관점에서 주요 환경 변수는 설치 과정 중 GITLAB_ROOT_PASSWORD를 활용하는 것입니다. 인터넷에 노출된 공용 IP 주소로 Self-Managed형 시스템을 설치하는 경우 비밀번호를 강력하게 설정해야 합니다. 역사적으로 GitLab 또는 다른 응용 프로그램을 포함한 공개 서비스를 설정하는 경우, 해당 시스템이 발견되는 즉시 기회주의적 공격이 발생함을 보여주었기 때문에 강화 과정은 설치 과정 중에 시작해야 합니다.

운영 체제 권장 사항에서 언급된 대로 이상적으로는 GitLab 설치 시작 전에 방화벽 규칙이 이미 설정되어 있어야 하지만, 설치 전에 여전히 안전한 비밀번호를 설정해야 합니다.

Git 프로토콜

SSH를 통한 Git 액세스를 권한이 있는 사용자만 사용하도록 하려면 다음을 /etc/ssh/sshd_config 파일에 추가하세요:

# 권한이 있는 사용자만 Git 사용하도록 함
AcceptEnv GIT_PROTOCOL

이를 통해 사용자가 유효한 GitLab 계정을 가지고 있지 않다면 SSH를 통해 프로젝트를 다운로드할 수 없도록 보장할 수 있습니다. 더 자세한 정보는 Git 프로토콜 구성에서 확인할 수 있습니다.

수신 이메일

GitLab Self-Managed형 인스턴스에서는 등록된 사용자가 수신 이메일을 사용하여 코멘트를 작성하거나 이슈 및 Merge Request을 생성할 수 있도록 구성할 수 있습니다. 강화된 환경에서는 외부 통신을 통해 정보를 보내는 기능을 구성해서는 안됩니다.

이 기능이 필요한 경우 수신 이메일 문서의 지침을 따르고 다음과 같은 권장 사항을 준수하여 최대 보안을 보장하세요:

인스턴스로의 수신 이메일을 위해 특정 이메일 주소를 할당하세요.
이메일 서브-주소를 사용하세요.
이메일 계정 사용자는 해당 계정에 MFA(Multi-Factor Authentication)가 필요하며 활성화되어야 합니다.
Postfix의 경우 수신 이메일용 Postfix 설정을 따르세요.

Redis 복제 및 장애 조치

Redis는 복제 및 장애 조치를 위해 Linux 패키지 설치에 사용되며, 스케일링이 필요한 경우 설정할 수 있습니다. 모든 노드의 IP 주소를 확인하고 해당하는 포트에 대해 다른 노드만 접근할 수 있도록 방화벽 규칙을 설정하세요. 복제 및 장애 조치 문서를 따르되 모든 노드의 IP 주소를 확인하고 해당하는 포트에 대해 다른 노드만 접근할 수 있도록 방화벽 규칙을 설정하세요.

Sidekiq 설정

외부 Sidekiq 구성 안내에는 여러 IP 주소 범위를 구성하는 방법에 대한 많은 참조가 있습니다. 또한 HTTPS 활성화를 구성해야 하며 이것을 위해 Sidekiq가 통신하는 특정 시스템의 IP 주소를 제한해야 합니다. 또한 운영 체제 수준에서 방화벽 규칙을 조정해야 할 수도 있습니다.

이메일의 S/MIME 서명

GitLab 인스턴스가 사용자에게 이메일 통지를 보낼 수 있도록 구성된 경우, 수신자가 해당 이메일이 정품임을 확인할 수 있도록 S/MIME 서명을 구성하세요. 이메일 서명 구성 지침을 따르세요.

컨테이너 레지스트리

Lets Encrypt가 구성되어 있는 경우, 컨테이너 레지스트리가 기본적으로 활성화됩니다. 이를 통해 프로젝트가 자체 Docker 이미지를 저장할 수 있습니다. 컨테이너 레지스트리를 구성하는 방법을 따라 새 프로젝트에서 자동 활성화를 제한하고 컨테이너 레지스트리를 완전히 비활성화하는 것과 같은 작업을 수행할 수 있습니다. 완전히 독립된 시스템인 경우에는 컨테이너 레지스트리의 액세스를 로컬호스트에만 제한해야 할 수도 있습니다. 사용되는 포트 및 해당 구성에 대한 구체적인 예제는 문서에 포함되어 있습니다.