FIPS는 "Federal Information Processing Standard(연방 정보 처리 표준)"의 약자로, "암호화 모듈(Cryptographic Module, CM)"에 대한 특정 보안 관행을 정의합니다. 암호화 모듈은 승인된 보안 기능(암호화 알고리즘 및 키 생성 포함)을 구현하고 암호화 경계 내에 포함된 하드웨어, 소프트웨어 또는 펌웨어의 집합입니다.

GitLab에서 암호화 모듈은 거의 항상 다른 제품이나 패키지 릴리스에 내장된 소프트웨어 구성 요소를 의미하며, 특정 바이너리 버전에 해당합니다. 예를 들어, 특정 버전의 Ubuntu Kernel Crypto API 암호화 모듈 또는 OpenSSL 프로젝트의 FIPS Provider가 이에 해당합니다.

모듈은 NIST 인증 실험실의 테스트를 완료하고 암호화 모듈 검증 프로그램(Cryptographic Module Validation Program)에 유효한 인증서가 등록되면 검증됩니다. 암호화 모듈은 CMVP 보안 정책에 따라 컴파일, 설치 및 구성되어야 합니다.

규제 요건#

GitLab은 FIPS 140-2 및 140-3을 준수해야 하는 고객을 위한 소프트웨어를 릴리스하는 데 최선을 다하고 있습니다.

FIPS 140은 미국 공공 부문뿐만 아니라 일부 비미국 공공 부문 조직 및 특정 산업(의료, 금융 등)에서 비즈니스를 수행하기 위한 요건입니다. FIPS 140-2 및 FIPS 140-3 요건은 Self-managed 또는 클라우드 방식에 관계없이 구매하는 소프트웨어를 포함한 모든 미국 연방 기관에 적용됩니다. 기관은 15 U.S.C. § 278g-3에 정의된 모든 운영 및 자산에 적절한 정보 보안을 제공하기 위해 암호화 기반 보안 시스템을 사용해야 합니다.

검증되지 않은 암호화는 현재 정보나 데이터에 어떠한 보호도 제공하지 않는 것으로 간주됩니다. 사실상 데이터는 보호되지 않은 평문으로 간주됩니다. 기관이 정보나 데이터를 암호화 방식으로 보호하도록 지정하면 FIPS 140-2 또는 FIPS 140-3이 적용됩니다. 즉, 암호화가 필요한 경우에는 반드시 검증되어야 합니다. 암호화 모듈이 취소된 경우, 해당 모듈의 사용은 더 이상 허용되지 않습니다.

어려움은 FIPS 검증 모듈의 사용이 소프트웨어 패키지 또는 바이너리의 특정 버전 사용을 요구한다는 점입니다. 과거에는 일부 조직이 규정 준수를 유지하기 위해 버전을 고정(pin)하거나 잠그는 방식을 사용했습니다. 문제는 이러한 검증 모듈이 결국 취약해진다는 것이며, 새로운 버전의 검증을 획득하는 데 오랜 시간이 걸리기 때문에 다음 두 가지 연방 의무를 지속적으로 동시에 달성하는 것이 비현실적입니다:

• 검증된 모듈의 사용.

• 취약점의 적시 완화.

이 분야의 규제 환경 및 정책 수립은 역동적이며 GitLab의 면밀한 모니터링이 필요합니다.

사용을 피해야 할 용어#

이 표현들은 GitLab 및 소프트웨어 제공업체에서 광범위하게 사용됩니다. 그러나 이러한 용어 사용을 지양하고 문서를 업데이트해야 합니다.

• "FIPS compliant" 또는 "FIPS compliance": 이 용어들은 NIST 또는 CMVP에서 정의한 공식 용어가 아니므로 사용해서는 안 됩니다. 모호함이나 주관적인 해석의 여지가 있기 때문입니다.

FIPS 140 준수는 CMVP 검증 모듈의 엄격한 사용, CMVP 승인 보안 기능, CMVP 승인 민감한 매개변수 생성 및 확립 방법, CMVP 승인 인증 메커니즘을 포함한 암호화 모듈에 대한 전체 표준 및 모든 보안 요건의 준수를 요구합니다.

• 이 용어는 종종 표준의 한 가지 측면에 불과한 "CMVP 승인 보안 기능" 사용과 동의어로 사용됩니다.

사용해야 할 용어#

다음 공식 용어 및 표현은 CMVP에서 사용 승인을 받았습니다.

• CMVP 인증서 및 번호가 있는 암호화 모듈을 지칭할 때 "FIPS 140-2 Validated" 또는 "FIPS-validated"를 사용합니다.

• GitLab, GitLab 소프트웨어 구성 요소 또는 GitLab 배포 소프트웨어와 같이 FIPS 검증 모듈을 내장하는 제품을 지칭할 때 "FIPS 140-2 Inside" 또는 "FIPS inside"를 사용합니다. 제품에 FIPS 140-2 모듈이 내부적으로 포함되어 있고 FIPS 공식 로고를 사용하는 경우, 로고와 함께 "FIPS 140-2 Inside" 및 인증서 번호도 표시해야 합니다.

• "CMVP 승인 보안 기능" 또는 "FIPS 승인 알고리즘": 기술적으로 후자는 공식 표현이 아니지만 동일한 의미를 전달하며 NIST 용어에 익숙하지 않은 사람들에게 추가적인 맥락을 제공합니다. 이는 CMVP 승인 암호화 알고리즘과 승인된 사용 사례를 지정하는 NIST SP 800-140C를 참조합니다.

GitLab의 FIPS 140 구현#

GitLab은 SaaS First 기업으로서 연방 위험 및 인가 관리 프로그램(Federal Risk and Authorization Management Program, FedRAMP)의 최신 지침을 따릅니다. FedRAMP는 클라우드 서비스 제공업체가 암호화, 해싱, 난수 생성, 키 생성을 포함하여 암호화가 필요한 모든 곳에 FIPS 검증 암호화 모듈을 사용하도록 요구합니다. 그러나 FedRAMP 보안 제어 기준의 제어 SC-13에 따르면, 다음 조건에서는 FIPS 검증되지 않은 암호화 모듈 사용이 허용됩니다:

• FIPS 검증 버전에 알려진 취약점이 있는 경우.

• 취약점이 있는 기능이 사용 중인 경우.

• 비FIPS 버전이 해당 취약점을 수정하는 경우.

• 비FIPS 버전이 FIPS 검증을 위해 NIST에 제출된 경우. 즉, CMVP 웹사이트의 Modules In Process 또는 Implementation Under Test에 등록된 경우.

• 준비가 되면 승인 및 배포를 추적하기 위해 POA&M이 추가되는 경우.

FedRAMP는 보다 실용적인 구현 지침을 제공하기 위한 초안(변경될 수 있음) 암호화 모듈 선택 및 사용 정책(Policy for Cryptographic Module Selection and Use)을 공개했습니다. 주목할 점은 알려진 취약점이 검증의 보증 가치보다 큰 위험을 초래하기 때문에 FIPS 검증된 알려진 취약 소프트웨어를 계속 사용하는 것보다 패치나 업데이트를 통해 알려진 취약점을 해결하는 것을 선호한다는 것입니다.

이 초안 정책의 CSP01 요건에 따라 GitLab은 암호화 모듈에 패치를 적용하는 입장을 취합니다. CSP10에 따른 암호화 모듈 선택 우선순위는 다음과 같습니다:

• 검증된 모듈의 취약점 완화.

• 검증되지 않은 모듈 사용 시 다음 우선순위 순서로:

모듈이 FIPS 검증 모듈과 실질적으로 유사함; 검증된 알고리즘.

• 모듈에 대한 FIPS 검증 진행 중; 검증된 알고리즘.

• 이전에 검증된 모듈의 만료된 FIPS 검증; 검증된 알고리즘.

• 모듈이 FIPS 검증 프로세스 미진행; 검증된 알고리즘.

• 알고리즘이 승인 및 테스트되었지만 아직 검증되지 않았으며 모듈이 FIPS 검증 프로세스 미진행.

검증 워크플로#

제3자 평가 조직(Third Party Assessment Organizations, 3PAOs)은 다음을 통해 FIPS 검증 CM의 사용을 검증합니다:

• 인증서 번호 확인.

• CM이 승인된 모드로 구성되어 있고 CM의 보안 정책에서 승인된 것으로 나열된 알고리즘만 사용하는지 검증.

GitLab은 또한 내부적으로 지속적인 모니터링을 수행하며, 과거에는 독립 감사자에게 의뢰하여 FIPS 140 표준에 대한 소프트웨어 감사를 진행했습니다. 결과는 Trust Center에서 확인할 수 있습니다.

GitLab FIPS 승인 소프트웨어#

GitLab은 현재 Omnibus(Linux 패키지) 배포, 클라우드 네이티브(Helm 차트) 배포, GitLab Runner, 보안 분석기 등을 위한 소프트웨어를 릴리스하고 있습니다. 위에서 언급했듯이 GitLab은 FedRAMP 지침을 따르며, 가능한 경우 FIPS 140-2 검증 모듈(FIPS inside)을 포함하려고 노력하지만, 최소한 FIPS 승인 알고리즘(CMVP 승인 보안 기능)을 포함합니다. GitLab은 FIPS 140-2와 관련하여 두 가지를 모두 달성할 수 없는 상황에서 규정 준수보다 보안을 우선시합니다.

AI Gateway#

FIPS 검증 AI Gateway Docker 이미지는 GitLab Duo Self-Hosted 배포에 사용할 수 있습니다. 이 이미지는 Red Hat UBI 9 기반으로 빌드되며 CMVP 검증 OpenSSL FIPS provider를 사용합니다.

설치 지침은 FIPS 검증 이미지를 참조하세요.

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

일부 GitLab 기능은 FIPS 모드가 활성화된 경우 작동하지 않을 수 있습니다. 다음은 FIPS 모드에서 작동하지 않는 것으로 알려진 기능들입니다. 그러나 여기에 나열되지 않은 추가 기능도 FIPS 모드에서 제대로 작동하지 않을 수 있습니다:

인증이 필요한 리포지터리의 이미지 스캐닝에 대한 컨테이너 스캐닝 지원.

코드 품질(Code Quality)은 FIPS 준수 모드에서 작동을 지원하지 않습니다.

Gradle에 대한 종속성 스캐닝 지원.

yarn 프로젝트에 대한 취약점 솔루션.

정적 애플리케이션 보안 테스트(SAST)는 FIPS 준수 모드에서 운영할 때 분석기의 제한된 세트를 지원합니다.

운영 컨테이너 스캐닝.

GitLab 및 FIPS는 DSA 인증서 파일을 지원하지 않습니다. 로그에서 DSA 인증서 오류가 발생하면 DSA를 제외하도록 sshHostKeys.types 설정을 구성하세요:

gitlab:
  webservice:
    sshHostKeys:
      types: [rsa,ecdsa,ed25519]

ED25519 키는 모든 FIPS 시스템에서 완전히 지원되지 않을 수 있습니다.

자세한 내용은 이슈 367429를 참조하세요.

또한 다음 패키지 리포지터리는 FIPS 모드에서 비활성화됩니다:

• Conan 1 패키지 리포지터리.

• Conan 2 패키지 리포지터리.

• Debian 패키지 리포지터리.

개발 가이드라인#

자세한 내용은 위의 정보를 참조하고 GitLab 암호화 표준(GitLab Cryptography Standard)을 확인하세요. 질문이 있으면 #sec-assurance에 문의하거나 명확히 해야 할 사항이 있으면 MR을 열어주세요.

다음은 GitLab FIPS 승인 소프트웨어 개발을 위한 가이드라인입니다:

대부분 또는 모든 암호화 호출이 FIPS 검증 OpenSSL(예시)을 사용해야 합니다:

운영 체제 또는 컨테이너 기본 이미지의 일부로 내장(권장).

• 독립 실행형.

OpenSSL 3.0은 이제 fips.so라는 CMVP 검증 모듈인 OpenSSL FIPS Provider를 사용하면서도 모듈을 무효화하지 않고 나머지 OpenSSL에 보안 패치를 적용할 수 있습니다(OpenSSL README-FIPS.md 참조). 이는 이제 RHEL 9 및 UBI9에서도 사용할 수 있습니다 (CMVP 인증서 #4746).

비승인 암호화 알고리즘(예: MD5)을 피하고 FIPS 140-3 승인 알고리즘(예: SHA256)으로 전환해야 합니다. MD5는 암호화적으로 취약하기 때문에 이는 좋은 관행입니다.

비암호화 목적으로 비승인 암호화 알고리즘을 사용할 수 있는 경우가 있을 수 있습니다. 예를 들어, SHA1은 FIPS 140-3 알고리즘이 아니지만 Git이 비암호화 목적으로 사용하기 때문에 사용할 수 있습니다. 이러한 경우 암호화 목적으로 사용되지 않는 이유를 문서화하거나 해당 기능을 완전히 비활성화해야 합니다.

하위 호환성. 알고리즘을 전환하면 기존 기능이 중단될 수 있는 기능이 있을 수 있습니다. 예를 들어, 데이터베이스는 bcrypt로 암호화된 비밀번호를 저장하는데, 사용자의 도움 없이는 이 비밀번호를 재암호화할 수 없습니다.

• GitLab은 FIPS 승인 소프트웨어 릴리스를 위해 RHEL 및 UBI를 표준으로 채택했으며, Ruby, Go, CNG, Omnibus 및 Runner, Secure 분석기 등의 다른 소프트웨어에 대해 아래에 설명된 패턴을 사용해야 합니다.

FIPS 준수 GitLab 설치#

이 가이드는 FIPS 준수 GitLab 프로덕션 인스턴스를 실행해야 하는 공개 사용자 또는 GitLab 팀 구성원을 위한 것입니다. 이 가이드는 Omnibus와 Cloud Native GitLab 설치 방식의 요소를 모두 사용하는 하이브리드 배포 방식을 설명합니다.

필수 조건#

• Amazon Web Services 계정. 첫 번째 타깃 환경은 AWS에서 실행되며 다른 FIPS 준수 AWS 리소스를 사용합니다. 많은 AWS 리소스의 경우 FIPS 전용 엔드포인트를 사용해야 합니다.

• GitLab을 위한 Ubuntu 20.04 머신 실행 능력. 첫 번째 타깃 환경은 하이브리드 아키텍처를 사용합니다.

• 고급 검색: GitLab은 패키지된 Elastic 또는 OpenSearch 배포를 제공하지 않습니다. FIPS 준수 서비스를 사용하거나 고급 검색을 비활성화해야 합니다.

FIPS 활성화 클러스터 설정#

GitLab Environment Toolkit을 사용하여 개발 및 테스트를 위한 FIPS 활성화 클러스터를 구동할 수 있습니다. 필수 조건에서 언급했듯이, 이 지침은 첫 번째 타깃 환경이기 때문에 Amazon Web Services(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.yml의 gitlab_edition 및 gitlab_repo_script_url 필드를 업데이트하세요.

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

Cloud Native Hybrid#

Cloud Native Hybrid 설치는 Omnibus와 Cloud Native GitLab(CNG) 이미지를 모두 사용합니다. 이전 지침은 Omnibus 부분을 다루지만, CNG에서 FIPS를 활성화하려면 두 가지 추가 단계가 필요합니다:

• 사용자 정의 Amazon Elastic Kubernetes Service(EKS) AMI 사용.

• RedHat의 Universal Base Image(UBI)로 빌드된 GitLab 컨테이너 사용.

사용자 정의 EKS AMI 빌드#

Amazon이 아직 FIPS 활성화 AMI를 공개하지 않기 때문에 Packer를 사용하여 직접 빌드해야 합니다.

Amazon은 사용자 정의 EKS AMI에 대한 정보가 담긴 다음 Git 리포지터리를 공개하고 있습니다:

• Amazon EKS AMI 빌드 사양

• 샘플 EKS 사용자 정의 AMI

이 GitHub 풀 리퀘스트를 통해 Kubernetes v1.21용 FIPS가 활성화된 Amazon Linux 2 EKS AMI를 생성할 수 있습니다. 이미지를 빌드하려면:

Packer 설치.

다음을 실행하세요:

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 # Be sure to set the region accordingly

다른 버전의 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이지만, 실제 값은 다를 수 있습니다.

FIPS가 활성화된 RHEL 기반 시스템 빌드가 가능해야 하지만, 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을 편집하여 사용자 정의 Charts 변수를 사용하세요:

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

이제 위에 지정된 위치에 charts.yml을 생성하고 -fips 접미사가 있는 태그를 지정하세요.

자세한 내용은 FIPS에 대한 Charts 문서를 참조하세요. 예시 values 파일도 참고할 수 있습니다.

릴리스 태그도 사용할 수 있지만 각 구성 요소마다 자체 버전 체계를 사용할 수 있어 버전 관리가 복잡합니다. 예를 들어, 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 성능 벤치마킹#

Quality Engineering Enablement 팀은 FIPS 활성화 환경이 비FIPS 환경에 비해 얼마나 잘 수행되는지 확인하여 이러한 노력을 지원합니다.

테스트 결과 Gitaly SSL 등 일부 영역에서 영향이 있지만, 고객에게 영향을 줄 만큼 크지는 않습니다.

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

• FIPS 참조 아키텍처 성능 벤치마크

FIPS 활성화 개발 환경 설정#

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

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

가상 머신이 설정된 후 RHEL을 위한 고급 지침을 포함하여 GDK 설치 지침을 따를 수 있습니다. RedHat 제공 Go 컴파일러 및 기타 시스템 의존성을 사용하는 것이 필수적이기 때문에 asdf 도구는 의존성 관리에 사용되지 않습니다.

FIPS 모드 활성화#

GDK 및 의존성이 설치된 후, 다음 명령을 실행하고(root로) 가상 머신을 재시작하세요:

fips-mode-setup --enable

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

fips-mode-setup --check

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

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

다음 명령을 실행한 후 가상 머신을 재시작하여 FIPS 모드를 다시 비활성화할 수 있습니다:

fips-mode-setup --disable

코드에서 FIPS 활성화 감지#

Ruby 코드에서 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 빌드는 다음을 사용하도록 컴파일됩니다:

• GitLab 19.0 이상에서는 Omnibus 내장 버전의 OpenSSL 및 Curl 대신 시스템 OpenSSL 및 Curl.

• GitLab 18.11 이하에서는 Omnibus 내장 버전의 OpenSSL 대신 시스템 OpenSSL.

이러한 패키지는 다음을 위해 빌드됩니다:

• RHEL 8 및 9(호환 포함)

• AmazonLinux 2 및 2023

• Ubuntu 20.04

이것들은 GitLab Environment Toolkit에서 사용됩니다(GET).

FIPS 빌드 생성 방법에 관한 섹션을 참조하세요.

시스템 Libgcrypt#

버그로 인해 GitLab 17.6 이하의 FIPS Linux 패키지는 시스템 Libgcrypt를 사용하지 않고 일반 Linux 패키지에 번들된 동일한 Libgcrypt를 사용했습니다.

이 이슈는 AmazonLinux 2를 제외한 GitLab 17.7의 모든 FIPS Linux 패키지에서 수정되었습니다. AmazonLinux 2의 Libgcrypt 버전은 FIPS Linux 패키지에 포함된 GPGME 및 GnuPG 버전과 호환되지 않습니다.

AmazonLinux 2용 FIPS Linux 패키지는 GPGME 및 GnuPG를 다운그레이드해야 하므로 일반 Linux 패키지에 번들된 동일한 Libgcrypt를 계속 사용합니다.

완전한 준수가 필요한 경우 FIPS Linux 패키지를 사용할 수 있는 다른 운영 체제로 마이그레이션해야 합니다.

야간 Omnibus FIPS 빌드#

Distribution 팀은 테스트 목적으로 사용할 수 있는 야간 FIPS Omnibus 빌드를 생성했습니다. 이는 프로덕션 환경에서 절대 사용해서는 안 됩니다.

Runner#

FIPS 준수 GitLab Runner 설치 문서를 참조하세요.

FIPS 검증#

다음 섹션은 FIPS 활성화 여부를 확인하는 방법을 설명합니다.

커널#

$ cat /proc/sys/crypto/fips_enabled
1

Ruby (Omnibus 이미지)#

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

Ruby (CNG 이미지)#

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

Go#

Google은 Go 컴파일러에서 dev.boringcrypto 브랜치를 유지 관리하여 OpenSSL에서 포크된 FIPS 검증 모듈인 BoringSSL을 정적으로 링크할 수 있게 합니다. 그러나 BoringCrypto는 공식적으로 지원되지 않지만 다른 회사들에서도 사용됩니다.

GitLab은 golang-fips, 즉 dev.boringcrypto 브랜치의 포크를 사용하여 dlopen을 통해 OpenSSL을 동적으로 링크하는 Go 프로그램을 빌드합니다. 이는 다음과 같은 여러 장점이 있습니다:

• FIPS 검증된 시스템 OpenSSL(RHEL/UBI) 사용이 간단합니다.

• 이것은 Red Hat go-toolset 패키지에서 사용하는 소스 코드입니다.

• go-toolset와 달리 이 포크는 최신 Go 릴리스를 따라가는 것으로 보입니다.

그러나 이것이 작동하려면 CGO_ENABLED=1을 통해 cgo를 활성화해야 합니다. C 코드를 호출할 때 성능 저하가 발생합니다.

Linux x86에서 golang-fips로 컴파일된 프로젝트는 OpenSSL을 사용하는 암호화 루틴으로 자동 빌드됩니다. boringcrypto 빌드 태그가 자동으로 존재하지만 추가 빌드 태그는 실제로 필요하지 않습니다. 이러한 암호화 후크를 비활성화하는 특정 빌드 태그가 있습니다.

go tool nm을 통해 주어진 바이너리가 OpenSSL을 사용하는지 확인하고 Cfunc__goboringcrypto 또는 crypto/internal/boring/sig.BoringCrypto라는 심볼을 찾을 수 있습니다.

예를 들어:

$ # Find in a Golang-FIPS 1.17 library
$ go tool nm nginx-ingress-controller | grep '_Cfunc__goboringcrypto_|\bcrypto/internal/boring/sig\.BoringCrypto' | 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
$ # Find in a Golang-FIPS 1.22 library
$ go tool nm tenctl | grep '_Cfunc__goboringcrypto_|\bcrypto/internal/boring/sig\.BoringCrypto'
  4cb840 t crypto/internal/boring/sig.BoringCrypto.abi0

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

FIPS 빌드 생성 방법#

많은 GitLab 프로젝트(예: Gitaly, GitLab Pages)는 로컬에서 FIPS 바이너리를 빌드하기 위해 FIPS_MODE=1 make 사용을 표준화했습니다.

Omnibus#

Omnibus FIPS 빌드는 다음을 사용하도록 컴파일됩니다:

• GitLab 19.0 이상에서는 시스템 OpenSSL 및 Curl. NGINX 및 libgit2와 같은 Omnibus 의존성은 시스템 OpenSSL 및 Curl에 링크됩니다. OpenSSL 및 Curl은 Omnibus 빌드에 포함되지 않습니다.

• GitLab 18.11 이하에서는 시스템 OpenSSL. NGINX 및 libgit2와 같은 Omnibus 의존성은 시스템 OpenSSL에 링크됩니다. OpenSSL은 Omnibus 빌드에 포함되지 않습니다.

Omnibus 빌드는 golang-fips 컴파일러를 사용하는 컨테이너 이미지를 사용하여 생성됩니다. 예를 들어, 이 job은 RHEL 8용 패키지를 빌드하는 데 사용되는 registry.gitlab.com/gitlab-org/gitlab-omnibus-builder/centos_8_fips:3.3.1 이미지를 생성했습니다.

다른 Linux 배포판에 대한 새 FIPS 빌드 추가#

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

이 머지 리퀘스트를 검토하세요. 새 이미지는 다음을 통해 추가할 수 있습니다:

• _fips 접미사가 있는 CI job 추가(예: ubuntu_18.04_fips).

• Dockerfile이 Snippets.new.populate 대신 Snippets.new(fips: fips).populate를 사용하는지 확인.

이 이미지가 태그된 후 Omnibus GitLab에 새 CI job을 추가하세요.

Cloud Native GitLab(CNG)#

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

• Debian

• Red Hat Universal Base Image(UBI)

UBI 이미지는 RHEL에서 사용하는 것과 동일한 OpenSSL 패키지와 함께 제공됩니다. 이를 통해 RHEL 없이도 FIPS 준수 바이너리를 빌드할 수 있습니다. RHEL 8.2는 FIPS 검증 OpenSSL을 제공하지만, 8.5는 FIPS 검증을 위한 검토 중입니다.

이 머지 리퀘스트는 CNG 이미지에 대한 FIPS 파이프라인을 도입합니다. FIPS용으로 태그된 이미지는 -fips 접미사를 갖습니다. 예를 들어, webservice 컨테이너는 다음 태그를 가집니다:

• master

• master-ubi

• master-fips

FIPS 빌드용 기본 이미지#

• 현재: UBI 9.7 Micro

FIPS 파이프라인으로 머지 리퀘스트 테스트#

Package and QA를 트리거할 수 있는 머지 리퀘스트는 FIPS 패키지와 참조 아키텍처 테스트 파이프라인을 트리거할 수 있습니다. 트리거에 사용되는 기본 이미지는 Ubuntu 20.04 FIPS입니다:

• 아직 트리거되지 않은 경우 e2e:test-on-omnibus-ee job을 트리거합니다.

• gitlab-omnibus-mirror 하위 파이프라인에서 수동으로 Trigger:package:fips를 트리거합니다.

• 패키지 job이 완료되면 수동으로 RAT:FIPS job을 트리거합니다.