API 백엔드 mTLS 체크리스트: 서비스 간 상호 인증과 인증서 운영
API 입구는 잠겼는데, 그 다음 호출은 누구를 믿고 있을까요?
API 보안 설계에서 클라이언트 인증은 익숙한 항목입니다. 하지만 요청이 게이트웨이를 통과한 뒤 백엔드 서비스로 향할 때도 ‘이 요청이 정말 우리 게이트웨이에서 왔는가’를 확인하고 있을까요?
AWS는 2026년 9월 Amazon API Gateway REST API가 백엔드 TLS 핸드셰이크에서 ACM 인증서를 제시하도록 해, 백엔드 연동에도 mTLS를 적용할 수 있다고 발표했습니다. 기존의 클라이언트-게이트웨이 구간뿐 아니라 게이트웨이-백엔드 구간까지 상호 인증 범위를 넓힐 수 있다는 뜻입니다. 이것은 특정 제품의 기능 소개보다 API 신뢰 경계를 다시 확인하게 하는 변화입니다.
mTLS는 암호화가 아니라 상대 확인까지 포함합니다
일반 TLS는 전송 내용을 보호하고 서버 신원을 확인합니다. mTLS는 여기에 클라이언트 인증서를 더해 양쪽이 서로의 신원을 확인합니다. API 호출 경로에서 이를 적용하면 백엔드는 단순히 ‘암호화된 요청’이 아니라, 승인한 주체가 제시한 인증서로 연결된 요청인지 확인할 수 있습니다.
다만 mTLS가 사용자 권한까지 대신하지는 않습니다. 인증서는 호출 주체의 신뢰를 확인하는 수단이고, 업무별 접근 권한·요청 범위·호출량 제한은 별도의 인증·인가와 정책으로 다뤄야 합니다. 따라서 인증서, 토큰, API Key, 네트워크 제어를 한 기능처럼 섞기보다 각 통제의 목적을 구분하는 것이 좋습니다.
인증서 수명주기가 설계의 절반입니다
인증서를 발급하는 순간보다 갱신하는 날에 장애가 나는 경우가 많습니다. 어느 CA를 신뢰할지, 비밀키를 어디에 보관할지, 만료 전 교체를 어떻게 검증할지, 폐기된 인증서를 어떻게 차단할지를 정하지 않으면 mTLS는 운영 부담으로 돌아올 수 있습니다.
AWS 발표에 따르면 ACM에서 인증서를 다시 가져오기 또는 갱신하면 API Gateway가 변경을 전파합니다. 그러나 자동 전파 여부와 무관하게 기업은 인증서 체인, 백엔드의 신뢰 저장소, 갱신 알림, 이전 인증서와 신규 인증서가 공존하는 기간을 각 환경에서 시험해야 합니다. ‘갱신 성공’뿐 아니라 잘못된 인증서와 만료된 인증서가 실제로 차단되는지도 확인해야 합니다.
도입 전에 네 가지를 점검하세요
어떤 호출 구간에 상호 인증이 필요한가? 외부 클라이언트, 파트너, 게이트웨이, 내부 서비스의 경계를 각각 목록화합니다.
인증서의 발급·보관·갱신·폐기 책임자는 누구인가? 서비스팀과 보안팀, 플랫폼팀 사이의 소유권을 문서화합니다.
인증서 교체 중 실패하면 어떤 업무가 멈추는가? 이중 신뢰 기간, 되돌리기 절차, 만료 알림을 준비합니다.
인증서로 확인한 호출 주체에 어떤 권한과 호출량을 허용할 것인가? 업무 권한 정책과 호출 로그를 함께 검토합니다.
신뢰 경계는 정책과 관측으로 완성됩니다
mTLS는 서비스 간 신뢰를 좁히는 강력한 수단이지만, 혼자서 API 운영을 완성하지는 않습니다. 인증서 오류, 거부된 연결, 정책 위반 호출을 같은 운영 흐름에서 찾고 책임자에게 전달할 수 있어야 합니다.
Litis는 API Gateway·API Security·API Monitoring 관점에서 API 호출 경계, 인증·인가 정책, 운영 가시성을 함께 검토하는 데 도움을 드릴 수 있습니다. 실제 지원 기능과 구성은 사용 중인 플랫폼과 보안 정책을 기준으로 확인해야 합니다.
