들어가며: 끊임없는 진화만이 살길
사이버 보안 업계에는 오랫동안 하나의 원칙이 자리 잡고 있습니다. 바로 "끊임없는 변화와 진화만이 애플리케이션을 영원히 안전하게 지키는 유일한 방법"이라는 것입니다.
과거에는 컴포넌트 간 인증(inter-component authentication)이 많은 애플리케이션에게 골칫거리였습니다. 앱은 클라우드 API 내의 다양한 미들웨어와 백엔드 컴포넌트에 스스로를 검증해야만 접근 권한을 얻을 수 있었죠. 하지만 웹 API에서의 애플리케이션 인증은 선택이 아닌 필수적인 과정입니다.
기존의 검증 메커니즘은 정적 애플리케이션 로그인(static application login) 방식입니다. 그러나 이 방법에는 다음과 같은 보안 문제가 존재합니다.
- 로그인 자격 증명이 수시로 갱신되어야 하는 관리 부담이 있습니다.
- 기업이 애플리케이션의 활동을 확인하고 기록하는 능력이 떨어집니다.
함께 읽기: DevSecOps는 애플리케이션과 소프트웨어 보안에 도움이 될까?
TLS 상호 인증이란?
클라우드 API 보안을 강화하는 가장 효과적인 방법 중 하나는 컴포넌트나 프로세스가 서로 통신할 때 TLS(전송 계층 보안, Transport Layer Security) 상호 인증(mutual authentication)을 도입하는 것입니다.
RESTful API 컴포넌트가 이미 TLS 상호 인증 기법을 사용하고 있다고 가정해 보겠습니다. 이 방식은 애플리케이션에게 클라이언트 인증서(client certificate)를 제출하여 자신을 검증하도록 요구합니다. 이를 통해 애플리케이션 보안 인프라 전략을 한층 견고하게 다질 수 있습니다.
기존 인증 방식의 문제점
일반적인 프로세스에서는 활동 내역이 백엔드 컴포넌트 기준으로 하나의 사용자 ID 아래 묶여 분류됩니다. 이러한 분류 방식 때문에 방대한 이벤트 정보 속에서 특정 애플리케이션과 관련된 이벤트를 찾아내기가 매우 어렵습니다. 사이버 공격이 발생했는데 해당 이벤트조차 찾지 못한다면 상황은 더욱 악화됩니다. 결국 보안 담당자는 정상적인 애플리케이션과 악성 애플리케이션을 구분하기 어려워지죠. 이 문제는 10년 넘게 지속되어 온 고질적인 과제로, 아직까지 완전히 해결되지 않았습니다.
RESTful API 역시 여전히 상호 검증이 필요하며, HTTP 기반 방식에 의존해 인증을 수행합니다. 예를 들어 HTTP 요청 헤더에 숨겨진 값을 포함시켜 요청자를 검증하는데, 이를 HTTP 기본 인증(HTTP basic authentication)이라고 합니다. 이 방식은 클라우드 애플리케이션이 클라우드에 있든 온프레미스(on-premises)에 있든 구분 없이 적용됩니다. PaaS든 IaaS든, 컴포넌트 간 인증은 여전히 풀리지 않는 숙제입니다.
TLS가 해결책이 되는 이유
핵심은 이미 구현한 인증 메커니즘을 강화하기 위해 TLS의 기능을 적극 활용하는 것입니다. TLS가 웹 서핑 용도로 사용되지 않는 경우에도, 거래하는 피어(peer) 간의 상호 검증을 지원합니다.
서버는 브라우저가 원격 웹사이트를 인증하는 것과 같은 방식으로 요청자를 인증합니다. 클라우드 API는 HTTP 프로토콜을 전송 수단으로 사용하지만, 그럼에도 컴포넌트 간 상호 검증을 허용할 수 있습니다. TLS 상호 인증에서는 허용 가능한 인증서 매개변수를 세부적으로 제한할 수도 있습니다. 즉, 클라우드 애플리케이션은 특정 인증서나 특정 일련번호, 심지어 특정 인증 기관(CA)에서 발급된 인증서만 제출하도록 요구할 수 있는 것이죠. 또한 TLS 방식을 정적 숨김 값(hidden value)이나 비밀번호와 결합하는 것도 가능합니다.
다만 클라우드 환경에서 TLS 상호 인증을 구현하는 데는 몇 가지 전제 조건이 있습니다. 우선 클라우드 API가 TLS 상호 인증을 설정할 수 있도록 커스터마이징 가능해야 합니다. 이는 설정을 직접 수정할 수 있는 IaaS 환경을 갖추고 있어야 함을 의미합니다. 아니면 해당 기능을 간편하게 활성화할 수 있는 PaaS 환경이어야 하죠. AWS나 마이크로소프트 애저(Azure) 같은 클라우드 전문 업체의 사례를 참고하면 도움이 됩니다.
TLS 상호 인증의 장점
TLS 상호 인증을 활용하면 누릴 수 있는 이점이 많습니다. 가장 두드러진 장점은 비밀번호나 시크릿 값(secret value)을 관리하는 번거로움이 크게 줄어든다는 점입니다. 비밀번호나 정적 숨김 값을 사용·관리하는 일은 주기적인 변경, 사용 현황 점검, 복잡한 비밀번호 생성, 보호 보장 등 여러 과정을 수반하기 때문에 상당히 번거로운 작업입니다. 반면 TLS 상호 인증은 이런 추가적인 관리 부담을 덜어줍니다. 인증 방식을 처음 활성화할 때 몇 차례 비밀번호가 사용되긴 하지만, 장기적으로는 TLS가 비밀번호의 역할을 크게 축소해 줍니다.
또한 TLS 상호 인증은 비밀번호보다 휴대성이 낮은 인증서와 개인 키(private key)를 사용합니다. 물론 인증서와 개인 키도 다른 디지털 자산과 마찬가지로 유출될 수 있지만, 해커가 원격 API 호출자로 위장하려 할 때 최소한 물리적 확보 측면에서 공격 난이도를 크게 높여줍니다.
애플리케이션 모니터링 측면에서도 TLS는 API 요청을 보낸 컴포넌트나 애플리케이션을 더 명확하게 기록해 줍니다. 비밀번호 기반 방식으로는 이를 파악하는 것이 훨씬 복잡한 작업입니다.
함께 읽기: 사이버 보안은 발전하고 있는가, 아니면 악화되고 있는가?
TLS 상호 인증의 단점
TLS 상호 인증을 구현할 때 몇 가지 단점도 존재합니다. 하지만 어떤 단점도 이 기술 도입을 망설일 이유는 되지 않으며, 오히려 보완 포인트로 삼으면 됩니다.
먼저 인증서에는 유효 기간이 있다는 점입니다. 따라서 인증서가 만료되기 전에 재발급하는 것을 항상 기억해야 합니다. 재발급을 잊으면 결과가 심각할 수 있는데, 만료로 인한 장애는 원인 파악과 디버깅이 매우 까다롭기 때문입니다. 인증서 만료일을 체계적으로 추적하고, 만료된 인증서를 선제적으로 교체하는 운영 프로세스를 반드시 갖추시기 바랍니다.
결론
종합적으로, TLS 상호 인증은 클라우드 API 보안을 강화하기 위한 실용적이고 건설적인 방법입니다. 무엇보다 TLS 상호 인증은 보안 전문가가 클라우드 환경에서 애플리케이션 보안 수준을 정확하게 평가하고 관리하는 데 든든한 기반이 되어 줄 것입니다.