pki

오리진에 대한 양자 이후 인증이 이제 지원됩니다 (새 탭에서 열림)

Cloudflare는 Cloudflare와 고객의 원본 서버 사이 연결에 ML-DSA 기반의 포스트퀀텀(PQ) 인증을 지원하기 시작했다. 이제 Custom Origin Trust Store와 Authenticated Origin Pulls를 조합하면 원본 서버 연결을 암호화할 뿐 아니라 양쪽을 포스트퀀텀 방식으로 인증하는 mTLS 구성이 가능하다. 이는 Cloudflare가 2029년까지 완전한 포스트퀀텀 보안을 달성하기 위해 세운 로드맵의 첫 번째 주요 milestone이다. ## 포스트퀀텀 인증이 필요한 이유 - 기존에는 양자컴퓨터가 현재의 암호화를 미래에 해독하는 ‘수집 후 해독(harvest-now/decrypt-later)’ 공격에 대비해 포스트퀀텀 암호화를 우선 배포했다. - 최근 양자컴퓨팅과 암호해석 기술의 발전으로, 공격자가 고전적 인증서를 위조해 서버나 클라이언트를 사칭하는 위험에도 대비해야 하게 됐다. - Cloudflare는 다음 연결에 대해 이미 포스트퀀텀 암호화를 지원하고 있다. - 방문자와 Cloudflare 간 연결: 2022년 지원 - Cloudflare와 원본 서버 간 연결: 2023년 지원 - 이번 변경은 여기에 포스트퀀텀 인증을 추가한 것이다. ## Cloudflare-원본 서버 연결의 특성 - 웹사이트 요청에는 일반적으로 두 개의 TLS 연결이 사용된다. - 방문자 → Cloudflare - Cloudflare → 고객 원본 서버 - Cloudflare-원본 서버 연결에서는 Cloudflare가 TLS 클라이언트 역할을 하므로 인증 방식을 직접 통제할 수 있다. - Cloudflare는 여러 요청을 적은 수의 연결로 묶는 connection pooling을 사용해 PQ 서명에 따른 연결 설정 비용을 분산할 수 있다. - 고객과 이미 Cloudflare 계정 기반의 신뢰 관계가 있으므로, 공개 웹 PKI의 제약 없이 용도에 맞는 사설 PKI를 사용할 수 있다. - 중간 인증서 체인과 Certificate Transparency가 필요하지 않을 수 있다. - 공개 웹의 인증서 생태계보다 빠르게 ML-DSA 인증을 배포할 수 있다. - 방문자-Cloudflare 연결에서는 향후 Merkle Tree Certificates(MTC)를 활용할 계획이며, 초기 배포 목표는 2027년이다. ## 지원되는 ML-DSA 구성 - Cloudflare는 FIPS 204의 세 가지 ML-DSA 파라미터 세트를 지원한다. - ML-DSA-44 - ML-DSA-65 - ML-DSA-87 - 대부분의 애플리케이션에는 성능이 가장 우수하고 NIST 보안 강도 카테고리 2를 제공하는 ML-DSA-44가 권장된다. ## Custom Origin Trust Store를 이용한 원본 인증 - Full (strict) SSL 모드에서 Cloudflare는 원본 서버의 인증서를 신뢰 저장소와 대조한다. - 기본적으로 일반적으로 신뢰되는 CA와 Cloudflare Origin CA가 사용된다. - Custom Origin Trust Store(COTS)를 사용하면 고객이 관리하는 CA 목록으로 기본 신뢰 저장소를 대체할 수 있다. - 이제 ML-DSA CA를 업로드할 수 있으며, Cloudflare는 해당 CA로부터 발급된 원본 서버 인증서만 신뢰하도록 구성할 수 있다. - COTS 사용에는 Advanced Certificate Manager가 필요하다. ## Authenticated Origin Pulls를 이용한 상호 인증 - Authenticated Origin Pulls(AOP)는 원본 서버가 Cloudflare에서 온 요청만 처리하도록 제한하는 기능이다. - Cloudflare가 클라이언트 인증서를 제시하므로 원본 서버는 요청 주체가 Cloudflare인지 검증할 수 있다. - 이를 통해 Cloudflare와 원본 서버 간 상호 TLS(mTLS)를 구성할 수 있다. - AOP는 모든 Cloudflare 요금제에서 무료로 제공된다. - 영역(zone)별 및 호스트명별 설정에서 다음을 업로드할 수 있다. - ML-DSA 인증서 - ML-DSA 개인 키 - 개인 키는 현재 FIPS 204 seed 형식으로만 업로드할 수 있다. - 전역(global) 설정의 ML-DSA 지원은 아직 제공되지 않으며 추후 작업으로 예정되어 있다. ## 다운그레이드 공격 방지 - 양쪽이 PQ 인증을 지원하는 것만으로는 완전한 포스트퀀텀 보안이 보장되지 않는다. - 원본 서버가 기존의 양자 취약 인증 방식도 계속 신뢰하면, 공격자가 고전적 인증서를 위조해 연결을 다운그레이드할 수 있다. - 따라서 인증서를 검증하는 원본 서버는 양자 취약한 인증 메커니즘에 대한 신뢰를 제거해야 한다. - 복잡한 PKI에서는 인증 체계 전환 단계와 신뢰 설정을 별도로 설계해야 한다. ## 구성에 필요한 도구와 절차 - 인증서 생성에는 OpenSSL 3.5.0 이상이 필요하다. - Cloudflare가 현재 허용하는 개인 키 형식은 FIPS 204의 seed-only 인코딩이다. - 일반적인 구성 절차는 다음과 같다. - ML-DSA-44 등의 알고리즘으로 원본 서버용 CA와 인증서 체인을 생성한다. - 생성한 CA를 COTS에 업로드한다. - ML-DSA 클라이언트 인증서와 개인 키를 AOP의 영역별 또는 호스트명별 설정에 업로드한다. - Cloudflare API 또는 대시보드를 통해 원본 서버의 mTLS 및 인증서 검증을 활성화한다. - 원본 서버에서 양자 취약 인증서와 인증 기관을 신뢰하지 않도록 설정한다. ## 실용적인 권장 사항 대부분의 사용자는 ML-DSA-44를 사용해 COTS와 AOP를 함께 구성하는 것이 적절하다. 단순히 ML-DSA 인증서를 추가하는 데 그치지 말고, 원본 서버의 신뢰 저장소에서 기존 양자 취약 인증 방식을 제거해야 다운그레이드 공격까지 방어할 수 있다.

AWS Certificate Manager에서 ACME 지원으로 퍼블릭 TLS 인증서 발급 자동화 | Amazon Web Services (새 탭에서 열림)

AWS Certificate Manager(ACM)가 ACMEv2를 지원하면서 Certbot, cert-manager, acme.sh 등 기존 ACME 클라이언트로 Amazon Trust Services의 공인 TLS 인증서를 자동 발급·갱신할 수 있게 됐다. 인증서 수명이 2027년 100일, 2029년 47일까지 단축될 예정인 상황에서 수동 갱신의 운영 부담을 줄이고, 조직 차원의 인증서 발급·권한·감사를 ACM에서 통합 관리할 수 있다는 것이 글의 핵심이다. ## 인증서 자동화가 필요한 이유 - TLS 인증서는 만료 시 고객의 접속 오류와 서비스 중단을 일으킬 수 있다. - CA/Browser Forum 정책에 따라 최대 인증서 유효기간이: - 2027년 3월부터 100일 - 2029년부터 47일 로 단축될 예정이다. - 수동 발급과 갱신만으로는 짧아지는 인증서 주기를 안정적으로 관리하기 어렵다. - ACME는 인증서 발급, 갱신, 폐기를 자동화하는 표준 프로토콜이며 Let’s Encrypt를 비롯한 다양한 클라이언트가 지원한다. ## ACM의 ACME 지원 - ACM이 완전 관리형 ACME 서버 엔드포인트를 제공한다. - ACMEv2 호환 클라이언트를 사용해 공인 TLS 인증서를 발급할 수 있다. - Certbot - Kubernetes cert-manager - acme.sh - 기타 ACMEv2 클라이언트 - 인증서는 Amazon Trust Services에서 발급되며, 일반적인 브라우저와 운영체제에서 기본적으로 신뢰된다. - 기존에는 외부 CA와 ACM을 함께 사용해야 해 인증서 현황과 관리가 분산됐지만, 이제 ACM에서 ACME 발급 인증서까지 검색하고 관리할 수 있다. ## 중앙 집중식 권한 및 정책 관리 - PKI 관리자는 하나 이상의 ACME 엔드포인트를 만들어 조직의 인증서 사용을 중앙 관리할 수 있다. - IAM 역할과 ACME 계정을 연결해 클라이언트별 요청 권한을 세밀하게 제어할 수 있다. - 엔드포인트 수준에서 허용 도메인과 인증서 범위를 지정할 수 있다. - 도메인별로 다음 발급 범위를 선택할 수 있다. - Exact domain: 지정한 도메인만 허용 - Subdomains: `api.example.com` 같은 하위 도메인 허용 - Wildcards: `*.example.com` 같은 와일드카드 인증서 허용 - 와일드카드 발급을 제한하는 등 조직의 보안 정책을 일관되게 적용할 수 있다. - ECDSA와 RSA 등 허용할 키 유형도 중앙에서 제한할 수 있다. ## 도메인 검증과 역할 분리 - 도메인 검증은 엔드포인트 생성 시 PKI 관리자가 한 번 수행한다. - DNS 자격 증명은 관리자에게만 유지되며, 애플리케이션 소유자에게 배포할 필요가 없다. - 애플리케이션 소유자는 EAB 자격 증명으로 ACME 계정을 등록하고, 허용된 도메인 범위 안에서만 인증서를 요청한다. - Route 53을 사용하는 경우 ACM이 DNS 검증용 CNAME 레코드를 자동 생성한다. - 외부 DNS 제공업체를 사용하면 ACM이 제공하는 CNAME 레코드를 관리자가 직접 추가해야 한다. - 이 구조는 각 ACME 클라이언트가 개별적으로 DNS 검증을 수행하는 일반적인 구성보다 DNS 키 배포 위험을 줄인다. ## ACME 엔드포인트 설정 절차 - ACM 콘솔의 ACME certificates 페이지에서 `Create ACME endpoint`를 선택한다. - 엔드포인트 유형을 Public으로 설정한다. - 인증서 유형을 Public으로 설정한다. - 인증서 키 유형을 선택한다. - 기본값: ECDSA P-256 - 선택 가능: RSA 2048, ECDSA P-384 - 발급을 허용할 도메인과 도메인 스코프를 설정한다. - Route 53 Hosted Zone을 선택하거나 DNS 제공업체에 검증용 CNAME을 직접 등록한다. - DNS 검증 상태가 `Success`로 바뀌면 엔드포인트를 사용할 수 있다. ## External Account Binding(EAB) - EAB는 ACME 클라이언트가 ACM의 ACME 서버에 계정을 등록할 때 사용하는 인증 수단이다. - 다음 두 값으로 구성된다. - Key ID - HMAC Key - ACM 콘솔의 엔드포인트 상세 화면에서 EAB 자격 증명을 생성한다. - 생성한 EAB 자격 증명은 필요한 기간만큼만 유효하도록 만료 시간을 설정하는 것이 권장된다. - ACME 클라이언트가 EAB로 초기 계정을 등록하면, 이후에는 클라이언트가 생성한 비대칭 키 쌍으로 인증서 요청을 인증한다. - EAB 값은 클라이언트 설정에 필요하므로 안전하게 보관해야 한다. ## Certbot을 이용한 인증서 발급 - ACM 콘솔은 Certbot과 acme.sh용 CLI 예제를 제공한다. - Certbot은 다음과 같은 방식으로 실행할 수 있다. ```bash certbot certonly --standalone --non-interactive --agree-tos \ --email <EMAIL> \ --server https://acm-acme-enroll.us-east-1.api.aws/<ENDPOINT_ID>/directory \ --eab-kid <EAB_KID> \ --eab-hmac-key <EAB_HMAC_KEY> \ --issuance-timeout <ISSUANCE_TIMEOUT> \ -d <DOMAIN> ``` - `--server`에는 ACM ACME 엔드포인트 URL을 지정한다. - `--eab-kid`와 `--eab-hmac-key`에는 ACM에서 생성한 EAB 값을 입력한다. - `-d`로 발급 대상 도메인을 지정한다. - 클라이언트마다 EAB 설정 방식과 명령어 문법이 다를 수 있으므로 사용 중인 ACME 클라이언트의 문서를 확인해야 한다. ## 감사, 모니터링 및 만료 알림 - AWS CloudTrail이 ACME 인증서 요청을 기록해 감사 추적을 지원한다. - Amazon CloudWatch로 운영 지표를 모니터링할 수 있다. - ACM은 인증서 만료가 임박하면 알림을 보낸다. - 콘솔, API, ACME를 통해 발급된 인증서를 ACM에서 통합 검색할 수 있다. - 별도 인증서 라이프사이클 관리 제품이나 자체 정책 시스템을 구축하지 않고도 중앙 통제와 가시성을 확보할 수 있다. ## 실용적인 결론 조직에서 여러 서비스와 Kubernetes 클러스터의 인증서를 자동 관리해야 한다면 ACM ACME 엔드포인트를 활용하는 것이 유용하다. 특히 DNS 자격 증명은 PKI 관리자에게만 보관하고, 애플리케이션별로 제한된 도메인 스코프와 짧은 만료 기간의 EAB 자격 증명을 발급해 최소 권한 원칙을 적용하는 것이 권장된다.