InfoGrab Docs

강화 - 구성 권장 사항

요약

일반적인 강화 지침은 메인 강화 문서에 설명되어 있습니다. GitLab 인스턴스에 대한 일부 강화 권장 사항은 추가 서비스 또는 구성 파일을 통한 제어가 필요합니다. NGINX는 GitLab 인스턴스에 액세스하는 데 사용되는 웹 인터페이스를 제공하는 데 사용됩니다.

일반적인 강화 지침은 메인 강화 문서에 설명되어 있습니다.

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를 편집하고 다음을 추가합니다:

    #
# Only strong ciphers are used
#
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"
#
# Follow preferred ciphers and the order listed as preference
#
nginx['ssl_prefer_server_ciphers'] = "on"
#
# Only allow TLSv1.2 and TLSv1.3
#
nginx['ssl_protocols'] = "TLSv1.2 TLSv1.3"

##! **Recommended in: https://nginx.org/en/docs/http/ngx_http_ssl_module.html**
nginx['ssl_session_cache'] = "builtin:1000 shared:SSL:10m"

##! **Default according to https://nginx.org/en/docs/http/ngx_http_ssl_module.html**
nginx['ssl_session_timeout'] = "5m"

# Should prevent logjam attack etc
nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparam.pem" # changed from nil

# Turn off session ticket reuse
nginx['ssl_session_tickets'] = "off"
# Pick our own curve instead of what openssl hands us
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 파일에 다음을 추가합니다:

# Ensure only authorized users are using Git
AcceptEnv GIT_PROTOCOL

이렇게 하면 SSH를 통해 git 작업을 수행할 수 있는 유효한 GitLab 계정이 없는 한 사용자가 SSH를 사용하여 프로젝트를 가져올 수 없습니다. 자세한 내용은 Git 프로토콜 구성을 참조하세요.

수신 이메일#

GitLab Self-Managed를 구성하여 GitLab 인스턴스의 등록된 사용자가 댓글 작성이나 이슈 및 머지 리퀘스트 생성을 위해 수신 이메일을 사용할 수 있도록 할 수 있습니다. 강화된 환경에서는 외부 통신이 정보를 보내는 것을 포함하므로 이 기능을 구성하지 않아야 합니다.

기능이 필요한 경우 다음 권장 사항과 함께 수신 이메일 문서의 지침을 따라 최대 보안을 확보하세요:

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

Redis 복제 및 장애 조치#

Redis는 Linux 패키지 설치에서 복제 및 장애 조치에 사용되며 확장에 이 기능이 필요할 때 설정할 수 있습니다. 이렇게 하면 Redis의 TCP 포트 6379와 Sentinel의 26379가 열립니다. 복제 및 장애 조치 문서를 따르되 모든 노드의 IP 주소를 기록하고 다른 노드만 해당 특정 포트에 액세스할 수 있도록 노드 간 방화벽 규칙을 설정합니다.

Sidekiq 구성#

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

이메일 S/MIME 서명#

GitLab 인스턴스가 사용자에게 이메일 알림을 보내도록 구성된 경우 수신자가 이메일이 합법적인지 확인하는 데 도움이 되도록 S/MIME 서명을 구성합니다. 발신 이메일 서명에 대한 지침을 따르세요.

컨테이너 레지스트리#

Let's Encrypt가 구성된 경우 컨테이너 레지스트리가 기본적으로 활성화됩니다. 이를 통해 프로젝트가 자체 Docker 이미지를 저장할 수 있습니다. 컨테이너 레지스트리 구성 지침을 따라 새 프로젝트에서 자동 활성화를 제한하고 컨테이너 레지스트리를 완전히 비활성화하는 것과 같은 작업을 수행할 수 있습니다. 액세스를 허용하기 위해 방화벽 규칙을 조정해야 할 수 있습니다. 완전히 독립형 시스템이라면 컨테이너 레지스트리에 대한 액세스를 localhost만으로 제한해야 합니다. 사용된 포트 및 해당 구성의 특정 예시도 문서에 포함되어 있습니다.

강화 - 구성 권장 사항

원문 보기
요약

일반적인 강화 지침은 메인 강화 문서에 설명되어 있습니다. GitLab 인스턴스에 대한 일부 강화 권장 사항은 추가 서비스 또는 구성 파일을 통한 제어가 필요합니다. NGINX는 GitLab 인스턴스에 액세스하는 데 사용되는 웹 인터페이스를 제공하는 데 사용됩니다.

일반적인 강화 지침은 메인 강화 문서에 설명되어 있습니다.

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를 편집하고 다음을 추가합니다:

    #
# Only strong ciphers are used
#
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"
#
# Follow preferred ciphers and the order listed as preference
#
nginx['ssl_prefer_server_ciphers'] = "on"
#
# Only allow TLSv1.2 and TLSv1.3
#
nginx['ssl_protocols'] = "TLSv1.2 TLSv1.3"

##! **Recommended in: https://nginx.org/en/docs/http/ngx_http_ssl_module.html**
nginx['ssl_session_cache'] = "builtin:1000 shared:SSL:10m"

##! **Default according to https://nginx.org/en/docs/http/ngx_http_ssl_module.html**
nginx['ssl_session_timeout'] = "5m"

# Should prevent logjam attack etc
nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparam.pem" # changed from nil

# Turn off session ticket reuse
nginx['ssl_session_tickets'] = "off"
# Pick our own curve instead of what openssl hands us
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 파일에 다음을 추가합니다:

# Ensure only authorized users are using Git
AcceptEnv GIT_PROTOCOL

이렇게 하면 SSH를 통해 git 작업을 수행할 수 있는 유효한 GitLab 계정이 없는 한 사용자가 SSH를 사용하여 프로젝트를 가져올 수 없습니다. 자세한 내용은 Git 프로토콜 구성을 참조하세요.

수신 이메일#

GitLab Self-Managed를 구성하여 GitLab 인스턴스의 등록된 사용자가 댓글 작성이나 이슈 및 머지 리퀘스트 생성을 위해 수신 이메일을 사용할 수 있도록 할 수 있습니다. 강화된 환경에서는 외부 통신이 정보를 보내는 것을 포함하므로 이 기능을 구성하지 않아야 합니다.

기능이 필요한 경우 다음 권장 사항과 함께 수신 이메일 문서의 지침을 따라 최대 보안을 확보하세요:

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

Redis 복제 및 장애 조치#

Redis는 Linux 패키지 설치에서 복제 및 장애 조치에 사용되며 확장에 이 기능이 필요할 때 설정할 수 있습니다. 이렇게 하면 Redis의 TCP 포트 6379와 Sentinel의 26379가 열립니다. 복제 및 장애 조치 문서를 따르되 모든 노드의 IP 주소를 기록하고 다른 노드만 해당 특정 포트에 액세스할 수 있도록 노드 간 방화벽 규칙을 설정합니다.

Sidekiq 구성#

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

이메일 S/MIME 서명#

GitLab 인스턴스가 사용자에게 이메일 알림을 보내도록 구성된 경우 수신자가 이메일이 합법적인지 확인하는 데 도움이 되도록 S/MIME 서명을 구성합니다. 발신 이메일 서명에 대한 지침을 따르세요.

컨테이너 레지스트리#

Let's Encrypt가 구성된 경우 컨테이너 레지스트리가 기본적으로 활성화됩니다. 이를 통해 프로젝트가 자체 Docker 이미지를 저장할 수 있습니다. 컨테이너 레지스트리 구성 지침을 따라 새 프로젝트에서 자동 활성화를 제한하고 컨테이너 레지스트리를 완전히 비활성화하는 것과 같은 작업을 수행할 수 있습니다. 액세스를 허용하기 위해 방화벽 규칙을 조정해야 할 수 있습니다. 완전히 독립형 시스템이라면 컨테이너 레지스트리에 대한 액세스를 localhost만으로 제한해야 합니다. 사용된 포트 및 해당 구성의 특정 예시도 문서에 포함되어 있습니다.