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

Hardening - 구성 권고 사항

일반적인 강화 지침은 주요 강화 문서에 개요되어 있습니다.

GitLab 인스턴스의 몇 가지 강화 권고에는 추가 서비스나 구성 파일을 통한 제어가 포함됩니다. 구성 파일을 수정할 때는 편집 전에 백업 복사본을 만들어야 함을 상기하십시오. 또한 많은 변경 사항을 수행하는 경우 한꺼번에 모든 변경 사항을 수행하지 않도록 권장하며, 각 변경 사항 이후에 테스트하여 모든 것이 작동하는지 확인해야 합니다.

NGINX

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

Diffie-Hellman 키 생성:

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/dhparam.pem" # 이전값에서 변경

# 세션 티켓 재사용 해제
nginx['ssl_session_tickets'] = "off"
# OpenSSL이 제공하는 대신 곡선 선택
nginx['ssl_ecdh_curve'] = "secp384r1"

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

Consul

Consul은 GitLab 환경에 통합될 수 있으며, 일반적으로 1000명 미만의 사용자를 보유한 자체 관리 및 독립형 배포에는 Consul이 필요하지 않을 수 있습니다. 필요한 경우, 먼저 통신 중에 암호화가 사용되도록 합니다. Consul에 대한 자세한 정보는 HashiCorp 웹사이트에서 작동 방식을 이해하고 암호화 보안 정보를 검토하십시오.

환경 변수

자체 관리 시스템에서 여러 환경 변수를 사용자 정의할 수 있습니다. 보안 관점에서 주요 환경 변수는 설치 프로세스 중 GITLAB_ROOT_PASSWORD입니다. 자체 관리 시스템을 인터넷에 노출된 공용 IP 주소로 설치하는 경우, 비밀번호를 강력한 것으로 설정하십시오. 과거에 GitLab이나 기타 어플리케이션과 같은 공용 서비스를 설치하는 것은 발견되자마자 기회주의적 공격이 발생하는 것으로 밝혀졌으므로 강화 과정은 설치 프로세스 중에 시작해야 합니다.

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

Git 프로토콜

SSH를 통한 Git 액세스에는 인가된 사용자만 사용하는 것을 보장하기 위해 다음을 /etc/ssh/sshd_config 파일에 추가하십시오:

# 인가된 사용자만 Git을 사용
AcceptEnv GIT_PROTOCOL

이로써 사용자가 유효한 GitLab 계정을 보유한 경우에만 SSH를 통해 프로젝트를 다운로드할 수 없게 됩니다. 자세한 정보는 Git 프로토콜 구성에서 찾을 수 있습니다.

수신 이메일

GitLab 자체 관리 인스턴스를 구성하여 외부의 통신을 통해 등록된 사용자가 주석 또는 이슈 및 병합 요청을 만드는 데에 사용할 수 있는 수신 이메일을 허용하도록 구성할 수 있습니다. 강화된 환경에서는 외부 통신으로 정보를 보내는 것을 구성하지 말아야 합니다.

필요한 기능이 있는 경우, 수신 이메일 문서의 지침을 따르되 다음의 권장 사항을 준수하여 최대 보안을 보장하십시오:

인스턴스로의 수신 이메일을 위해 전용 이메일 주소를 할당하십시오.
이메일 하위 주소를 사용하세요.
사용자에 의해 사용되는 이메일 계정은 해당 계정에서 다중 인증을 필요로 하고 활성화되어야 합니다.
특히 Postfix의 경우, 수신 이메일을 위한 Postfix 설정을 따르세요.

Redis 복제 및 장애 조치

Redis는 복제 및 장애 조치를 위해 Linux 패키지 설치에서 사용되며, 확장이 필요할 때 설정할 수 있습니다. 모든 노드의 IP 주소를 주의하고 해당 포트에 대해 다른 노드만 액세스할 수 있도록 방화벽 규칙을 설정하세요. 자세한 정보는 복제 및 장애 조치 문서를 참고하되 모든 노드에서의 IP 주소를 참고하고 해당 포트에 대한 다른 노드의 액세스만 허용하는 방화벽 규칙을 설정해야 합니다.

Sidekiq 구성

외부 Sidekiq의 구성 방법에는 여러 개의 IP 범위 구성에 대한 많은 참조가 있습니다. 반드시 HTTPS를 구성하고 해당 IP 주소를 Sidekiq가 통신하는 특정 시스템의 것으로 제한하는 것을 고려해야 할 것입니다. 또한 운영 체제 수준에서 방화벽 규칙을 조정해야 할 수 있습니다.

이메일의 S/MIME 서명

만약 GitLab 인스턴스가 사용자에게 이메일 알림을 보내도록 구성되어 있다면, 수신자가 해당 이메일이 정허하다는 것을 확인할 수 있도록 S/MIME 서명을 구성하세요. 이메일 서명하기의 지침을 따르세요.

컨테이너 레지스트리

Let’s Encrypt가 구성되어 있다면 컨테이너 레지스트리는 기본적으로 활성화됩니다. 이를 통해 프로젝트는 자체 Docker 이미지를 저장할 수 있습니다. 컨테이너 레지스트리 구성 지침을 따르세요. 이를 통해 새 프로젝트에서의 자동 활성화 제한 및 컨테이너 레지스트리 전체 비활성화와 같은 작업을 수행할 수 있습니다. 완전 독립형 시스템인 경우 방화벽 규칙을 조정하여 컨테이너 레지스트리 액세스를 로컬호스트로만 허용해야 할 수도 있습니다. 사용되는 포트와 그 구성에 대한 구체적인 예제 똭 서두멘테이션에 포함되어 있습니다.