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

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

경고: FIPS 규정 준수 인스턴스를 GitLab에서 구축할 수 있지만, 모든 기능이 포함되지는 않습니다. FIPS 규정 준수 인스턴스는 FIPS 설치 지침을 정확하게 준수해야 합니다.

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

현재 상태

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

GitLab의 FIPS 규정 준수

FIPS 준수를 위해서는 모든 컴포넌트(GitLab 자체, Gitaly 등)뿐만 아니라 해당 컴포넌트 간의 통신 및 사용된 모든 리포지터리도 준수해야 합니다. 기능이 준수되지 못하는 경우 FIPS 모드가 활성화되면 비활성화되어야 합니다.

활용된 암호 모듈

암호 모듈 이름 CMVP 번호 인스턴스 유형 사용된 소프트웨어 컴포넌트
Ubuntu 20.04 AWS Kernel Crypto API Cryptographic Module 4132 EC2 리눅스 커널
Ubuntu 20.04 OpenSSL Cryptographic Module 3966 EC2 Gitaly, Rails (Puma/Sidekiq)
Ubuntu 20.04 Libgcrypt Cryptographic Module 3902 EC2 인스턴스 gpg, sshd
Amazon Linux 2 Kernel Crypto API Cryptographic Module 3709 EKS 노드 리눅스 커널
Amazon Linux 2 OpenSSL Cryptographic Module 3553 EKS 노드 NGINX
RedHat Enterprise Linux 8 OpenSSL Cryptographic Module 4271 EKS 노드 UBI 컨테이너: Workhorse, Pages, 컨테이너 레지스트리, Rails (Puma/Sidekiq), 보안 분석기, gitlab-sshd
RedHat Enterprise Linux 8 Libgcrypt Cryptographic Module 3784 EKS 노드 UBI 컨테이너: GitLab Shell, gpg

지원되는 운영 체제

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

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

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

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

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

GitLab의 FIPS 검증

FIPS 준수와 달리 FIPS 검증은 인증 받은 감사인에 의한 준수의 공식 선언입니다. 감사에 통과하기 위해 필요한 요구 사항은 FIPS 준수와 동일합니다.

FIPS-검증된 모듈 디렉터리은 미국표준기술연구소(National Institute of Standards and Technology)에서 찾을 수 있습니다.

FIPS 규정 준수로 GitLab 설치하기

본 가이드는 FIPS 규정 준수가 필요한 일반 사용자나 GitLab 팀 구성원을 대상으로 합니다. 본 가이드는 옴니버스 및 클라우드 네이티브 GitLab 설치 요소를 혼합하여 하이브리드 배포를 개요로 제공합니다.

전제 조건

  • Amazon Web Services 계정: 우리의 첫 번째 타겟 환경은 AWS에서 실행되며 다른 FIPS 준수 AWS 리소스를 사용합니다.
  • GitLab을 위한 Ubuntu 20.04 머신을 실행할 수 있는 능력: 첫 번째 타겟 환경은 하이브리드 아키텍처를 사용합니다.

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 릴리스는 자체의 FIPS-검증된 OpenSSL 라이브러리를 빌드하지만, 우리는 운영 체제의 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 부분을 다룹니다. 그러나 FIPS를 CNG에서 활성화하려면 두 가지 추가 단계가 필요합니다:

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

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

Amazon은 다음 Git 리포지터리들에 사용자 지정 EKS AMI에 관한 정보를 게시합니다:

이 GitHub 풀 리퀘스트는 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가 생성되어야 합니다: 

==> 빌드 완료. 성공적으로 생성된 빌드 아티팩트는 다음과 같습니다:
--> amazon-ebs: 생성된 AMI:
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 활성화 개발 환경 설정

가장 간단한 접근 방법은 다음과 같습니다:

  1. Red Hat Enterprise Linux 8을 실행하는 가상 머신을 설정하는 것입니다.
  2. 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 빌드는 시스템 OpenSSL을 사용하여 Omnibus에 포함된 OpenSSL 버전 대신에 컴파일되었습니다. 이러한 패키지는 다음과 같이 빌드되었습니다:

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

이러한 패키지는 GitLab 환경 도구(GIT)에서 소비됩니다.

FIPS 빌드가 만들어지는 방법은 FIPS 빌드가 생성되는 방법 섹션을 참조하십시오.

매일 Omnibus FIPS 빌드

배포 팀은 매일 FIPS Omnibus 빌드를 만들었으며, 이는 테스트 목적으로 사용할 수 있습니다. 이러한 빌드는 절대로 운영 환경에 사용해서는 안 됩니다.

Runner

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

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 브랜치를 유지하며, FIPS에서 인증된 OpenSSL에서 포크된 BoringSSL을 정적으로 링크할 수 있도록합니다. 그러나 BoringSSL은 일반적인 사용을 위한 것이 아닙니다.

우리는 Linux x86에서 golang-fips를 사용하여 컴파일된 프로젝트는 자동으로 OpenSSL을 사용하는 암호 루틴을 포함합니다. boringcrypto 빌드 태그는 자동으로 존재하지만, 추가 빌드 태그는 실제로 필요로하지 않습니다. 이에 따르면 go tool nm을 사용하여 주어진 이진 파일이 OpenSSL을 사용하는지 확인할 수 있습니다.

예시: 

$ 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 활성화 여부를 확인 (check) 할 수 있는 루틴이 포함되어 있습니다.

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 이미지로 생성됩니다.

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

  1. _fips 접미사가 있는 CI 작업 추가(예: ubuntu_18.04_fips).
  2. Dockerfile이 Snippets.new(fips: fips).populate를 사용하여 Snippets.new.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 작업을 트리거합니다.