Hardening - 구성 권장 내용

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

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/dhparams.pem" # nil에서 변경함

# 세션 티켓 재사용 비활성화
nginx['ssl_session_tickets'] = "off"
# OpenSSL이 제공하는 대신 고유한 곡선 선택
nginx['ssl_ecdh_curve'] = "secp384r1"

  3. GitLab 재구성: 

    sudo gitlab-ctl reconfigure

Consul

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

환경 변수

자체 관리 시스템에서는 여러 환경 변수를 사용자 정의할 수 있습니다. 보안 측면에서 설치 프로세스 중에 GITLAB_ROOT_PASSWORD 환경 변수를 활용하는 것이 주요합니다. 인터넷에 노출된 공개 IP 주소로 자체 관리 시스템을 설치하는 경우, 비밀번호를 강력하게 설정해야 합니다. 역사적으로, GitLab 또는 기타 애플리케이션을 포함한 공개 서비스를 설정하는 것은 발견되는 즉시 기회주의적 공격이 발생하므로 강화 프로세스는 설치 프로세스 중에 시작되어야 합니다.

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

Git 프로토콜

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

# 인증된 사용자만 Git 사용
AcceptEnv GIT_PROTOCOL

이렇게 함으로써 사용자가 유효한 GitLab 계정을 갖고 있지 않은 경우 SSH를 통해 프로젝트를 내려받을 수 없도록 보장합니다. 자세한 내용은 Git 프로토콜 구성에서 확인할 수 있습니다.

수신 이메일

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

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

  • 인스턴스로 들어오는 이메일을 위해 특정 이메일 주소를 할당합니다.
  • 이메일 서브 주소 지정 사용.
  • 사용자가 전자 메일을 보내기 위해 사용하는 이메일 계정은 해당 계정에 다중 인증(2단계 인증)이 필요하도록 설정되어 있어야 합니다.
  • 특히 Postfix의 경우, 수신 이메일 설정을 위한 Postfix 설정을 따르세요.

Redis Replication and Failover

Redis는 복제 및 장애 조치를 위해 리눅스 패키지 설치에서 사용되며, 확장이 해당 기능을 요구할 때 설정할 수 있습니다. 노드의 모든 IP 주소를 주의하며, 노드 간에는 해당 포트에 액세스할 수 있도록 허용하는 방화벽 규칙을 설정해야 합니다. 복제 및 장애 조치 설명서를 따르세요.

Sidekiq 구성

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

이메일의 S/MIME 서명

GitLab 인스턴스가 사용자에게 이메일 알림을 보내도록 구성된 경우, 수신자가 해당 이메일이 정허하다는 것을 보장하기 위해 S/MIME 서명을 구성하세요. 이메일 발신 서명 지침을 따르세요.

컨테이너 레지스트리

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