FIPS 규정 준수

FIPS는 “연방 정보 처리 표준”의 약자로, “암호화 모듈” (CM)을 위한 특정 보안 규정을 정의하는 문서입니다. 미국 연방 기관에 제품을 판매하는 공급업체가 일정한 보안 기준을 준수하도록 하는 것을 목표로 합니다.

caution
GitLab 내에서 FIPS 규정 준수 인스턴스를 구축할 수 있지만, FIPS 모드에서 지원되지 않는 기능이 있습니다. FIPS 규정 준수 인스턴스는 FIPS 설치 지침을 정확히 따라 구성해야 합니다.

현재 두 가지 FIPS 표준이 있습니다: 140-2140-3. GitLab에서는 일반적으로 FIPS 140-2를 의미합니다.

현재 상태

GitLab은 이 문서에서 지정한 빌드에 대해 FIPS 140-2 규정 준수를 완료했습니다. FIPS 140-2 인증서는 고객 보증 패키지에서 찾을 수 있습니다.

GitLab의 FIPS 규정 준수

준수해야 할 모든 컴포넌트(GitLab 그 자체, Gitaly 등)뿐만 아니라, 이러한 컴포넌트 간의 통신 및 해당 컴포넌트가 사용하는 모든 리포지터리도 준수해야 합니다. 준수할 수 없는 기능이 있는 경우 FIPS 모드가 활성화되면 해당 기능을 비활성화해야 합니다. FIPS 규정 준수 암호화는 FIPS-인증된 모듈을 활용하는 암호화 작업을 의미합니다.

활용된 암호 모듈

다음 디렉터리은 참고용으로 제공되며 동적으로 업데이트되는 것이 아닙니다. 아래 모듈에 대한 최신 CMVP 인증서가 적용됩니다.

암호화 모듈 이름 CMVP 번호 인스턴스 유형 사용된 소프트웨어 컴포넌트
Ubuntu 20.04 AWS 커널 암호화 API 암호 모듈 4366 EC2 (Omnibus) Linux 커널
Ubuntu 20.04 OpenSSL 암호 모듈 4292 EC2 (Omnibus) Gitaly, Rails (Puma/Sidekiq)
Ubuntu 20.04 Libgcrypt 암호 모듈 3902 EC2 (Omnibus) gpg, sshd
Amazon Linux 2 커널 암호화 API 암호 모듈 4593 EKS 노드 Linux 커널
Amazon Linux 2 OpenSSL 암호 모듈 4548 EKS 노드 EKS
Red Hat Enterprise Linux 8 OpenSSL 암호 모듈 4642 GitLab 헬름 차트 UBI 컨테이너: Workhorse, Pages, 컨테이너 레지스트리, Rails (Puma/Sidekiq), 보안 분석기, gitlab-sshd
Red Hat Enterprise Linux 8 Libgcrypt 암호 모듈 4438 GitLab 헬름 차트 UBI 컨테이너: GitLab Shell, gpg

지원되는 운영 체제

지원되는 하이브리드 플랫폼은 다음과 같습니다.

  • Omnibus GitLab: Ubuntu 20.04 LTS
  • 클라우드 네이티브 GitLab: Amazon Linux 2 (EKS)

FIPS 모드에서 지원되지 않는 기능

FIPS 모드에서 일부 GitLab 기능이 작동하지 않을 수 있습니다. 다음 기능들이 FIPS 모드에서 작동하지 않는 것으로 알려져 있습니다. 그러나 여기에 나열되지 않은 추가 기능이 또한 FIPS 모드에서 올바르게 작동하지 않을 수 있습니다.

또한, 다음과 같은 패키지 리포지터리는 FIPS 모드에서 비활성화됩니다.

GitLab의 FIPS 규정 준수 vs FIPS 검증

GitLab은 FIPS-규정 준수 소프트웨어 릴리스에서 암호화된 바이너리(예: OpenSSL)를 포크하거나 수정하지 않고 기존의 FIPS-검증된 암호화 소프트웨어(모듈)를 사용합니다. 따라서 GitLab은 소프트웨어를 NIST Cryptographic Module Validation Program (CMVP) 의 독립적인 실험실 테스트를 거쳐 제출할 필요가 없습니다. 대신, GitLab은 FIPS-검증된 소프트웨어(암호 모듈 검증 프로그램에 나열됨)를 사용하고 모든 암호화 작업에 활성화되어 있는지 확인해야 합니다.

FIPS-규정 준수 암호화는 암호 작업이 FIPS-검증된 모듈을 활용하는 것을 의미합니다. 모든 통신 세션의 한쪽 또는 양쪽에서 FIPS 모드를 활성화해야 합니다(즉, 클라이언트, 서버 또는 양쪽). 클라이언트에서 FIPS 모드를 활성화하면, 클라이언트가 암호화, 해싱 및 서명을 위해 FIPS 140-3/FIPS 140-2와 호환되는 강력한 암호화 알고리즘을 사용합니다. 클라이언트에서 FIPS 모드가 비활성화된 경우, 서버 측이나 응용 프로그램 로드 밸런서 또는 프록시 서버에서 FIPS-규정 준수 연결을 가능하게 하기 위해 서버 측에 구현해야 합니다.

FIPS 규정 준수로 GitLab 설치

이 가이드는 FIPS 준수 프로덕션 인스턴스를 실행해야 하는 일반 사용자 또는 GitLab 팀 구성원을 위한 것입니다. 이 가이드는 Omnibus 및 클라우드 네이티브 GitLab 설치 요소를 모두 사용하는 하이브리드 배포에 대해 개요를 제공합니다.

사전 요구 사항

  • Amazon Web Services 계정. 처음으로 대상 환경이 AWS에서 실행되고 다른 FIPS 준수 AWS 리소스를 사용합니다. 많은 AWS 리소스에 대해 FIPS 특정 엔드포인트를 사용해야 합니다.
  • GitLab을 위해 Ubuntu 20.04 머신을 실행할 수 있는 능력. 첫 번째 대상 환경에서는 하이브리드 아키텍처를 사용합니다.
  • 고급 검색: GitLab은 패키지화된 Elastic 또는 OpenSearch 배포를 제공하지 않습니다. FIPS-규정 준수 서비스를 사용하거나 고급 검색을 비활성화해야 합니다.

FIPS 활성화된 클러스터 설정

FIPS 활성화 클러스터를 구축하기 위해 GitLab 환경 도구킷을 사용할 수 있습니다. 사전 요구 사항에서 언급한 대로 이 지침은 처음 대상 환경이 아마존 웹 서비스(AWS)인 경우 사용합니다.

환경 설정하기

시작하려면 AWS 계정이 AWS Marketplace 콘솔에서 FIPS를 지원하는 Amazon Machine Image (AMI)를 구독해야 합니다.

이 예에서는 Canonical Group Limited가 제공하는 Ubuntu Pro 20.04 FIPS LTS AMI가 계정에 추가되었다고 가정합니다. 이 운영 체제는 Amazon EC2에서 실행되는 가상 머신에 사용됩니다.

Omnibus

FIPS를 지원하는 GitLab 클러스터를 얻는 가장 간단한 방법은 Omnibus 참조 아키텍처를 사용하는 것입니다. 자세한 내용은 GET 퀵 스타트 가이드를 참조하십시오. 다음 지침은 퀵 스타트를 기반으로 하며, Cloud Native Hybrid 설치에도 필요합니다.

Terraform: FIPS AMI 사용

GitLab 팀 구성원은 FIPS AMI를 사용하는 방법에 대해 내부 핸드북 페이지에서 더 많은 정보를 확인할 수 있습니다: https://internal.gitlab.com/handbook/engineering/fedramp-compliance/get-configure/#terraform---use-fips-ami

Ansible: FIPS Omnibus 빌드 지정

표준 Omnibus GitLab 릴리스는 자체 OpenSSL 라이브러리를 빌드하지만 해당 라이브러리는 FIPS를 유효성 검사하지 않습니다. 그러나 운영 체제의 OpenSSL 라이브러리에 연결된 Omnibus 패키지를 생성하는 매일 빌드가 있습니다. 이 패키지를 사용하려면 Ansible vars.ymlgitlab_editiongitlab_repo_script_url 필드를 업데이트하십시오.

GitLab 팀 구성원은 내부 핸드북 페이지에서 Ansible(AWS)에 대한 자세한 정보를 확인할 수 있습니다: https://internal.gitlab.com/handbook/engineering/fedramp-compliance/get-configure/#ansible-aws

클라우드 네이티브 하이브리드

클라우드 네이티브 하이브리드 설치는 Omnibus 및 클라우드 네이티브 GitLab (CNG) 이미지를 모두 사용합니다. 이전 지침은 Omnibus 부분을 다루지만, CNG에서 FIPS를 활성화하려면 두 가지 추가 단계가 필요합니다.

  1. 사용자 정의 Amazon Elastic Kubernetes Service (EKS) AMI 사용
  2. RedHat의 Universal Base Image (UBI)로 빌드된 GitLab 컨테이너 사용
사용자 정의 EKS AMI 빌드

Amazon은 아직 FIPS를 지원하는 AMI를 게시하지 않기 때문에 Packer를 사용하여 직접 빌드해야 합니다.

Amazon은 사용자 정의 EKS AMI에 관한 정보를 포함하는 다음 Git 리포지터리를 게시합니다.

GitHub pull request를 이용하면 특정 Kubernetes v1.21을 위해 FIPS가 활성화된 Amazon Linux 2 EKS AMI를 쉽게 생성할 수 있습니다. 이미지를 빌드하려면:

  1. Packer 설치
  2. 다음을 실행합니다:

    git clone https://github.com/awslabs/amazon-eks-ami
    cd amazon-eks-ami
    git fetch origin pull/898/head:fips-ami
    git checkout fips-ami
    AWS_DEFAULT_REGION=us-east-1 make 1.21-fips # 지역을 적절히 설정하세요
    

만약 다른 버전의 Kubernetes를 사용하고 있다면, make 명령어와 Makefile을 해당 버전에 맞게 조정해야 합니다.

AMI 빌드가 완료되면 다음과 유사한 메시지가 포함된 메시지로 새 AMI가 생성됩니다:

==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-west-2: ami-0a25e760cd00b027e

이 예에서 AMI ID는 ami-0a25e760cd00b027e이지만, 실제 값은 다를 수 있습니다.

RHEL 기반 시스템을 FIPS 활성화된 상태로 빌드하는 것이 가능하지만, Packer 빌드를 완료하지 못하는 미해결된 문제가 있습니다.

이미지의 특정 버전을 기반으로 사용자 정의 AMI를 빌드하기 때문에, 최신 보안 패치 및 업그레이드에 따라 정기적으로 사용자 정의 AMI를 다시 빌드해야 합니다.

Terraform: 사용자 정의 EKS AMI 사용

GitLab 팀 구성원은 사용자 정의 EKS AMI를 사용하는 방법에 대해 내부 핸드북 페이지에서 더 많은 정보를 확인할 수 있습니다: https://internal.gitlab.com/handbook/engineering/fedramp-compliance/get-configure/#terraform---use-a-custom-eks-ami

Ansible: UBI 이미지 사용

CNG는 Helm 차트를 사용하여 배포할 컨테이너 이미지를 관리합니다. UBI 기반 컨테이너를 사용하려면 Ansible vars.yml을 편집하여 사용자 지정 차트 변수를 지정합니다.

all:
  vars:
    ...
    gitlab_charts_custom_config_file: '/path/to/gitlab-environment-toolkit/ansible/environments/gitlab-10k/inventory/charts.yml'

이제 지정된 위치에 charts.yml을 만들고 접미사가 -fips인 태그를 지정하세요.

더 많은 자세한 정보와 참조를 위해 FIPS에 대한 차트 문서예시 값 파일을 확인하십시오.

릴리스 태그도 사용할 수 있지만, 각 컴포넌트가 자체 버전 관리 체계를 사용하기 때문에 버전 관리가 까다로울 수 있습니다. 예를 들어, GitLab v15.2의 경우:

global:
  image:
    tagSuffix: -fips
  certificates:
    image:
      tag: 20211220-r0
  kubectl:
    image:
      tag: 1.18.20

gitlab:
  gitaly:
    image:
      tag: v15.2.0
  gitlab-exporter:
    image:
      tag: 11.17.1
  gitlab-shell:
    image:
      tag: v14.9.0
  gitlab-mailroom:
    image:
      tag: v15.2.0
  gitlab-pages:
    image:
      tag: v1.61.0
  migrations:
    image:
      tag: v15.2.0
  sidekiq:
    image:
      tag: v15.2.0
  toolbox:
    image:
      tag: v15.2.0
  webservice:
    image:
      tag: v15.2.0
    workhorse:
      tag: v15.2.0

FIPS 성능 벤치마킹

품질 엔지니어링 활성화 팀은 FIPS를 지원하는 환경이 비-FIPS 환경과 비교하여 어떻게 성능을 발휘하는지 확인하여 이러한 노력을 지원합니다.

테스트 결과, Gitaly SSL과 같은 일부 영역에서 영향을 받지만 고객에게 큰 영향을 미치지는 않습니다.

FIPS 성능 벤치마킹에 대한 자세한 정보는 다음 이슈에서 확인할 수 있습니다:

FIPS를 지원하는 개발 환경 설정

가장 간단한 방법은 Red Hat Enterprise Linux 8를 실행하는 가상 머신을 설정하는 것입니다.

Red Hat은 개발자에게 무료 라이선스를 제공하고 CD 이미지를 Red Hat 개발자 포털에서 다운로드할 수 있습니다. 등록이 필요합니다.

가상 머신을 설정한 후 GDK 설치 지침 및 RHEL에 대한 고급 지침을 따르면 됩니다. 의존성 관리에 asdf를 사용하지 않아야 하므로 RedHat에서 제공하는 Go 컴파일러 및 기타 시스템 의존성을 사용해야 함에 주의하십시오.

FIPS 모드 활성화

GDK 및 해당 의존성을 설치한 후 다음 명령을 실행하고 (root로) 가상 머신을 다시 시작하십시오.

fips-mode-setup --enable

다음을 실행하여 효과가 적용되었는지 확인할 수 있습니다.

fips-mode-setup --check

이 환경에서 OpenSSL은 FIPS 표준에서 금지된 암호화 작업을 수행하지 않습니다. 이를 통해 FIPS 관련 버그를 재현하고 수정을 검증할 수 있습니다.

가상 머신 내에서 웹 브라우저를 열고 GitLab 인스턴스에 로그인할 수 있어야 합니다.

FIPS 모드를 다시 비활성화하려면 다음 명령을 실행한 다음 가상 머신을 다시 시작하십시오.

fips-mode-setup --disable

코드에서 FIPS 활성 여부 감지

루비 코드에서 Gitlab::FIPS를 조회하여 인스턴스가 FIPS로 활성화되었는지 확인할 수 있습니다.

def default_min_key_size(name)
  if Gitlab::FIPS.enabled?
    Gitlab::SSHPublicKey.supported_sizes(name).select(&:positive?).min || -1
  else
    0
  end
end

Omnibus FIPS 패키지

GitLab은 FIPS 규정 준수로 구축된 Omnibus GitLab 빌드를 위한 전용 리포지터리(gitlab/gitlab-fips)를 보유하고 있습니다. 이러한 GitLab 빌드는 시스템 OpenSSL을 사용하여 Omnibus에 포함된 OpenSSL 버전 대신 컴파일됩니다. 이러한 패키지는 다음과 같이 구축됩니다.

  • RHEL 8 (및 호환 버전)
  • AmazonLinux 2
  • Ubuntu

이러한 패키지는 GitLab 환경 툴킷(GET)에서 사용됩니다.

FIPS Omnibus 빌드가 생성된 방법에 대한 섹션을 참조하세요(#how-fips-builds-are-created).

매일 Omnibus FIPS 빌드

배포 팀은 매일 FIPS Omnibus 빌드를 생성했습니다. 이는 테스트를 위해 사용할 수 있습니다. 이것들은 절대 프로덕션 환경에서 사용해서는 안 됩니다.

러너

FIPS 호환 GitLab 러너를 설치하는 방법에 대한 문서를 참조하십시오.

FIPS 확인

다음 섹션에서 FIPS가 활성화되었는지 확인할 수 있는 방법을 설명합니다.

커널

$ cat /proc/sys/crypto/fips_enabled
1

루비 (Omnibus 이미지)

$ /opt/gitlab/embedded/bin/irb
irb(main):001:0> require 'openssl'; OpenSSL.fips_mode
=> true

루비 (CNG 이미지)

$ irb
irb(main):001:0> require 'openssl'; OpenSSL.fips_mode
=> true

Go

Google은 Go 컴파일러의 dev.boringcrypto 브랜치를 유지하여 OpenSSL에서 포크된 FIPS-검증 모듈인 BoringSSL을 정적으로 링크하는 것이 가능하게 했습니다. 그러나 BoringSSL은 일반적으로 사용하도록 고안된 것이 아닙니다.

이를 위해 golang-fips를 사용하여 Go 프로그램을 빌드합니다. 이것에는 여러 가지 장점이 있습니다.

  • FIPS-검증된 시스템 OpenSSL을 사용하는 것이 간단합니다.
  • 이것은 Red Hat의 go-toolset 패키지에서 사용하는 소스 코드입니다.
  • go-toolset과 달리, 이 포크는 최신 Go 릴리스를 따라갑니다.

그러나 이를 작동하려면 CGO_ENABLED=1을 통해 cgo를 활성화해야 합니다.

리눅스 x86에서 golang-fips로 컴파일된 프로젝트를 자동으로 빌드하면 OpenSSL을 사용하는 암호 루틴이 함께 빌드됩니다. boringcrypto 빌드 태그가 자동으로 포함되어 있지만 추가 빌드 태그는 실제로 필요하지 않습니다. 이와 관련된 특정 빌드 태그가 있습니다.

go tool nm을 사용하여 주어진 이진 파일이 OpenSSL을 사용하는지 확인할 수 있으며, Cfunc__goboringcrypto로 이름이 지정된 심볼을 찾으면 됩니다. 예를 들어:

$ go tool nm nginx-ingress-controller  | grep Cfunc__goboringcrypto | tail
 2a0b650 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Final
 2a0b658 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Init
 2a0b660 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Update
 2a0b668 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Final
 2a0b670 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Init
 2a0b678 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Update
 2a0b680 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ECDSA_sign
 2a0b688 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ECDSA_verify
 2a0b690 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ERR_error_string_n
 2a0b698 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ERR_get_error

또한 LabKit에는 FIPS 활성화 여부를 확인하는 루틴이 포함되어 있습니다.

FIPS 빌드 생성 방법

많은 GitLab 프로젝트(Gitaly, GitLab Pages 등)는 로컬에서 FIPS_MODE=1 make를 사용하여 FIPS 이진 파일을 빌드하는 것을 표준으로 삼았습니다.

Omnibus

Omnibus FIPS 빌드는 USE_SYSTEM_SSL 환경 변수를 true로 설정하여 트리거됩니다. 이 환경 변수가 설정되면 Omnibus 레시피의 의존성인 curl, NGINX 및 libgit2가 시스템 OpenSSL에 링크됩니다. OpenSSL은 Omnibus 빌드에 포함되지 않습니다.

Omnibus 빌드는 이러한 컨테이너 이미지를 사용하여 생성됩니다. 예를 들어, 이 작업은 RHEL 8용 패키지를 빌드하기 위해 사용된 registry.gitlab.com/gitlab-org/gitlab-omnibus-builder/centos_8_fips:3.3.1 이미지를 생성했습니다.

다른 Linux 배포판을 위한 새 FIPS 빌드 추가

먼저, 원하는 Linux 배포판에 대한 Omnibus 빌더 이미지가 있는지 확인해야 합니다. Omnibus 패키지를 빌드하는 데 사용되는 이미지는 Omnibus Builder images를 통해 생성됩니다.

이 Merge Request를 확인하세요. 새 이미지는 다음과 같이 추가할 수 있습니다:

  1. _fips 접미사를 사용한 CI 작업 추가(예: ubuntu_18.04_fips).
  2. DockerfileSnippets.new.populate 대신에 Snippets.new(fips: fips).populate를 사용하도록 확인합니다.

이 이미지에 태그가 추가되면, Omnibus GitLab에 새 CI 작업을 추가합니다.

Cloud Native GitLab (CNG)

Cloud Native GitLab CI 파이프라인은 여러 베이스 이미지를 사용하여 이미지를 생성합니다:

UBI 이미지에는 RHEL에서 사용하는 것과 동일한 OpenSSL 패키지가 함께 제공됩니다. 이를 통해 RHEL을 필요로하지 않고도 FIPS 호환 이진 파일을 빌드할 수 있습니다. RHEL 8.2에는 FIPS-확인된 OpenSSL이 함께 제공되나, 8.5는 FIPS 확인을 위한 검토 중입니다.

이 Merge Request는 CNG 이미지를 위한 FIPS 파이프라인을 소개합니다. FIPS로 태그가 지정된 이미지에는 -fips 접미사가 있습니다. 예를 들어, webservice 컨테이너에는 다음과 같은 태그가 있습니다:

  • master
  • master-ubi8
  • master-fips

FIPS 빌드용 베이스 이미지

FIPS 파이프라인으로 Merge Request 테스트

패키지 및 QA를 트리거할 수 있는 Merge Request는 FIPS 패키지 및 참조 아키텍처 테스트 파이프라인을 트리거할 수 있습니다. 트리거에 사용되는 베이스 이미지는 Ubuntu 20.04 FIPS입니다:

  1. 이미 e2e:package-and-test 작업이 트리거되지 않은 경우, 해당 작업을 트리거합니다.
  2. gitlab-omnibus-mirror 자식 파이프라인에서 매뉴얼으로 Trigger:package:fips를 트리거합니다.
  3. 패키지 작업이 완료되면 매뉴얼으로 RAT:FIPS 작업을 트리거합니다.