Keyfactor EJBCA 참조 아키텍처

개요

이 참조 아키텍처는 Google Distributed Cloud (GDC) 에어 갭에서 서드 파티 인증 기관 (CA)으로 Keyfactor EJBCA Enterprise 를 통합하기 위한 개념 설계를 정의합니다.

Keyfactor EJBCA Enterprise는 조직이 이기종 환경에서 공개 키 인프라 (PKI)를 관리할 수 있도록 하는 확장성이 높고 강력하며 FIPS를 준수하는 인증 기관 플랫폼입니다.

GDC 에어 갭에는 호스팅된 클라우드 경계 내에서 자동화된 키 및 인증서 관리를 위한 기본 인증 기관 서비스 가 포함되어 있습니다. 기본 CA 서비스는 대부분의 고객에게 권장되는 솔루션으로, 플랫폼 내에서 완전 관리형의 원활한 PKI 기능을 제공합니다. 그러나 GDC 외부의 기존 워크로드에 대해 Keyfactor EJBCA에서 PKI 인프라를 표준화한 조직은 GDC 환경 내에서 실행되는 워크로드에 대해 동일한 일관된 CA 아키텍처 및 관리 정책을 활용하는 것을 선호할 수 있습니다.

특징 및 기능

이 솔루션은 인증서 수명 주기 관리를 위한 여러 가지 핵심 기능 구성요소를 제공합니다.

  • 자동화된 인증서 수명 주기 관리: GDC 표준 클러스터 내에서 커스텀 EJBCA 발급기관을 활용하여 cert-manager를 통해 서버 인증서의 프로비저닝, 갱신, 취소를 자동화합니다.
  • 표준화된 ACME 자동화: DNS-01 챌린지를 사용하여 자동 인증서 관리 환경 (ACME) 프로토콜을 지원하므로 플랫폼 서비스에서 인증서를 원활하게 요청하고 갱신할 수 있습니다.
  • 보안 HSM 통합: CC EAL4+ 인증 하드웨어 보안 모듈 (HSM) 내에서 모든 CA 비공개 키를 직접 암호화하여, 키 자료가 물리적 보안 경계를 벗어나지 않도록 보장합니다. Keyfactor EJBCA Enterprise는 자체 관리형 HSM을 사용하거나 외부 HSM에 연결할 수 있습니다.
  • 에어 갭 호환성: 공개 레지스트리에서 GDC 비공개 Harbor 레지스트리로 EJBCA cert-manager 발급기관 이미지를 미러링하는 특수 워크플로를 통해 오프라인 가용성을 보장합니다.
  • 이그레스 트래픽 격리: GDC 서브넷 및 CloudNATGateway 리소스를 사용하여 아웃바운드 네트워크를 구성하여 GDC API 트래픽을 외부 EJBCA 서버 IP 주소로 직접 제한합니다.

아키텍처 원칙

  • 공유 책임 모델: 고객은 외부 EJBCA 서버 및 HSM을 운영하고 물리적 PKI 인프라 및 CA 루트 키를 소유하며 GDC는 표준 클러스터 내에서 컴퓨팅, 내부 DNS, 자동화된 클라이언트 계층을 제공합니다.
  • 보안 중심 설계: 로컬 컨테이너 이미지 미러를 활용하고 엄격한 이그레스 게이팅을 적용하여 네트워크 공격 노출 영역을 최소화함으로써 에어 갭 보안 요구사항을 준수합니다.
  • 프로토콜 표준화: CA 상호작용을 위한 표준 프로토콜 (ACME 및 mTLS REST)을 우선시하여 독점 API 종속성을 방지하고 유연한 클라이언트 통합을 허용합니다.

아키텍처

이 아키텍처는 EJBCA 서버와 지원 하드웨어 보안 모듈 (HSM)이 물리적 GDC 경계 외부에서 호스팅되지만 네트워크를 통해 액세스할 수 있는 외부 인증 기관 모델을 따릅니다. EJBCA 서버는 하드웨어 또는 소프트웨어 어플라이언스로 외부에서 배포할 수 있습니다. 이 가이드에 설명된 핵심 통합에는 외부 EJBCA 서버가 안정적인 IP 주소를 통해 연결될 수 있어야 합니다.

Keyfactor EJBCA 아키텍처 다이어그램

이 아키텍처의 주요 구성요소는 다음과 같습니다.

  • EJBCA Enterprise 서버: Keyfactor 하드웨어 어플라이언스 또는 소프트웨어 어플라이언스로 외부에서 배포되며 CA (루트 및 하위)를 호스팅하고 CC EAL4+ 인증 HSM 내에서 모든 CA 키 자료를 생성합니다.
  • 기본 VPC: 표준 Kubernetes 클러스터 또는 가상 머신에 사용자 워크로드가 배포되는 VPC입니다.
  • GDC 내부 DNS: 환경 변수에 구성된 비공개 도메인 이름을 사용하여 ACME DNS-01 챌린지를 확인하는 데 사용되는 로컬 비공개 DNS 영역을 관리합니다.
  • GDC 이그레스 NAT 게이트웨이: 클러스터 포드에서 외부 EJBCA 서버 IP 주소로 아웃바운드 트래픽을 전달합니다.
  • Harbor 비공개 레지스트리: 에어 갭 배포를 위해 미러링된 컨테이너 이미지 (예: EJBCA cert-manager 발급기관)를 호스팅합니다.

개념 및 기술

이 섹션에서는 기능 구성요소, 책임, 시스템 내에서 통신하는 방법을 자세히 설명합니다.

인프라 및 플랫폼

  • GDC 표준 클러스터: EJBCA 발급기관 및 cert-manager 포드가 상주하고 워크로드에 대한 인증서 자동화를 실행하는 기본 컴퓨팅 환경입니다.
  • Harbor 레지스트리: GDC의 모든 컨테이너 이미지에 대한 안전한 로컬 정보 출처입니다. 배포 전에 이미지가 알려진 취약점이 없는지 확인하기 위해 자동 스캔을 제공합니다.
  • GDC 이그레스 게이트웨이: 클러스터 포드에서 외부 CA 서버로의 아웃바운드 API 트래픽을 관리하고 보호하는 플랫폼 기본 네트워킹 리소스 (서브넷 및 CloudNATGateway)입니다.

서비스 및 로직

  • EJBCA Enterprise 서버: CA 계층 구조 (루트 및 하위)를 관리하고, 인증서 요청을 검증하고, 인증서에 서명하고, 감사 기록을 로깅하는 외부 CA 엔진 (소프트웨어 또는 하드웨어 어플라이언스)입니다.
  • 하드웨어 보안 모듈 (HSM): 키 생성 및 인증서 서명을 처리하여 CA 비공개 키가 노출되지 않도록 보장하는 CC EAL4+ 규정 준수 암호화 모듈입니다.
  • GDC 내부 DNS: ACME 챌린지 검증 서비스에서 임시 TXT 레코드를 통해 도메인 소유권을 확인하는 데 사용하는 비공개 DNS 영역 (ManagedDNSZone 및 ResourceRecordSet)을 관리합니다.
  • EJBCA 발급기관이 있는 cert-manager: 인증서 요청을 가로채고 EJBCA 발급기관을 활용하여 이를 보안 EJBCA API 호출로 변환하는 Kubernetes 기본 인증서 컨트롤러입니다.

데이터 흐름 및 인터페이스

  • ACME 프로토콜: DNS-01 챌린지를 사용하여 도메인 검증 서버 인증서 발급을 자동화하기 위한 표준 API 인터페이스입니다.
  • EJBCA REST API: 관리 부트스트랩 및 프로그래매틱 작업 (예: CSR 서명 및 취소)에 사용되는 RESTful 인터페이스입니다.
  • mTLS 클라이언트 인증: cert-manager 통합의 기본 인증 메커니즘으로, 전용 클라이언트 인증서를 사용하여 상호 TLS를 통해 클라이언트 ID를 확인합니다.

고려사항

  • 확장성 및 성능:
    • 특히 버스트 발급 프로필 중에 동시 검증 및 서명 요청을 처리하려면 외부 EJBCA 서버를 확장해야 합니다 (CPU, 메모리, HSM 용량).
    • cert-manager 검증 주기 중에 시간 초과를 방지하려면 외부 CA 서버에 대한 지연 시간을 최소화하도록 GDC 이그레스 게이트웨이 리소스의 크기를 조정해야 합니다.
  • 보안 및 규정 준수:
    • 외부 HSM 내에서 CA 루트 키를 격리하면 높은 보안 및 규정 준수 표준 (예: BSI VS-NfD)을 충족합니다.
    • EJBCA에 대한 관리 액세스는 역할 기반 액세스 제어 (RBAC)를 사용하여 엄격하게 제한되고 고유한 클라이언트 인증서 일련번호에 매핑되어야 합니다.
  • 가용성 및 안정성:
    • 연속적인 운영을 보장하고 단일 장애 지점을 방지하려면 여러 가용성 영역에 걸쳐 외부 EJBCA 서버를 고가용성으로 배포하는 것이 좋습니다 (활성-대기 또는 클러스터링된 구성 사용).
    • GDC 내에서 여러 cert-manager 컨트롤러 복제본을 배포하면 클러스터 측 자동 인증서 발급이 복원력을 유지합니다.
  • 운영 관리:
    • 고객은 시스템 패치, HSM 키 순환, CRL 게시를 비롯한 EJBCA 서버의 소유권을 유지합니다.
    • 고객의 GDC 플랫폼 관리자는 클러스터 내 cert-manager 및 EJBCA 발급기관 컨트롤러를 유지하고 GDC 측 비공개 DNS 레코드를 관리할 책임이 있습니다.

설계 결정

이 솔루션의 기본 아키텍처 선택은 자동화와 에어 갭 환경의 제약조건 간의 균형을 맞추는 데 중점을 둡니다.

EJBCA 통합 옵션

GDC의 기본 인증 기관 서비스는 대부분의 고객에게 권장되는 PKI 솔루션으로, GDC 에어 갭 환경 내에서 완전 관리형의 원활한 PKI 기능을 제공합니다. 그러나 GDC 외부의 워크로드에 대해 Keyfactor EJBCA에서 PKI 인프라를 이미 표준화한 조직의 경우 기존 외부 CA 서버를 통합하는 것이 선택 옵션으로 제공됩니다. 이를 통해 신뢰 계층 구조를 재설계하거나 핵심 워크플로를 마이그레이션하지 않고도 설정된 PKI 템플릿, 보안 정책, 운영 모델을 재사용할 수 있습니다.

ACME 챌린지 검증 옵션

HTTP-01 및 DNS-01 ACME 챌린지 검증 프로토콜이 모두 완전히 지원됩니다. 이 아키텍처 가이드에서는 인바운드 공개 HTTP 트래픽을 지원할 수 없는 격리된 비공개 환경에 적합한 GDC의 내부 DNS를 사용하는 DNS-01 챌린지를 중점적으로 설명하지만 고객은 특정 네트워크 토폴로지, 보안 정책, 워크로드 요구사항에 따라 검증 방법을 선택할 수 있습니다.

mTLS 관리 채널 권장사항

상호 TLS (mTLS)를 cert-manager 및 통합 클라이언트를 위한 강력한 인증 방법으로 사용하는 것이 좋습니다. mTLS는 클라이언트 인증서를 활용하여 클라이언트 ID의 암호화된 보안 검증을 제공하지만 고객은 회사 보안 정책에 따라 EJBCA 인스턴스에서 지원하는 다른 인증 메커니즘을 구성하도록 선택할 수 있습니다.

가정 및 제한사항

가정

  • 외부 EJBCA 서버가 배포, 구성되고 안정적인 IP 주소를 통해 연결될 수 있습니다.
  • EJBCA 서버는 적절한 최종 항목 프로필과 함께 필요한 루트 및 하위 CA로 사전 구성됩니다.
  • EJBCA 발급기관 컨테이너 이미지를 GDC Harbor 레지스트리에 게시하는 데 사용할 수 있는 보안 메커니즘 (예: 배스천 노드 또는 오프라인 전송 워크플로)이 있습니다.
  • GDC 내부의 표준 Kubernetes 클러스터에는 cert-manager가 사전 설치되어 있거나 작동하도록 구성되어 있습니다.

제한사항

  • 외부 HSM 및 EJBCA 유지보수: GDC 제어 영역은 외부 EJBCA 서버 또는 지원 HSM을 관리하지 않습니다. 수명 주기 작업 (백업, 업그레이드, 키 순환)은 고객의 PKI 운영팀에서 처리합니다.
  • DNSSEC 검증 제약조건: 비공개 내부 DNS가 사용되므로 로컬 비공개 도메인의 확인 실패를 방지하려면 ACME 구성에서 DNSSEC 검증을 서버 측에서 사용 중지해야 합니다.
  • 이그레스 연결 종속성: 자동 인증서 발급 서비스는 GDC 랙과 외부 EJBCA 서버 간의 네트워크 링크 의 가용성 및 지연 시간에 따라 달라집니다.