강화 - 구성 권장 사항

일반적인 강화 지침은 주요 강화 문서에서 설명됩니다.

GitLab 인스턴스에 대한 몇 가지 강화 권장 사항은 추가 서비스 또는 구성 파일을 통한 제어가 포함됩니다. 구성 파일을 변경할 때는 항상 백업 복사본을 만들어 두시기 바랍니다. 또한, 많은 변경을 하는 경우 모든 변경을 한꺼번에 진행하지 말고, 각 변경 후에 모든 것이 제대로 작동하는지 테스트하는 것이 좋습니다.

NGINX

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

  1. Diffie-Hellman 키를 생성합니다:

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

  2. /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"

# logjam 공격 등을 방지해야 함
nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparam.pem" # nil에서 변경됨

# 세션 티켓 재사용 꺼짐
nginx['ssl_session_tickets'] = "off"
# openssl이 제공하는 대신 우리의 곡선을 선택합니다
nginx['ssl_ecdh_curve'] = "secp384r1"

  3. GitLab을 다시 구성합니다:

    sudo gitlab-ctl reconfigure

Consul

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

환경 변수

다중 환경 변수를 사용자 관리 시스템에서 설정할 수 있습니다. 보안 관점에서 유용하게 사용할 수 있는 주요 환경 변수는 설치 과정 중 GITLAB_ROOT_PASSWORD입니다. 공용 IP 주소가 인터넷에 노출된 상태에서 사용자 관리 시스템을 설치하는 경우, 강력한 비밀번호로 설정해야 합니다. 역사적으로, GitLab 또는 다른 애플리케이션 등 공용 서비스 유형을 설정하는 즉시 이러한 시스템이 발견되면 기회를 노린 공격이 발생하는 것으로 나타났으므로, 하드닝 과정은 설치 과정 중에 시작되어야 합니다.

운영 체제 권장 사항에서 언급했듯이, GitLab 설치가 시작되기 전에 방화벽 규칙이 이미 설정되어 있어야 하지만, 설치 전에 GITLAB_ROOT_PASSWORD를 통해 보안 비밀번호를 설정해야 합니다.

Git 프로토콜

SSH를 통해 Git에 접근할 수 있는 사용자만을 허용하기 위해 /etc/ssh/sshd_config 파일에 다음을 추가하십시오:

# Git을 사용하는 인증된 사용자만 허용
AcceptEnv GIT_PROTOCOL

이 설정은 사용자가 유효한 GitLab 계정이 없이는 SSH를 통해 프로젝트를 가져올 수 없도록 합니다. SSH를 통한 git 작업을 수행할 수 있는 계정이 있어야 합니다. 더 자세한 내용은 Git 프로토콜 구성에서 확인할 수 있습니다.

수신 이메일

GitLab 사용자 관리 인스턴스를 구성하여 등록된 사용자가 GitLab 인스턴스에서 주석을 달거나 문제 및 병합 요청을 생성하는 데 사용할 수 있는 수신 이메일을 설정할 수 있습니다. 하드닝된 환경에서는 이 기능을 설정하지 않아야 하며, 이는 외부 통신이 정보를 보내는 것을 포함합니다.

기능이 필요하다면, 최대 보안을 보장하기 위한 다음 권장 사항과 함께 수신 이메일 문서의 지침을 따르십시오:

  • 인스턴스에 대한 수신 이메일 전용 이메일 주소를 지정하십시오.
  • 이메일 하위 주소를 사용하십시오.
  • 이메일을 보내는 사용자가 사용하는 이메일 계정은 이 계정에서 다중 인증(MFA)을 요구하고 활성화해야 합니다.
  • 특히 Postfix의 경우, 수신 이메일을 위한 Postfix 설정 문서를 따르십시오.

Redis 복제 및 장애 조치

Redis는 복제 및 장애 조치를 위해 Linux 패키지 설치에서 사용되며, 확장에서 이 기능이 필요할 경우 설정할 수 있습니다. 이는 Redis에 대해 TCP 포트 6379와 Sentinel에 대해 26379를 엽니다. 복제 및 장애 조치 문서를 따르되, 모든 노드의 IP 주소를 주의 깊게 기록하고, 특정 포트에 대한 접근을 허용하는 노드 간 방화벽 규칙을 설정하십시오.

Sidekiq 구성

외부 Sidekiq 구성 지침에서는 IP 범위를 구성하는 여러 참조가 있습니다. HTTPS 구성을 구성해야 하며, Sidekiq가 통신하는 특정 시스템에 IP 주소를 제한하는 것을 고려해야 합니다. 운영 체제 수준에서 방화벽 규칙을 조정해야 할 수도 있습니다.

S/MIME 이메일 서명

GitLab 인스턴스가 사용자에게 이메일 알림을 발송하도록 구성된 경우, 수신자가 이메일이 정당한지 확인할 수 있도록 S/MIME 서명을 구성하십시오. 발신 이메일 서명에 대한 지침을 따르십시오.

컨테이너 레지스트리

Lets Encrypt가 구성된 경우, 컨테이너 레지스트리는 기본적으로 활성화됩니다.

이것은 프로젝트가 자신의 Docker 이미지를 저장할 수 있게 해줍니다.

컨테이너 레지스트리 구성에 대한 지침을 따라, 새로운 프로젝트에서 자동 활성화를 제한하거나 컨테이너 레지스트리를 완전히 비활성화하는 것과 같은 작업을 수행할 수 있습니다.

액세스를 허용하기 위해 방화벽 규칙을 조정해야 할 수도 있습니다 - 완전히 독립적인 시스템인 경우, 컨테이너 레지스트리에 대한 액세스를 localhost로만 제한해야 합니다.

사용되는 포트와 해당 구성의 구체적인 예도 문서에 포함되어 있습니다.