내장 FIPS 140-3 지원

내장 FIPS 140-3 지원 (FIPS 140-3 Inside)

특별히 빌드된 Vault Enterprise(fips1403 기능 이름 표기)는 FIPS 140-3 준수를 위한 내장 지원을 포함합니다. FIPS 준수를 위해 Seal Wrap을 사용하는 방식과 달리, 이 바이너리는 HSM에 대한 외부 의존성이 없습니다.

출처: 문서

본문

이 기능을 사용하려면 Vault Enterprise Plus(HSM) 활성 또는 체험판 라이선스가 필요합니다. 체험판을 시작하려면 HashiCorp 영업 담당자에게 문의하세요.

FIPS 140-3 Vault Enterprise 사용하기

FIPS 140-3 Inside 버전의 Vault Enterprise는 비-FIPS 버전과 동일하게 동작합니다. 알고리즘에 제한이 없으며, Vault가 FIPS 준수 운영 모드를 유지하도록 하는 것은 운영자의 책임입니다. 즉 일부 시크릿 엔진이 제한된 알고리즘 집합만 허용하도록 구성해야 합니다(예: PKI 시크릿 엔진에서 ed25519 기반 CA를 금지).

Vault Enterprise는 시크릿을 평문으로 반환할 수 있으므로, Vault 서버의 리스너 구성 섹션이 TLS를 활용하는지 확인하는 것이 중요합니다. 이렇게 해야 시크릿이 서버에서 클라이언트로 안전하게 전송됩니다.

잠재적 컴플라이언스 문제의 비전체적인 목록은 다음과 같습니다.

  • Transit 시크릿 엔진에서 ChaCha20+Poly1305 키 사용
  • Transform 시크릿 엔진에서 FF3-1/FPE 사용
  • Agent 자동 인증 또는 Transit 시크릿 엔진에 파생 키(HKDF 사용) 사용
  • 엔트로피 보강 사용: BoringCrypto는 내부의 FIPS 140-3 승인 RNG를 사용하므로 다른 소스의 엔트로피와 혼합할 수 없습니다. FIPS 140-3 HSM 활성 바이너리에서 EA를 사용하려 하면 panic: boringcrypto: invalid code execution 같은 실패가 발생합니다.

HashiCorp는 Vault Enterprise를 FIPS 준수 방식으로 사용하는 것에 대한 일반 지침만 제공할 수 있습니다. HashiCorp는 NIST 인증 테스트 연구소가 아니므로, 최종 정보를 위해 조직은 승인된 감사자와 상담해야 할 수 있습니다.

FIPS 140-3 변형 Vault는 별도 바이너리를 사용하며 다음 소스에서 얻을 수 있습니다.

  • HashiCorp Releases 페이지에서 +ent.fips1403 및 +ent.hsm.fips1403 접미사로 끝나는 것
  • Docker Hub의 hashicorp/vault-enterprise-fips 컨테이너 레포지토리
  • AWS ECR의 hashicorp/vault-enterprise-fips 컨테이너 레포지토리
  • Red Hat Access의 hashicorp/vault-enterprise-fips 컨테이너 레포지토리

참고: FIPS UBI 기반 이미지를 가져올 때, 이것들은 궁극적으로 OpenShift 인증을 위해 설계되었습니다. 환경에 맞게 Vault가 mlock을 활성화할 수 있도록 --user root --cap-add IPC_LOCK 옵션을 추가하거나, mlock을 완전히 비활성화하는 --env SKIP_SETCAP=1 옵션을 사용하는 것을 고려하세요.

사용 제한

마이그레이션 제한

HashiCorp는 버전과 관계없이 비-FIPS Inside 버전의 Vault에서 FIPS Inside 버전으로의 제자리(in-place) 마이그레이션을 지원하지 않습니다. 지원을 받으려면 새 클러스터 설치가 필요합니다. 직접 업그레이드와 복제 기반 마이그레이션을 피하는 것을 일반적으로 권장합니다. 이유는 다음과 같습니다.

  • 이전 항목은 덮어쓸 때까지 이전 배리어 키로 암호화된 채 남아 있는데, 이 배리어 키는 FIPS 라이브러리로 생성되지 않았을 가능성이 높아 준수하지 않습니다.
  • 많은 시크릿 엔진이 내부적으로 키를 생성합니다. Transit 같은 것은 키를 생성·저장하지만 (Vault 내부에) 데이터를 저장하지 않는 것들로, 여전히 접근 가능해야 하고 새 FIPS 준수 키로 교체(rotation)되어야 합니다. PKI 엔진도 비준수 키를 생성했을 수 있는데, 예를 들어 Root CA 교체는 Vault 외부의 조직적 노력이 필요한 작업이라 신중하게 수행해야 합니다.

따라서 HashiCorp는 기존 클러스터 워크로드를 FIPS 140-3 Inside 바이너리로 전환하면서 발생하는 기술적 또는 비준수 영향이 있는 워크로드에 대해 지원을 제공할 수 없습니다.

대신 기존 클러스터를 그대로 두고, 특정 워크로드를 FIPS 기반 클러스터로의 마이그레이션을 신중히 고려하길 권장합니다.

엔트로피 보강 제한

엔트로피 보강은 FIPS 140-3 Inside에서 동작하지 않습니다. 내부 BoringCrypto RNG는 FIPS 140-3 인증을 받았으며 다른 소스의 엔트로피를 받아들이지 않습니다. Vault 1.11.0 이상에서는 엔트로피 보강을 사용하려 하면 경고("Entropy Augmentation is not supported...")가 발생하고 엔트로피 보강이 비활성화됩니다.

TLS 제한

Vault Enterprise의 FIPS 수정은 지원되는 TLS 암호 스위트와 키 정보에 대한 제한을 포함합니다. TLS 1.2 이하에서 다음 암호 스위트만 허용됩니다.

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384

또한 TLS 신뢰 체인에서 다음 키 유형만 허용됩니다.

  • RSA 2048, 3072, 4096, 7680, 8192비트
  • ECDSA P-256, P-384, P-521

이기종 클러스터 배포

HashiCorp는 같은 Vault 클러스터 내에서 혼합 배포 시나리오(FIPS와 비-FIPS Vault 바이너리 버전 혼합, FIPS Inside와 FIPS Seal Wrap 클러스터 혼합 등)를 지원하지 않습니다. 클러스터 노드는 전체 클러스터에 걸쳐 단일 바이너리/배포 유형이어야 합니다. FIPS Inside 바이너리와 함께 Seal Wrap을 사용하는 것은 허용됩니다.

시스템의 일부 구성 요소가 FIPS를 준수하지 않으므로 이기종 클러스터 실행은 FIPS에서 허용되지 않습니다.

기술 세부사항

Vault Enterprise의 FIPS 140-3 Inside 바이너리는 FIPS 검증 BoringCrypto 버전을 포함한 특별한 버전의 Go 툴체인에 의존합니다. Vault Enterprise 버전에 FIPS 지원이 포함되어 있는지 확인하려면, 서버 시작 후 Fips: Enabled 줄이 보이는지 확인하세요.

                    Fips: FIPS 140-3 Enabled, BoringCrypto version 7

참고: FIPS 140-3 Inside 바이너리는 cgo에 의존하므로 Vault를 실행하려면 GNU C Library(glibc) Linux 배포판이 필요합니다. 또한 현재 AMD64 아키텍처에서만 인증하기로 결정했습니다. 즉 이 바이너리는 Alpine Linux 기반 컨테이너에서는 동작하지 않습니다.

FIPS 140-3 Inside와 외부 플러그인

Vault Enterprise의 내장 플러그인은 핵심 Vault를 컴파일한 것과 같은 Go 툴체인 버전으로 Vault 바이너리에 컴파일되므로, 이 플러그인들도 FIPS 140-3 준수 상태를 갖습니다. 이 동일한 보장은 외부 플러그인에는 적용되지 않습니다.

FIPS 140-3 Inside 검증

FIPS 140-3 Inside 바이너리가 BoringCrypto를 올바르게 포함하는지 검증하려면 바이너리에서 go tool nm을 실행해 심볼 덤프를 얻으세요. 비-FIPS 빌드에서는 출력에서 goboringcrypto를 검색해도 결과가 없지만, FIPS 활성 빌드에서는 다음과 같은 많은 결과가 보입니다.

$ go tool nm vault | grep -i goboringcrypto
  4014d0 T _cgo_6880f0fbb71e_Cfunc__goboringcrypto_AES_cbc_encrypt
  4014f0 T _cgo_6880f0fbb71e_Cfunc__goboringcrypto_AES_ctr128_encrypt
  401520 T _cgo_6880f0fbb71e_Cfunc__goboringcrypto_AES_decrypt
  401540 T _cgo_6880f0fbb71e_Cfunc__goboringcrypto_AES_encrypt
  401560 T _cgo_6880f0fbb71e_Cfunc__goboringcrypto_AES_set_decrypt_key
...추가 줄 생략...

모든 FIPS 암호화 모듈은 시작 테스트를 실행해야 합니다. BoringCrypto는 이를 위해 _goboringcrypto_BORINGSSL_bcm_power_on_self_test 심볼을 사용합니다. Vault Enterprise 바이너리가 시작 테스트를 올바르게 실행하는지 확인하려면 GDB로 이 함수에서 실행을 중지해 실제로 도달하는지 확인하세요.

$ gdb --args vault server -dev
...GDB 시작 메시지 생략...
(gdb) break _goboringcrypto_BORINGSSL_bcm_power_on_self_test
...브레이크포인트 위치 생략...
(gdb) run
...추가 GDB 출력 생략...
Thread 1 "vault" hit Breakpoint 1, 0x0000000000454950 in _goboringcrypto_BORINGSSL_bcm_power_on_self_test ()
(gdb) backtrace
#0 0x0000000000454950 in _goboringcrypto_BORINGSSL_bcm_power_on_self_test ()
#1 0x00000000005da8f0 in runtime.asmcgocall () at /usr/local/hashicorp-fips-go-devel/src/runtime/asm_amd64.s:765
#2 0x00007fffd07a5a18 in ?? ()
#3 0x00007fffffffdf28 in ?? ()
#4 0x000000000057ebce in runtime.persistentalloc.func1 () at /usr/local/hashicorp-fips-go-devel/src/runtime/malloc.go:1371
#5 0x00000000005d8a49 in runtime.systemstack () at /usr/local/hashicorp-fips-go-devel/src/runtime/asm_amd64.s:383
#6 0x00000000005dd189 in runtime.newproc (siz=6129989, fn=0x5d88fb <runtime.rt0_go+315>) at <autogenerated>:1
#7 0x0000000000000000 in ?? ()

정확한 출력은 다를 수 있습니다.

참고: GDB 내에서 Vault Enterprise를 실행할 때 GDB는 지정된 브레이크포인트에서 중지할 수 있도록 바이너리의 일부를 재작성해야 합니다. 이로 인해 포함된 BoringCrypto 라이브러리의 HMAC이 변경되어 FIPS 무결성 검사가 깨집니다. 위 예시에서 continue 명령으로 실행을 계속하면 다음과 같은 메시지가 발생합니다.

Continuing.
FIPS integrity test failed.
Expected: 18d35ae031f649825a4269d68d2e62583d060a31d359690f97b9c8bf8120cdf75b405f74be7018094da7eb5261f2f86d0f481cc3b5a9c7c432268d94bf91aad9
Calculated: 111502a3201de3b23f54b29d79ca6a1a754f94ecfc57a379444aac0d3ada68bf3c06834e6d84e68599bdf763e28e2c994fcdaeac84adabd180b59cad5fc980bb
 
Thread 1 "vault" received signal SIGABRT, Aborted.

이것은 예상된 동작입니다. GDB 없이(또는 브레이크포인트를 설정하지 않고 — 예: delete 1) Vault를 다시 실행하면 이 함수는 여전히 실행되지만 FIPS 무결성 검사가 성공합니다.

BoringCrypto 인증

BoringCrypto Version 7은 다음 FIPS 140-3 인증서와 소프트웨어 버전을 사용합니다.

  • NIST CMVP 인증서 #4735
  • BoringCrypto 소프트웨어 버전 2022061300

Leidos 준수

Leidos는 Vault가 FIPS 140-2 버전의 BoringCrypto 준수를 평가했습니다. HashiCorp는 가까운 시일 내에 FIPS 140-3에 대한 평가를 추구할 예정입니다. 그동안 Vault는 FIPS 140-2 평가 이후 BoringCrypto와의 통합을 수정하지 않았습니다(이제 표준에서 허용되는 TLS 1.3 활성화를 제외하고). BoringCrypto 자체는 대부분 변하지 않았으며 FIPS 140-3 검증 인증을 받았습니다.

Seal Wrap FIPS 140 준수와 FIPS Inside 준수의 차이

  • Seal Wrapping을 사용할 때는 민감 항목의 저장(seal wrapped 항목)만 FIPS 검증 암호화로 다룹니다.
  • Seal Wrapping을 사용할 때 클라이언트가 Vault에 연결하는 TLS는 FIPS 검증 암호화로 다루지 않습니다(FIPS 140-2 Inside에서는 갱신된 인증서의 항목 1, 2, 7, 13에 따라 다룹니다).
  • Seal Wrap 버전에서는 키 자료 생성이 FIPS 검증 암호화를 사용하지 않았습니다(예: PKI 인증서 — 갱신된 FIPS 140-2 Inside 인증서 항목 8; 또는 SSH 모듈 — 항목 10).
  • Seal Wrapping을 사용하면 일부 항목은 FIPS 검증 암호화로 보호되지만 Vault의 모든 암호화가 FIPS 인증된 것은 아닙니다. FIPS 140-2 Inside에서는 기본적으로(알고리즘이 인증된 경우) Vault가 인증된 암호화 구현을 사용합니다.

더 알아보기 (Learn more)