IBM Vault PKI로 사내 TLS 인증서 관리하기: 발급·교체·적용 확인 가이드

사내 포털·내부 API·서버 간 TLS 통신의 인증서를 관리하는 IT 담당자께

인증서 관리의 완료 기준은 ‘새 파일을 받았다’가 아니라 ‘실제 서비스가 올바른 새 인증서로 연결된다’입니다. IBM HashiCorp Vault(이하 IBM Vault)의 PKI를 활용하면 발급 기준을 관리하고 서비스의 인증서 교체 흐름을 구성할 수 있습니다. 이 글은 사내 TLS 인증서 관리를 검토할 때 필요한 범위와 확인 항목을 정리합니다.

만료일 알림만으로 해결하기 어려운 이유

인증서가 늘면 발급기관·개인키 보관 위치·배포 대상·적용 담당자가 흩어질 수 있습니다. 파일은 교체했지만 웹서버가 예전 인증서를 계속 사용하거나, 여러 서버 중 일부만 바뀌는 상황도 시험에서 확인할 항목입니다. 따라서 만료일 목록과 함께 발급부터 실제 접속까지 이어지는 절차가 필요합니다.

Vault PKI가 맡는 일과 연결해야 할 일

PKI는 인증기관(CA)을 중심으로 인증서의 발급과 신뢰를 다루는 체계입니다. Vault PKI secrets engine은 인증·권한을 확인해 X.509 인증서를 발급합니다. 보통 조직의 CA 체계에서 루트 CA와 중간 CA의 역할을 나누며, 기존 CA와 어떻게 연결할지 먼저 결정합니다.

근거: HashiCorp 공식 문서 [1] · HashiCorp 공식 문서 [7]

위 표는 도입 검토용 업무 구분입니다. Vault 설치만으로 모든 서버의 배포·신뢰 설정·알림까지 완성된다는 의미는 아닙니다.

1. 요청자 권한과 인증서의 발급 범위를 함께 제한합니다

Vault에 접근하는 주체의 인증과 경로 권한을 설정하고, PKI의 발급 역할(role)에는 허용 도메인·하위 도메인 허용 여부·최대 유효기간 등을 정합니다. “발급 API에 접근할 수 있음”과 “어떤 서비스 이름으로 발급할 수 있음”을 함께 점검해야 합니다.

허용 범위를 넓게 열어두는 대신 실제 필요한 서비스 이름과 용도를 기준으로 정리합니다. 인증서의 SAN은 접속하는 호스트 이름과 맞아야 하며, 발급용 CA의 만료일도 함께 관리해야 합니다.

근거: HashiCorp 공식 문서 [2] · HashiCorp 공식 문서 [3] · HashiCorp 공식 문서 [6]

2. 개인키를 어디에서 만들고 보관할지 정합니다

Vault가 키와 인증서를 생성해 반환하는 발급 방식과, 대상에서 키를 만들고 CSR(인증서 서명 요청)을 보내 서명받는 방식이 있습니다. 고객 환경에 맞는 방식을 선택하고, 개인키가 지나가는 경로·파일 권한·보관 대상을 확인해야 합니다. 개인키를 일반 공유 폴더나 작업 로그에 남기는 방식은 피해야 합니다.

근거: HashiCorp 공식 문서 [5]

3. 새 인증서 발급 뒤 실제 적용을 연결합니다

서버용 인증서를 갱신한다는 것은 새 인증서를 발급받아 기존 인증서를 교체하는 흐름입니다. Vault Agent의 pkiCert 템플릿 등으로 인증서를 받아 파일로 반영하고, 출력이 변경되면 적용 명령을 실행하도록 연동할 수 있습니다. 애플리케이션이 새 파일을 언제 읽는지에 따라 재로딩 또는 재시작 절차가 달라집니다.

교체 후에는 파일 날짜만 확인하지 말고, 실제 TLS 접속에서 제시되는 인증서의 일련번호·만료일·이름·체인을 확인하도록 시험을 설계합니다. 로드밸런서가 TLS를 종료하는 경우와 뒤쪽 서버가 TLS를 처리하는 경우도 나누어 봐야 합니다. 서버가 여러 대라면 적용 대상 전체의 확인 방법을 정합니다.

근거: HashiCorp 공식 문서 [4] · HashiCorp 공식 문서 [6]

4. 유효기간은 자동화·복구 능력과 함께 결정합니다

짧은 유효기간은 인증서가 유효한 기간을 줄이는 데 도움이 됩니다. 반면 발급이나 배포가 멈췄을 때 대응할 수 있는 시간도 고려해야 합니다. “일괄 하루”처럼 정하기보다 서비스 특성과 발급·교체 주기, 장애 감지·복구 시간을 함께 검토합니다.

서비스용 인증서의 교체와 루트·중간 CA의 교체는 같은 작업이 아닙니다. 특히 루트 CA를 바꾸면 클라이언트의 신뢰 전환을 별도로 계획해야 합니다. 또한 인증서 폐기는 서버의 파일 삭제와 다르며, CRL·OCSP 같은 폐기 상태 확인 경로와 이를 이용하는 클라이언트의 동작도 설계 대상입니다. 짧은 유효기간이 모든 폐기 대응을 대신하지는 않습니다.

근거: HashiCorp 공식 문서 [1] · HashiCorp 공식 문서 [3] · HashiCorp 공식 문서 [6]

작은 범위의 PoC에서 확인할 다섯 가지

이는 제안하는 검증 항목이며 실제 고객 시험 결과가 아닙니다. 무중단 전환 여부는 대상 애플리케이션과 구성에서 따로 검증해야 합니다.

자주 묻는 질문

사내 CA로 만들면 외부 고객 브라우저도 신뢰하나요?

자동으로 신뢰하지 않습니다. 관리하는 사내 기기의 신뢰 체계와 일반 인터넷 사용자의 신뢰 체계를 구분해야 합니다. 공개 서비스는 신뢰받는 공개 CA 등 목적에 맞는 발급 체계를 별도로 검토합니다.

Vault Agent만 설치하면 교체가 끝나나요?

인증·발급 권한, 템플릿, 파일 권한, 앱 적용 방법을 연결해야 합니다. 재로딩 명령이 성공해도 실제 서비스에서 새 인증서가 사용되는지 확인하는 절차까지 필요합니다.

사내 인증서 상담에 필요한 정보

대상 서비스와 서버 수, 웹서버·로드밸런서·컨테이너 등의 실행 환경, 현재 인증서 발급기관, 교체 시 재시작 가능 여부를 알려주세요. 케이엔피플이 반복되는 수작업과 Vault 적용 범위, 먼저 확인할 시험 항목을 함께 정리하겠습니다.

처음에는 서비스 한 곳의 발급·적용·접속 확인·실패 알림부터 범위를 정할 수 있습니다. 상담에 개인키·비밀번호·Vault 토큰을 보내실 필요는 없습니다.