FIPS(연방정보처리표준) 준수

FIPS는 “Federal Information Processing Standard”의 준말로, “암호화 모듈” (CM)을 위해 특정 보안 관행을 정의하는 문서입니다. 미국 연방 기관에 제품을 판매하는 공급 업체가 특정 보안 기준을 충족시키도록 하는 것을 목표로 합니다.

경고: GitLab의 FIPS(연방정보처리표준) 준수 인스턴스를 구축할 수 있지만, 일부 기능이 포함되지 않습니다. FIPS(연방정보처리표준) 준수 인스턴스는 FIPS 설치 지침을 정확하게 준수하여 구성해야 합니다.

현재 FIPS 표준은 140-2와 140-3이 있습니다. GitLab에서 일반적으로 FIPS 140-2를 의미합니다.

현재 상태

GitLab은이 문서에서 명시된 빌드에 대한 FIPS 140-2 준수를 완료했습니다. FIPS 140-2 Attestation은 고객 보증 패키지의 커뮤니티 패키지에 있습니다.

GitLab의 FIPS 준수

준수해야 하는 항목은 모든 구성 요소(GitLab 자체, Gitaly 등)뿐만 아니라, 이러한 구성 요소간의 통신 및 그들이 사용하는 모든 저장소도 준수해야 합니다. 기능을 준수할 수 없는 경우 FIPS 모드가 활성화되면 해당 기능을 비활성화해야 합니다. FIPS(연방정보처리표준) 준수 암호화는 암호화 작업이 FIPS(연방정보처리표준)로 검증된 모듈을 사용한다는 것을 의미합니다.

활용된 암호화 모듈

다음 목록은 참고용으로 제공되며 동적으로 업데이트되지 않습니다. 아래 모듈의 최신 CMVP 인증서가 적용됩니다.

암호화 모듈 이름 CMVP 번호 인스턴스 유형 사용된 소프트웨어 구성 요소
Ubuntu 20.04 AWS 커널 암호화 API 암호 모듈 4366 EC2 (Omnibus) 리눅스 커널
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 노드 리눅스 커널
Amazon Linux 2 OpenSSL 암호 모듈 4548 EKS 노드 EKS
Red Hat Enterprise Linux 8 OpenSSL 암호 모듈 4642 GitLab Helm 차트 UBI 컨테이너: Workhorse, Pages, 컨테이너 레지스트리, Rails (Puma/Sidekiq), 보안 분석기, gitlab-sshd
Red Hat Enterprise Linux 8 Libgcrypt 암호 모듈 4438 GitLab Helm 차트 UBI 컨테이너: GitLab Shell, gpg

지원되는 운영 체제

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

  • Omnibus GitLab: Ubuntu 20.04 LTS
  • Cloud Native 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) 독립심사실 테스트를 거치지 않아도 되지만, 암호화 모듈 검증 프로그램에 나열된 활성 CMVP 인증서를 가진 FIPS-검증 소프트웨어를 사용해야 하며 이를 모든 암호화 작업에 대해 활성화해야 합니다.

FIPS(연방정보처리표준) 준수 암호화는 암호화 작업이 FIPS-검증 모듈을 사용한다는 것을 의미합니다. FIPS 모드는 통신 세션의 한쪽 또는 양쪽(client, server 또는 둘 다)에서 활성화해야 합니다. 클라이언트에서 FIPS 모드를 활성화하면 클라이언트가 암호화, 해싱 및 서명을 위해 FIPS 140-3/FIPS 140-2와 호환되는 강력한 암호 알고리즘을 사용하도록 보장합니다. 클라이언트에서 FIPS 모드가 활성화되지 않은 경우 서버 측이나 어플리케이션 로드 밸런서 또는 프록시 서버에서 FIPS-검증 연결을 허용하도록 FIPS 모드를 구현해야 합니다.

GitLab 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 Environment Toolkit을 사용할 수 있습니다. 전제 조건에서 설명한대로 이러한 지침은 처음 타깃 환경이 AWS에서 실행되므로 Amazon Web Services(AWS)를 사용합니다.

환경 설정

시작하려면 AWS 계정이 AWS Marketplace 콘솔에서 FIPS 활성화 사용자 지정 AMI(Amazon Machine Image)를 구독해야 합니다.

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

Omnibus

FIPS 활성화 GitLab 클러스터를 얻는 가장 간단한 방법은 Omnibus 참조 아키텍처를 사용하는 것입니다. 자세한 내용은 GET Quick Start Guide를 참조하십시오. 다음 지침은 Quick Start를 보충하며 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 및 클라우드 네이티브 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를 통해 Amazon Linux 2 EKS AMI에 FIPS를 활성화할 수 있습니다. 이미지를 빌드하려면 다음을 실행하십시오.

  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 빌드가 완료되면 다음과 유사한 메시지가 표시되어야 합니다. 

==> 빌드 완료. 성공한 빌드의 결과물은 다음과 같습니다:
--> amazon-ebs: AMI가 생성되었습니다:
us-west-2: ami-0a25e760cd00b027e

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

RHEL 기반 시스템을 FIPS를 활성화한 상태로 빌드할 수 있지만, Packer 빌드가 완료되지 못하는 문제가 있습니다.

이미지가 특정 버전의 이미지를 기반으로 만들었기 때문에 최신 보안 패치 및 업그레이드와 함께 사용자 정의 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 및 해당 종속성을 설치한 후 다음 명령을 실행하고 가상 머신을 다시 시작합니다. (루트로 실행) 

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 빌드는 Omnibus에 포함된 OpenSSL 대신 시스템 OpenSSL을 사용하도록 컴파일됩니다. 이러한 패키지는 다음과 같은 운영체제로 빌드됩니다:

  • RHEL 8 (및 호환 운영체제)
  • AmazonLinux 2
  • Ubuntu

이러한 패키지는 GitLab Environment Toolkit(GET)에서 사용됩니다.

FIPS 빌드가 만들어지는 방법에 대한 섹션을 확인해보세요.

매일 Omnibus FIPS 빌드

배포 팀은 매일 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은 공식적으로 사용되지 않는 OpenSSL에서 포크된 FIPS-검증 모듈인 BoringSSL을 정적으로 링크할 수 있게 하는 dev.boringcrypto 브랜치를 유지합니다.

그러나 BoringSSL은 공개적으로 사용되지 않습니다.

우리는 Go 프로그램을 빌드하기 위해 golang-fips를 사용합니다. 이것은 Red Hat의 go-toolset 패키지에서 사용되는 소스 코드입니다. go-toolset과 달리, 이 포크는 최신 Go 릴리스와 함께 사용됩니다. 그러나 이것은 작동할 때 CGO_ENABLED=1를 통해 cgo를 활성화해야 합니다.

특정 이진파일이 OpenSSL을 사용하고 있는지 확인하는 방법은 go tool nm을 사용하여 Cfunc__goboringcrypto 또는 crypto/internal/boring/sig.BoringCrypto로 명명된 심볼을 찾는 것입니다.

FIPS 빌드 생성 방법

많은 GitLab 프로젝트(예: Gitaly, GitLab Pages)는 로컬에서 FIPS 이진 파일을 빌드하기 위해 FIPS_MODE=1 make를 사용하는 것으로 표준화되어 있습니다.

Omnibus

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

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

다른 Linux 배포판용 FIPS 빌드 추가

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

이미지가 태깅되면, Omnibus GitLab에 새로운 CI 작업을 추가하십시오.

Cloud Native GitLab (CNG)

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

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

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

  • master
  • master-ubi8
  • master-fips

FIPS 빌드용 기본 이미지

FIPS 파이프라인을 활용한 MR 테스트

패키지와 QA를 트리거할 수 있는 MR(병합 요청)은 FIPS 패키지와 참조 아키텍처 테스트 파이프라인을 트리거할 수 있습니다. 트리거에 사용된 기본 이미지는 Ubuntu 20.04 FIPS입니다:

  1. e2e:test-on-omnibus 작업을 트리거하십시오. 이미 트리거되었다면 넘어가도록 합니다.
  2. gitlab-omnibus-mirror 하위 파이프라인에서 수동으로 Trigger:package:fips를 트리거하십시오.
  3. 패키지 작업이 완료되면, 수동으로 RAT:FIPS 작업을 트리거하십시오.